我有一個財務領域的遺留產品。使用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頁）中，您可以找到關於的好讀物，爲什麼不分配您的業務邏輯。