微服務架構的前世今生（二）：技術架構演變

上一篇我們講了微服務架構的前世今生（一）：傳統行業向互聯網行業的轉型，本文接著3講述微服務技術架構演變。

下圖表示從單體應用逐漸轉變為微服務應用。

一、單一應用架構

通俗地講，“單體應用（monolith application）”就是將應用程式的所有功能都打包成一個獨立的單元。當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。

1、特點

• 所有的功能集成在一個項目工程中；
• 所有的功能打一個 war 包部署到伺服器；
• 應用與資料庫分開部署；
• 通過部署應用集群和資料庫集群來提高系統的性能。

2、優點

• 「開發簡單」：一個 IDE 就可以快速構建單體應用；

• 「便於共用」：單個歸檔文件包含所有功能，便於在團隊之間以及不同的部署階段之間共用；

• 「易於測試」：單體應用一旦部署，所有的服務或特性就都可以使用了，這簡化了測試過程，因為沒有額外的依賴，每項測試都可以在部署完成後立刻開始；

• 「容易部署」：整個項目就一個 war 包，Tomcat 安裝好之後，應用扔上去就行了。群化部署也很容易，多個 Tomcat + 一個 Nginx 分分鐘搞定。

3、缺點

• 「妨礙持續交付」：隨著時間的推移，單體應用可能會變得比較大，構建和部署時間也相應地延長，不利於頻繁部署，阻礙持續交付。在移動應用開發中，這個問題會顯得尤為嚴重；
• 「不夠靈活」：隨著項目的逐漸變大，整個開發流程的時間也會變得很長，即使在僅僅更改了一行代碼的情況下，軟體開發人員需要花費幾十分鐘甚至超過一個小時的時間對所有代碼進行編譯，並接下來花費大量的時間重新部署剛剛生成的產品，以驗證自己的更改是否正確。如果多個開發人員共同開發一個應用程式，那麼還要等待其他開發人員完成了各自的開發。這降低了團隊的靈活性和功能交付頻率；
• 「受技術棧限制」：項目變得越來越大的同時，我們的應用所使用的技術也會變得越來越多。這些技術有些是不相容的，就比如在一個項目中大範圍地混合使用 C++ 和 Java 幾乎是不可能的事情。在這種情況下，我們就需要拋棄對某些不相容技術的使用，而選擇一種不是那麼適合的技術來實現特定的功能。
• 「可靠性差」：某個環節出現了死迴圈，導致記憶體溢出，會影響整個項目掛掉。
• **伸縮性差：**系統的擴容只能針對應用進行擴容，不能做到對某個功能進行擴容，擴容後必然帶來資源浪費的問題。
• 「技術債務」：假設我的代碼庫中有一個混亂的模塊結構。此時，我需要添加一個新功能。如果這個模塊結構清晰，可能我只需要2天時間就可以添加好這個功能，但是如今這個模塊的結構很混亂，所以我需要4天時間。多出來的這兩天就是債務利息。隨著時間推移、人員變動，技術債務必然也會隨之增多。

二、垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。

1、特點

• 以單體結構規模的項目為單位進行垂直劃分，就是將一個大項目拆分成一個一個單體結構項目。
• 項目與項目之間存在數據冗餘，耦合性較大，比如上圖中三個項目都存在用戶信息。
• 項目之間的介面多為數據同步功能，如：資料庫之間的資料庫，通過網路介面進行資料庫同步。

2、優點

• 開發成本低，架構簡單；

• 避免單體應用的無限擴大；

• 系統拆分實現了流量分擔，解決了併發問題；

• 可以針對不同系統進行擴容、優化；

• 方便水平擴展，負載均衡，容錯率提高；

• 不同的項目可採用不同的技術；

• 系統間相互獨立。

3、缺點

• 系統之間相互調用，如果某個系統的埠或者 IP 地址發生改變，調用系統需要手動變更；
• 垂直架構中相同邏輯代碼需要不斷的複製，不能復用。
• 系統性能擴展只能通過擴展集群結點，成本高、有瓶頸。

三、SOA 面向服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心。當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集群容量，提高集群利用率。

P.S.：從軟體設計的角度上來說，ESB 是一個抽象的間接層，提取了服務調用過程中調用與被調用動態交互中的一些共同的東西，減輕了服務調用者的負擔。Java 編程思想里提到：“所有的軟體設計的問題都可以通過增加一個抽象的間接層而得到解決或者得到簡化！”簡單來說 ESB 就是一根管道，用來連接各個服務節點。為了集成不同系統，不同協議的服務，ESB 做了消息的轉化解釋和路由工作，讓不同的服務互聯互通。

1、特點

• 基於 SOA 的架構思想將重覆公用的功能抽取為組件，以服務的形式給各系統提供服務。
• 各項目（系統）與服務之間採用 WebService、RPC 等方式進行通信。
• 使用 ESB 企業服務匯流排作為項目與服務之間通信的橋梁。

2、優點

• 將重覆的功能抽取為服務，提高開發效率，提高系統的可重用性、可維護性。
• 可以針對不同服務的特點制定集群及優化方案；
• 採用 ESB 減少系統中的介面耦合。

3、缺點

• 系統與服務的界限模糊，不利於開發及維護。
• 雖然使用了 ESB，但是服務的介面協議不固定，種類繁多，不利於系統維護。
• 抽取的服務的粒度過大，系統與服務之間耦合性高。
• 涉及多種中間件，對開發人員技術棧要求高。
• 服務關係複雜，運維、測試部署困難

四、微服務架構

1、特點

• 將系統服務層完全獨立出來，並將服務層抽取為一個一個的微服務。
• 微服務中每一個服務都對應唯一的業務能力，遵循單一原則。
• 微服務之間採用 RESTful 等輕量協議傳輸。

2、優點

• 團隊獨立：每個服務都是一個獨立的開發團隊，這個小團隊可以是 2 到 5 人的開發人員組成；
• 技術獨立：採用去中心化思想，服務之間採用 RESTful 等輕量協議通信，使用什麼技術什麼語言開發，別人無需干涉；
• 前後端分離：採用前後端分離開發，提供統一 Rest 介面，後端不用再為 PC、移動端開發不同介面；
• 資料庫分離：每個微服務都有自己的存儲能力，可以有自己的資料庫。也可以有統一資料庫；
• 服務拆分粒度更細，有利於資源重覆利用，提高開發效率；
• 一個團隊的新成員能夠更快投入生產；
• 微服務易於被一個開發人員理解，修改和維護，這樣小團隊能夠更關註自己的工作成果。無需通過合作才能體現價值；
• 可以更加精準的制定每個服務的優化方案（比如擴展），提高系統可維護性；
• 適用於互聯網時代，產品迭代周期更短。

3、缺點

• 微服務過多，服務治理成本高，不利於系統維護；
• 分散式系統開發的技術成本高（網路問題、容錯問題、調用關係、分散式事務等），對團隊挑戰大；
• 微服務將原來的函數式調用改為服務調用，不管是用 rpc，還是 http rest 方式，都會增大系統整體延遲。這個是再所難免的，這個就需要我們將原來的串列編程改為併發編程甚至非同步編程，增加了技術門檻；
• 多服務運維難度，隨著服務的增加，運維的壓力也在增大；
• 測試的難度提升。服務和服務之間通過介面來交互，當介面有改變的時候，對所有的調用方都是有影響的，這時自動化測試就顯得非常重要了，如果要靠人工一個個介面去測試，那工作量就太大了，所以 API 文檔的管理尤為重要。

 本文就介紹到這裡，想獲取java微服務架構學習視頻資料，請點擊訪問java微服務架構spring全家桶教程。

下一篇文章將分享2個故事，幫助大家更好的理解 SOA 與微服務的區別。