我有一个财务领域的遗留产品。使用tomcat 6.我们在几小时内获得数百万的请求10k的请求。我想在高层 我应该去哪里我的mvc组件在一个系统和服务/道另一个盒子（可以使用弹簧远程/ EJB）的ditributed应用程序。 我打算沿着这个方向前进的原因，以便负载分散并获得更好的性能。因此，它也可以扩展。 我只看到它的积极面，但不知何故无法弄清楚它可能是什么消极方面？决定去分布式应用程序？
如果一些专家可以帮助 我应该考虑去分布式模型和利弊的标准是什么？我也尝试使用谷歌搜索，在那里我可以得到一些统计 像一个给定的网络服务器（在我的情况下，tomcat）有多少负载与给定的硬件（16 GB内存，Windows 7中，处理器）有效地处理。
是的，我要 做POC我将用分布式模型测量性能vs没有位高级输入将高度赞赏？
如果没有更多的细节，回答这个问题是不可能的 - 在当前服务器上回复一个请求需要多长时间？为一个请求分配了多少资源？
每小时有10k个请求意味着每秒约3个请求。如果执行必要的操作并回复请求，则使用1个CPU需要约300ms - 一台简单的机器是完全正常的。这是简单的数学，并不总是工作。我想你在这些每小时10k个请求中仍然有高峰，而且它们不是逐渐分布的。
如果我们假设，一个回复最多可能需要1秒，比您的系统具有CPU的情况下每秒可处理的回复数多（假设CPU是瓶颈）。如果CPU不是瓶子您的应用程序服务器的脖子，可能有错误。您应该在不同的机器上设置数据库，并仅在应用程序服务器计算机上执行计算任务。
特别是在财务部门使用旧版软件时，我不会尝试拆分正在运行的产品。目前的服务器多大？我相信一个新的服务器应该比重写应用程序便宜。除非您很快就会预计每小时有5万到10万个请求，否则我不认为分裂这些小部分是有道理的。
相反 - 在最新的服务器硬件上运行它，拆分应用程序服务器和数据存储，你应该没问题。
我想知道如果我应该在我的mvc组件在另一个系统上的服务/ dao（可以使用spring远程/ EJB）的分布式应用程序。
我不知道你在这方面的意思为“系统”，但如果它意味着你打算在两台服务器上运行你的应用程序， 一个专用于演示和其他专用于业务层，请记住，更简单的方法（可能更适合您的应用程序） 构建co-located体系结构。
基本上，这个想法是在几台服务器（至少两台）上复制你的应用程序，并在它们前面放置一个负载平衡器，用于在可用服务器之间路由传入请求。 所有服务器共享相同的数据库实例。这将为您提供垂直可伸缩性，并且还会提高系统的可用性。
我只看到它的积极面，但不知何故无法弄清楚它可能是什么消极方面？
分配您的业务逻辑可能会涉及应用程序代码的重构，如果系统运行良好，您肯定会添加一些错误。 必要的远程调用会增加延迟，并且您在多个服务器中执行业务逻辑的事实不能解决表示层上的性能问题。
在Expert One-on-One J2EE Development Without EJB（第65页）中，您可以找到关于的好读物，为什么不分配您的业务逻辑。