PaaS服務之路漫談（二）

標籤：href   均衡   ESS   案頭   理解   article   led   快速迭代   工具鏈   

此文已由作者堯飄海授權網易雲社區發布。

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。

天下大勢，分久必合，合久必分，社會曆史的發展方向總有著驚人的相似。把這種規律應用到軟體應用架構的發展方向上，當生產力和生產關係到了不可調和的矛盾時，也將導致軟體架構的演變，這樣演變將會進一步推動軟體的發展，同時也會帶來很多問題，因此在不同的階段，採用不同的架構適應業務發展是有一定道理的，步子太小，容易夾著蛋，步子太大，容易扯著蛋 。

從前文的WEB應用技術的發展來看，WEB應用的服務架構模式的可以劃分為Monolithic（整塊架構）和MSA（微服務架構）。並且現在很大的中小應用還是使用Monolithic的架構模式，不同的架構模式應用在不同規模的應用中將產生不同的效果，下面我們簡單的對二種架構進行分析

Monolithic架構

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

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

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

• 資料庫層，負責模型層的資料存放區和組織

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

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

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

• 新入希望能夠較快的溶入到隊伍中，並且能快速上手

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

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

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

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

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

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

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

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

• 部署簡單 通過一些部署的工具，甚至SHELL指令碼即能完成整個應用的部署，其他的無非是一些正常化或定製化的東西

• 易營運 通過複製多份的方式來實現模向擴充，負載平衡完成請求路由。

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

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

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

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

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

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

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

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

為了避免本文的裹腳布又長又臭，將繼續分下一篇對MSA服務構架來分析。敬請期待。

PaaS服務之路漫談（一）

網易 雲端運算基礎服務 深度整合了  IaaS 、 PaaS  及容器技術，提供彈性計算、 DevOps  工具鏈及微服務基礎設施等服務，協助企業解決  IT 、架構及營運等問題，使企業更聚焦於業務，是新一代的雲端運算平台， 點擊可免費試用 。 

相關文章：
【推薦】 後台服務項目的白盒測試之旅
【推薦】 遭遇各種內容監管，有些企業到底欠缺的是什麼，僅僅是價值觀嗎？

PaaS服務之路漫談（二）