網易杭州研究院·堯飄海

本文作于2015年2月

天下大勢，分久必合，合久必分，社會歷史的發展方向總有著驚人的相似。

把這種規律應用到軟件應用架構的發展方向上，當生產力和生產關系到了不可調和的矛盾時，也將導致軟件架構的演變。這樣演變將會進一步推動軟件的發展，同時也會帶來很多問題，因此在不同的階段，采用不同的架構適應業務發展是有一定道理的。步子太小，容易夾著蛋，步子太大，容易扯著蛋 。

從前文【PaaS服務之路漫談（一）】的WEB應用技術的發展來看，WEB應用的服務架構模式的可以劃分為Monolithic（整塊架構）和MSA（微服務架構）。并且現在很大的中小應用還是使用Monolithic的架構模式，不同的架構模式應用在不同規模的應用中將產生不同的效果。

下面我們簡單的對這兩種架構進行分析。

Monolithic架構

隨著移動應用的發展，現在的服務端程序需要提供不同的能力來支持包括桌面端、瀏覽器端及移動端等。早期的應用可通過CORBA，EJB等技術來實現，日前，考慮到各平臺的兼容和簡便性，大部分會通過暴露相關的服務接口或消息代理給第三方消費和實現消息交換。應用程序基本上通過分層或者組合的方式來架構，由不同的組件來完成相關職責

• 表現層，主要負責處理HTTP相關請求，然后返回不同的響應格式，包括HTML，JSON等

• 業務邏輯，即控制層，負責應用的邏輯處理

• 數據庫層，負責模型層的數據存儲和組織

這種架構的方式的實現方式如下：

在日常的軟件開發過程中，無樣采用什么樣的軟件模式，常常有這樣的非功能性需求：

• 須有一完整的開發隊伍保證應用的開發進度

• 新人希望能較快溶入隊伍中，并能快速上手

• 應用希望能夠容易的理解和修改

• 應用支持能夠持續的部署

• 能較好實現擴展性和高可用性等非功能性需求

• 能夠快速的利用新的技術的紅利

在完成相關的功能開發和測試后，在上線時，會采用什么樣的部署方式呢？對于JAVA應用大部分采用JAR或者WAR的方式來實現，對于其他的語言也基本采用打包整個目錄的方式來完成部署，我們的自動部署平臺系統中的大部分應用都是屬于采用這種使用方式來實現部署上線。

采用這種架構模式的優勢是：

• 易開發：整個應用能直接利用開發工具或IDE直接完成，除了一些依賴的服務，基本在能單機上完成；

• 測試簡單：由于不涉及到多個系統的交互，因此對應的測試流程也會變得相對簡單，單一的流程能完成相關的測試；

• 部署簡單：通過一些部署的工具，甚至SHELL腳本即能完成整個應用的部署，其他的無非是一些規范化或定制化的東西；

• 易運維：通過復制多份的方式來實現模向擴展，負載均衡完成請求路由。

當然，隨著系統的發展和擴大，Monolithic架構的一些問題也暴露出來了：

• 大量的代碼經常會導致開發人員因為風險導致不敢輕易重構，同時還要完整的測試用例才能保證重構的完成；另外對新人來說，模塊劃分不清楚也會帶來很多的挫折感，基本在一段時間內不敢對應用功能修改，情愿添加新增的方式來完成。而很大一部分的人都使用新增導致整個系統更復雜，最后很快就變得無法維護了

• 大量的代碼會將導致CO代碼的時間非常長，同時對應的IDE的編譯時間和運行時間也變得不可預測，以前就碰到過同事的代碼過長在緊張上線修改BUG時，導致ECLIPSE死掉而使得工作效率大大減少的問題；另外應用容器的啟動時間也會因為應用代碼的急增導致變長，不能快速的啟動導致調試和測試的時間變長，影響應用的進度。同樣在部署的過程中也會影響到用戶的服務時間。

• 持續部署也是很困難的，如果應用要希望時常發布，這對運用運維也來也是一定的災難，為了修改一個問題導致整個應用重新打包部署，編譯時間打包又長，特別是在后端的應用修改的情況下還要進行前端代碼的無功打包，對了運維人員的時間是個極大的浪費。如果應用里面包括定時任務等功能還可能對業務數據產生影響，導致運維的風險越來越高，加上開發人員對運維方式的抱怨，導致運維人員對發布越來抗拒，從而導致矛盾越來越嚴重。在同事使用自動部署平臺的反饋中，有時候就聽到開發人員和運維人員的相互指責或者抱怨。

• 擴展也是比較團難的，盡管大部門分的WEB應用能支持橫向擴展，但是實際上，當應用規模擴展到了后端服務無法支撐時，比如后端單一數據庫連接資源不夠時，就無法擴展了。另外對其他的資源競爭也會導致無法真正的擴展，因為系統到一定規模時就有定會有熱點數據，這個熱點數據常會導致整個系統無法正常服務。系統的每個模塊對資源的使用也是不同的，有些是CPU密集型，有些是IO密集型,因此，實際是不可擴展的，只是系統沒有真的到達到相像中的那么大。

• 快速開發的障礙 整塊應用的架構還將導致整個開發團隊的相互依賴，一般來講一個應用最后會發展成根據特定的功能劃分成不同的工程師隊伍，比如UI小組,交互小組，會員組，前端組等架構形式，這將使用得各工作的團隊相互依賴，不能獨立工程一個功能的修改會使得一系統的人員依賴和評估相關的風險，這也使得導致產品不能快速迭代。

• 技術債，此架構迫使開發人員嚴重依賴相關的技術，比如只能使用JAVA語言，甚至還些還依賴于特定的軟件版本，就也會使得軟件無法采用最新的版本，只能通過補丁加補丁的方式來完成，導致技術債越來越重。如果使用的軟件版本不再提供維護，后面只能通過特定的人員或團隊才能搞定或者采用整個應用重寫的方式來實現，這在實際應用開發中是非常常見的，包括微軟這樣的大公司也避免不了這個問題，這將導致相關大的風險。

小結

上面我們大體根據實際應用中碰到的問題，對Monolithic架構的優勢和問題進行了分析，但是本文并不是說Monolithic架構毫無用處，只是說明這種架構模式的適用場景。其實它在大部分的系統中還是使用這種模式完成的，并且還工作得很好，引用之前汪源引用GOOLGE大師的話，JUST WORK就好。

下期預告

下期《PaaS服務之路漫談（三）》將為大家分析MSA服務構架。敬請關注。

「

往期回顧

」

﹀

﹀

﹀

PaaS服務之路漫談（一）

網易云信∣真正穩定的IM云服務

ID：neteaseim ?長按識別，關注精彩

總結

以上是生活随笔為你收集整理的PaaS服务之路漫谈(二)：Monolithic架构分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。