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

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

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

1、單一應用架構

通俗地講，「單體應用（monolith application）」就是將應用程序的全部功能都打包成一個獨立的單元。當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。

一、特色

全部的功能集成在一個項目工程中；
全部的功能打一個 war 包部署到服務器；
應用與數據庫分開部署；
經過部署應用集羣和數據庫集羣來提升系統的性能。

二、優勢

「開發簡單」：一個 IDE 就能夠快速構建單體應用；

「便於共享」：單個歸檔文件包含全部功能，便於在團隊之間以及不一樣的部署階段之間共享；

「易於測試」：單體應用一旦部署，全部的服務或特性就均可以使用了，這簡化了測試過程，由於沒有額外的依賴，每項測試均可以在部署完成後馬上開始；

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

三、缺點

「妨礙持續交付」：隨着時間的推移，單體應用可能會變得比較大，構建和部署時間也相應地延長，不利於頻繁部署，阻礙持續交付。在移動應用開發中，這個問題會顯得尤其嚴重；

「不夠靈活」：隨着項目的逐漸變大，整個開發流程的時間也會變得很長，即便在僅僅更改了一行代碼的狀況下，軟件開發人員須要花費幾十分鐘甚至超過一個小時的時間對全部代碼進行編譯，並接下來花費大量的時間從新部署剛剛生成的產品，以驗證本身的更改是否正確。若是多個開發人員共同開發一個應用程序，那麼還要等待其餘開發人員完成了各自的開發。這下降了團隊的靈活性和功能交付頻率；

「受技術棧限制」：項目變得愈來愈大的同時，咱們的應用所使用的技術也會變得愈來愈多。這些技術有些是不兼容的，就好比在一個項目中大範圍地混合使用 C++ 和 Java 幾乎是不可能的事情。在這種狀況下，咱們就須要拋棄對某些不兼容技術的使用，而選擇一種不是那麼適合的技術來實現特定的功能。

「可靠性差」：某個環節出現了死循環，致使內存溢出，會影響整個項目掛掉。

伸縮性差：系統的擴容只能針對應用進行擴容，不能作到對某個功能進行擴容，擴容後必然帶來資源浪費的問題。

「技術債務」：假設個人代碼庫中有一個混亂的模塊結構。此時，我須要添加一個新功能。若是這個模塊結構清晰，可能我只須要2天時間就能夠添加好這個功能，可是現在這個模塊的結構很混亂，因此我須要4天時間。多出來的這兩天就是債務利息。隨着時間推移、人員變更，技術債務必然也會隨之增多。

2、垂直應用架構

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

一、特色

以單體結構規模的項目爲單位進行垂直劃分，就是將一個大項目拆分紅一個一個單體結構項目。
項目與項目之間存在數據冗餘，耦合性較大，好比上圖中三個項目都存在用戶信息。
項目之間的接口多爲數據同步功能，如：數據庫之間的數據庫，經過網絡接口進行數據庫同步。

二、優勢

開發成本低，架構簡單；

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

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

能夠針對不一樣系統進行擴容、優化；

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

不一樣的項目可採用不一樣的技術；

系統間相互獨立。

三、缺點

系統之間相互調用，若是某個系統的端口或者 IP 地址發生改變，調用系統須要手動變動；
垂直架構中相同邏輯代碼須要不斷的複製，不能複用。
系統性能擴展只能經過擴展集羣結點，成本高、有瓶頸。

3、SOA 面向服務架構

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

P.S.：從軟件設計的角度上來講，ESB 是一個抽象的間接層，提取了服務調用過程當中調用與被調用動態交互中的一些共同的東西，減輕了服務調用者的負擔。Java 編程思想裏提到：「全部的軟件設計的問題均可以經過增長一個抽象的間接層而獲得解決或者獲得簡化！」簡單來講 ESB 就是一根管道，用來鏈接各個服務節點。爲了集成不一樣系統，不一樣協議的服務，ESB 作了消息的轉化解釋和路由工做，讓不一樣的服務互聯互通。

一、特色

基於 SOA 的架構思想將重複公用的功能抽取爲組件，以服務的形式給各系統提供服務。
各項目（系統）與服務之間採用 WebService、RPC 等方式進行通訊。
使用 ESB 企業服務總線做爲項目與服務之間通訊的橋樑。

二、優勢

將重複的功能抽取爲服務，提升開發效率，提升系統的可重用性、可維護性。
能夠針對不一樣服務的特色制定集羣及優化方案；
採用 ESB 減小系統中的接口耦合。

三、缺點

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

4、微服務架構

一、特色

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

二、優勢

團隊獨立：每一個服務都是一個獨立的開發團隊，這個小團隊能夠是 2 到 5 人的開發人員組成；
技術獨立：採用去中心化思想，服務之間採用 RESTful 等輕量協議通訊，使用什麼技術什麼語言開發，別人無需干涉；

先後端分離：採用先後端分離開發，提供統一 Rest 接口，後端不用再爲 PC、移動端開發不一樣接口；
數據庫分離：每一個微服務都有本身的存儲能力，能夠有本身的數據庫。也能夠有統一數據庫；
服務拆分粒度更細，有利於資源重複利用，提升開發效率；

一個團隊的新成員可以更快投入生產；
微服務易於被一個開發人員理解，修改和維護，這樣小團隊可以更關注本身的工做成果。無需經過合做才能體現價值；

能夠更加精準的制定每一個服務的優化方案（好比擴展），提升系統可維護性；
適用於互聯網時代，產品迭代週期更短。

三、缺點

微服務過多，服務治理成本高，不利於系統維護；

分佈式系統開發的技術成本高（網絡問題、容錯問題、調用關係、分佈式事務等），對團隊挑戰大；
微服務將原來的函數式調用改成服務調用，不論是用 rpc，仍是 http rest 方式，都會增大系統總體延遲。這個是再所不免的，這個就須要咱們將原來的串行編程改成併發編程甚至異步編程，增長了技術門檻；

多服務運維難度，隨着服務的增長，運維的壓力也在增大；

測試的難度提高。服務和服務之間經過接口來交互，當接口有改變的時候，對全部的調用方都是有影響的，這時自動化測試就顯得很是重要了，若是要靠人工一個個接口去測試，那工做量就太大了，因此 API 文檔的管理尤其重要。

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

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