我在金融领域有一个遗留产品。使用tomcat 6.我们在一小时内收到数百万请求10k的请求。我想在高层 我应该选择ditributed应用程序，其中我的mvc组件在一个系统上，而service / dao在另一个盒子上（可以使用spring remote / EJB）。 我计划朝着这个方向前进的原因，以便分配负载并获得更好的性能随着它变得可扩展。 我只看到它的积极方面，但不知何故无法弄清楚它的负面影响是什么？
如果有专家可以提供帮助 我应该考虑分配模型的标准和它的优缺点是什么？我也试过谷歌搜索我可以得到一些统计数据 比如给定的web服务器（在我的情况下是tomcat）有多少负载处理给定的硬件（16 gb ram，windows 7，处理器）。
是的，我要去 要做POC我将用分布式模型测量性能与没有位高级输入将受到高度赞赏吗？
答案 0 :(得分：1)
如果没有更多详细信息，则无法回答这些问题 - 在当前服务器上回复一个请求需要多长时间？为一个请求分配了多少资源？
每小时有10k个请求意味着每秒约3个请求。如果执行必要的操作并回复请求，使用1个CPU需要大约300毫秒 - 一台简单的机器完全没问题。这是简单的数学，并不总是有效。我猜你在每小时10k的请求中仍然有峰值，并且它们不会逐渐分发。
如果我们假设，一个回复可能需要1秒钟，而不是你可以处理每秒多少回复，因为你的系统有CPU（假设CPU是瓶颈）如果CPU不是瓶颈对于您的应用程序服务器，可能有些错误。您应该在另一台计算机上设置数据库，并仅在应用程序服务器计算机上执行计算任务。
特别是在使用传统软件的金融领域，我不会尝试拆分正在运行的产品。当前的服务器多大了？我相信新服务器应该比重写应用程序便宜。除非你很快就会得到每小时50-100k的请求，否则我不认为，拆分这么小的部分是有道理的。
相反 - 在最新的服务器硬件上运行它，拆分应用程序服务器和数据存储，你应该没问题。
答案 1 :(得分：1)
我想知道我是否应该选择ditributed应用程序，其中我的mvc组件在一个系统上，而service / dao在另一个盒子上（可以使用spring remote / EJB）。
我不确定你的意思是什么＆＃34; system＆＃34;在这种情况下，但如果这意味着您计划在两台服务器上运行您的应用程序， 一个致力于演示和其他专用于业务层，请记住一个更简单的方法（可能更适合您的应用程序） 构建co-located架构。
基本上，我们的想法是在几个服务器（至少两个）中复制您的应用程序，并在它们前面放置一个负载均衡器，用于在可用服务器之间路由传入请求。 所有服务器共享同一个数据库实例。这将为您提供垂直可扩展性，并且还将提高系统的可用性。
我只看到它的积极方面，但不知何故无法弄清楚它的消极方面是什么？
分发业务逻辑可能涉及应用程序代码的重构，如果系统运行良好，您肯定会添加一些错误。 必要的远程调用会增加延迟，并且您在多个服务器中执行业务逻辑这一事实并不能解决表示层上的性能问题。
在Expert One-on-One J2EE Development Without EJB（第65页）中，您可以找到关于为什么不分发业务逻辑的好消息。