將一個大的整體應用程序拆分為兩個應用程序有什么好處？

Question

當前，我們有一個大型的單片J2EE應用程序（weblogic / DB2）。 這是典型的OLTP應用程序。 我們正在考慮將該應用程序拆分為2個應用程序，其中每個應用程序都有自己的數據庫，其他應用程序無法直接訪問該數據庫。 這也意味着每個應用程序都需要公開其他應用程序所需功能的接口。

那么，將這樣一個現有應用程序分為2個應用程序的潛在主要好處是什么？

Answer 1

大多數應用程序在90％的時間內使用10％的代碼。

微服務的核心思想是現代SOA。 您可以在微服務特定的特殊雲中靈活擴展應用程序的關鍵部分。 雲是一個彈性集群，其中每個節點都是一個虛擬服務器（XEN或VMware等）。 雲可以根據負載因子自動擴展或收縮節點數，而無需人工關注。

對於經典的單片應用程序，您需要擴展整個單片應用程序。 通常，此類應用程序使用大量RAM，並且需要強大的硬件或強大而昂貴的虛擬服務器。 整體式的另一個缺點-如果您需要發布新的業務功能，則發布周期會非常長，因為您已經使用代碼熵對龐大而復雜的代碼庫進行了修改。 這將需要時間/預算昂貴的回歸測試。 但是您有一個好處-與SOA方法相比，可以輕松集成不同的應用程序部分（子系統和模塊），如果您具有良好的應用程序設計，這是沒有原因的。

另一方面，您可以將應用程序邏輯拆分為一組小型應用程序，例如稱為微服務的應用程序。 例如，您有一個僅負責UI的微服務-即只有帶有Angluar.js的Spring MVC，另一個用於業務邏輯和持久性的微服務，以及另一個用於從社交網絡獲取數據的微服務。 所有這些服務都使用通常為RestFull的某些Web服務彼此互連，但可以是SOAP或類似Google Protocol Buffers RPC之類的東西。因此，現在您只能自動縮放UI微服務，這有望實現性能關鍵，而無需觸及業務邏輯和社交網絡微服務。 而且，即使只有一個弱點，您也能夠更新UI微服務，因為僅UI測試並不像業務邏輯測試那樣昂貴。 但是有一個缺點-集群結構變得更加復雜，並且需要更強大的團隊來維護它（通常使用某些基於Chef或Docker的腳本來實現自動化）。 同樣也很難實現子系統集成，並且您需要更仔細地考慮系統設計。

因此，如果您有一個龐大且復雜的系統，需要高負載（例如Amazon.com，Ebay，Facebook或stackoverflow）。 SOA方法使您有機會在基礎架構和硬件上節省一些錢。 但是它的開發成本會更高。 如果您的系統非常簡單，即網吧站點只有幾頁，則首選整體方法。

Answer 2

如果您不關心可伸縮性，那么我將指出以下好處：

• 增加的變更速度-縮短功能從構思階段到生產的時間（降低開發人員的復雜性）
• 較低的測試成本（較小的測試范圍）
• 質量提高（再次，更小的測試范圍）

Answer 3

我們無法權衡利弊，而不必查看該應用程序的全部內容，什么是業務規則，如何划分應用程序以及兩個應用程序如何共享業務規則。 將一個應用程序分為兩個應用程序不只是將Java類分為兩個組。 它需要從不同角度進行深度分析。 希望這可以幫助。