什麼是分佈式系統
從進程角度看, 兩個程序分別運行在兩臺主機的進程上, 它們相互協作最終完成同一個服務, 那麼理論上這兩個程序所組成的系統, 可以稱作"分佈式系統".
當然, 這兩個程序可以是不同的程序, 可以是相同的程序. 如果是相同的程序, 我們又可以稱爲 "集羣". 所謂集羣, 就是將相同的程序, 通過不斷橫向擴展, 以提高服務能力的方式.
應用框架演進
服務化架構
上圖的 web app 服務是單體化的, 所有組件耦合在一個開發項目中, 並且配置和運行在一個 JVM 進程中. 如果某個組件需要升級上線, 則會導致其他沒有變更的組件同樣上線.
而且無法滿足高併發請求處理, 水平擴展能力也很有限的.
爲了解決上述問題, SOA 出現了. SOA 代表面向服務的架構, 俗稱服務化. SOA 將應用程序的模塊化組件通過定義明確的接口和協議聯繫起來, 接口是採用中立的方式進行定義的, 獨立於某種語言、硬件和操作系統, 通常通過網絡通信來完成, 但是並不侷限於某種網絡協議, 可以是底層的 TCP/IP, 可以是應用層的 HTTP, 也可以是消息隊列協議, 甚至可以是來約定的某種數據庫存儲信息.
這使得各種各樣的系統中的模塊化組件可以以一種統一和通用的方式進行交互.
SOA 將模塊化組件從單一進程中進一步拆分, 通過某種網絡協議形成獨立的對外提供服務的網絡化組件, 這種架構下的特點如下:
- SOA 定義了良好的對外接口, 通過網絡協議對外提供服務, 服務之間表現爲鬆耦合性.
- 某個服務的內部結構和實現發生改變時, 只要接口保持不變, 不影響整個流程對外提供服務.
- SOA 通過定義標準的對外接口, 可以讓多個使用方同時使用, 增加服務的可重用性.
- SOA 可以讓企業最大化地使用內部和外部地公共服務, 避免重複造輪子.
要徹底理解 SOA 時代地服務化發展情況, 我們必須理解 SOA 的兩個主流實現方式: web service 和 ESB.
- Web Service
Web Service 技術是 SOA 服務化的一種實現方式. 運行在不同操作系統上的服務的互相發現和調用, 並且可以通過某種協議交換數據.
上圖可以看到, 每個服務之間是對等的, 並且互相是解耦的, 通過 WSDL 定義的服務發現接口進行訪問, 並通過 SOAP 協議進行通信. SOAP 協議通常是一種在 HTTP 或者 HTTPS 通道上傳輸 XML 數據來實現的協議, 但是每個服務都要依賴中心化 Web Service 目錄來發現現存的服務.
Web Service 的工作原理如下.
- 服務提供者 Web Service 2 和 Web Service 3 通過 UDDI 協議將服務註冊到 Web Service 目錄服務中.
- 服務消費者 Web Service 1 通過 UDDI 協議從 Web Service 目錄中查詢服務, 並獲得服務的 WSDL 服務描述文件.
- 服務消費者 Web Service 1 通過 WSDL 語言遠程調用和消費 Web Service 2 和 3 提供的服務.
通過這個過程, 要改造一個新的業務流程, 可以從 Web Service 目錄中發現現有的服務, 並最大限度地重用現有的服務.
從服務化到微服務
隨着物聯網企業的不斷髮展, 互聯網產品需要服務的用戶量逐漸增加, 海量用戶發起的大規模、高併發請求是企業不得不面對的.
前面介紹的 SOA 服務化系統能夠分解任務, 讓每個服務更簡單、職責單一、更易於擴展, 但無論是 Web Service 還是 ESB, 都有時代遺留問題.
Web Service 的問題如下:
- 依賴中心化的服務發現機制.
- 使用 SOAP 通信協議, 通常使用 XML 格式來序列化通信數據, XML 格式的數據冗餘太大, 協議太重.
- 服務化管理和治理設施並不完善.
微服務架構倡導將軟件應用設計成多個可獨立開發、可配置、可運行和可維護的子服務, 子服務之間通過良好的接口定義通信機制, 通常使用 RESTful 風格的 API 形式來通信, 因爲 RESTful 風格的 API 通常是在 HTTP 或者 HTTPS 通道上傳輸 JSON 格式的數據來實現的, HTTP 協議有跨語言、跨異構系統的優點.
當然, 也可以通過底層的二進制協議、消息隊列協議等進行交互.
這些服務不需要中心化的統一管理, 每個服務的功能可以自治, 並且可以由不同的語言、系統和平臺實現.
微服務架構與傳統單體架構的對比
上圖我們可以得出如下結論:
- 微服務把每個職責單一的功能放在一個獨立的服務中.
- 每個服務運行在一個單獨的進程中.
- 每個服務有多個實例在運行, 每個實例可以運行在容器化平臺內, 達到平滑伸縮的效果.
- 每個服務有自己的數據存儲, 實際上, 每個服務又該有自己獨享的數據庫、緩存、信息隊列等資源.
- 每個服務應該有自己的運營平臺, 以及獨享的運營人員, 這包括技術運維和業務運營人員; 每個服務都高度自治, 內部的變化對外透明.
- 每個服務都可以根據性能需求獨立的進行水平伸縮.
通過對比微服務與傳統單體架構, 我們得知傳統單體架構具有如下特點:
- 傳統單體架構將所有模塊化組件混合後運行在同一個 JVM 進程中.
- 可對包含多個模塊化組件的整體 JVM 進程進行水平擴展, 而無法對某個模塊化組件進行水平擴展.
- 某個模塊化組件發生變化時, 需要所有模塊化組件進行編譯、打包、和上線.
- 久而久之, 模塊之間的依賴將會不清晰, 互相耦合、相互依賴成爲家常便飯.
微服務架構與 SOA 服務化的對比
微服務在 SOA 服務化的基礎上進行演進和疊加, 形成了適合現代化應用場景的一個方法論.
1.目的不同
SOA 服務化涉及的範圍更廣一些, 強調不同的異構服務之間的協作和協議, 並強調有效集成、業務流程編排、歷史應用集成等, 典型代表 Web Service 和 ESB.
微服務使用一系列的微小服務來實現整體的業務流程, 目的是有效的拆分應用, 實現敏捷開發和部署, 在每個微小服務的團隊裏, 減少了跨團的溝通, 讓專業的人做專業的事, 縮小變更和迭代影響的範圍, 並達到單一微服務更容易水平擴展的目的.
2.部署方式不同
微服務將完整的應用拆分成多個細小的服務, 通常使用敏捷擴容、縮容的 Docker 技術來實現自動化的容器管理, 每個微服務運行在單一的進程內, 微服務中的部署互相獨立、互不影響.
SOA 服務化通常將多個業務服務通過組件化模塊方式打包在一個 war 包裏, 然後統一部署在一個應用服務器上.
3.服務粒度不同
微服務倡導將服務拆分成更細的粒度, 通過多個服務組合來實現業務流程的處理, 拆分到職責單一, 甚至小到不能再進行拆分.
SOA 對粒度沒有要求, 在實戰中服務通常是粗粒度的, 強調接口協議的規範化, 內部實現可以更粗顆粒.
總結
- 微服務是新一代分佈式架構.
- 每個服務運行在單一的進程內, 獨立部署、互不影響.
- 每個服務拆分到職責單一、甚至小到不能在拆分.
- 每個服務有自己獨享的數據庫、緩存、信息隊列等資源.
- 每個服務有自己的運營平臺; 每個服務都高度自治, 內部的變化對外透明.
- 每個服務可以通過 HTTP 或底層的二進制協議、消息隊列協議等進行交互.