微服務架構
— 筆記整理自 北京理工大學 計算機學院
從Dubbo說起
備註：圖片託管於github，請確保網絡的可訪問性
單一架構
- Dubbo是阿里開源的一款高性能分佈式服務框架，致力於提供高性能透明化的RPC遠程服務調用方案以及SOA服務治理方案
- Dubbo可以和Spring系統無縫集成, 最大特點是按照分層的方式來架構，將整個框架分成10層來爲服務提供方和消費方提供各自需要關心和擴展的接口,構建整個服務生態系統
- 當一個網站很小的時候只需要一個應用就可以將所有功能都部署在一起, 可以減少部署節點和成本，這時候用於簡化增刪改查工作量的框架ORM是關鍵
垂直架構
- 當訪問量逐步增大的時候，單應用通過增加機器這樣的加速度越來越小，這時候就可以將這個應用拆成互不相干的幾個應用來提高效率，這時候用於加速前端開發的MVC業務框架是關鍵
分佈式架構
- 當垂直應用越來越多，這種應用之間的交互變得不可避免，可以將核心的業務抽取出來作爲獨立的服務，逐漸形成了穩定的服務中心，使得前端應用可以快速響應多變的市場需求
- 這時候，用於提高業務複用和整合的分佈式服務框架RPC是關鍵
彈性計算架構
- 當服務越來越多，容量的評估，消耗服務資源的浪費等問題逐漸顯露出來的時候，就需要增加一個調度中心，基於訪問壓力來時時的管理集羣容量，提高集羣利用率
- 這時候，用來提高集羣利用率的資源調度中心，就是SOA是關鍵
- 當業務的複雜性進一步增加的時候，我們可以採用什麼架構呢?
- 單應用或MVC應用都是一種應用的層面
- 從RPC到SOA出現了服務的概念
關於RPC
備註：圖片託管於github，請確保網絡的可訪問性
- RPC是遠程的過程調用
- 兩臺服務器，A和B，一個應用在A服務器上，它想要調用B服務器上的應用接口
- 由於不再一臺服務器上就需要通過網絡來實現調用
- RPC要解決的問題主要有一下幾個：
- 通訊：方法是在客戶端和服務器之間建立一個TCP的連接，遠程調用的所有數據都是在這個連接裏面傳輸，連接可以是按需連接(用完即斷), 也可以是長連接(多個遠程調用共享同一個連接)
- 尋址：A服務器上的應用，怎樣告訴底層的RPC框架如何連接到B服務器，以特定的接口，方法的名稱等
- 序列化：A服務器上的應用發起遠程調用的時候, 方法參數要通過底層網絡傳輸, 網絡協議是二進制的，參數需要進行序列化轉化成二進制的形式，這種轉變叫序列化
- 反序列化：B服務器收到請求後，需要對參數進行反序列化，恢復爲內存中的表達形式, 找到對應方法進行本地調用得到返回值,返回值通過序列化和反序列化的方式返回A服務器
- 實現RPC服務的協議
- CORBA、Java RMI
- Web Service、Rest API
- …
關於SOA
備註：圖片託管於github，請確保網絡的可訪問性
- SOA是一個面向服務的體系結構模型，它將應用程序的不同功能單元(服務)，通過服務之間定義良好的接口和契約來聯繫起來
- 接口是採用中立的方式來定義的，應獨立於實現服務的軟硬件平臺，操作系統，編程語言，這就使得構建在各個系統中的服務可以以一種統一的和通用的方式進行調度
- SOA架構中的三種角色
- 服務提供者：發佈自己的服務，對服務的請求進行響應
- 服務註冊中心：註冊已經發布的web服務, 對他們進行分類並提供搜索服務
- 服務請求者：利用服務中心來查找所需要的服務並使用這個服務
- SOA操作
- 發佈操作：爲了使服務可訪問，需要發佈服務的描述，以使服務的使用者可以發現它
- 查找操作：服務的請求者來定位服務，方法是查詢服務註冊中心來找到滿足它標準的服務
- 綁定操作：在檢索到服務之後，服務的使用者繼續根據服務描述中的信息來處理服務
- SOA需要使用三種協議(相關標準)
- SOAP(簡單對象訪問協議)：作爲傳輸層，用於消費者和服務提供者之間傳遞信息
- 一個消費者在UDDI註冊查找服務，取得服務的WSDL描述，通過SOAP來調用這個服務
- WSDL(web服務描述語言)：用於描述服務
- UDDI(統一描述發現集成)：用於註冊和查找服務
- SOAP(簡單對象訪問協議)：作爲傳輸層，用於消費者和服務提供者之間傳遞信息
從SOA到微服務
- SOA將緊耦合系統拆解爲面向服務的，粗粒度的，松耦合無狀態的服務
- SOA致力於將單個應用程序的功能彼此分開，以便這些功能可以作爲單個應用程序的功能或組件
- 這些組件可用於企業內部創建其他應用程序或者對外向合作者公開提供服務
- 企業服務總線ESB(Enterprise Service Bus)簡化了應用間的管理
- 是傳統的中間件技術與sml，web服務等技術結合的產物
- ESB是構建企業神經系統的必要元素
- ESB利用總線這種模式來管理簡化應用之間的集成拓撲結構
- 以廣爲接受的開放標準作爲基礎來支持應用之間消息事件，服務級別動態上互通互聯
- 是一種在鬆散耦合的服務和應用之間標準的集成方式
- 微服務對業務系統進行了更加徹底的組件化和服務化
- 單業務進一步拆分：原有單個業務系統可拆分爲多個, 可獨立開發，設計，運行和維護的小應用
- 這些小應用之間通過服務進行集成和交互
- 每個小應用從前端UI到控制層,邏輯層,數據訪問,數據庫完全是獨立的一套
- 在這裏不用組件，而用小應用這個詞更加合適
- 每個小應用除了完成自身的業務功能之外，重點是消費外部其他應用所暴露的服務
- 同時將自己的能力向外提供服務
微服務
- 在服務架構中，一組服務構成一個應用, 服務獨立部署在不同進程中
- 不同服務間通過輕量級的交互機制來通信，如：RPC，HTTP等
- 服務可以擴展和伸縮，每個服務定義了明確的邊界，不同服務可採用不同的編程語言來實現，由獨立團隊來維護
- 微服務的目的是有效的拆分應用，實現敏捷開發和部署(單個服務的變化只需重新部署服務的進程, 不影響整個應用的運行)
- 什麼是微服務(Microservices)
- 微服務架構按照業務功能劃分爲不同的服務
- 每個服務要求在對應的業務領域中從前端到後端整個的軟件實現，從界面到數據，存儲再到外部溝通協作等
- 微服務的特徵：是按業務能力來劃分服務和組織團隊的
- 微服務與DevOps
- 微服務需要DevOps，也就是開發，測試，部署運維等一體化支持
- 當單體應用被拆分爲多個小應用之後, 整體架構可以松耦合和可擴展
- 如果拆分的組件越多，這些組件之間本身的集成，部署運維就越複雜
- 需要強化DevOps的應用才能更好的完成測試和部署工作
- 進程隔離
- 微服務架構強調各個組件本身可以在獨立的進程裏工作
- 各個組件之間在部署的時候就能做到進程級別的隔離
- 虛擬機技術無法滿足大量的進程隔離的時候，就可以使用輕量級的docker來完成
- 每個docker是獨立的容器剛好做到了進程級別的隔離，資源佔用最小
- 這些條件剛好滿足微服務架構的開發測試和自動化部署
- 簡化的SOA服務管理(服務管控平臺)
- 所有微服務需要一個服務管控，治理平臺，雖然不需要ESB這類重組件
- 但是要保證最基本的服務註冊，服務代理，服務發佈，簡單的路由, 安全訪問和授權，服務調度消息和日誌等功能
微服務的優勢
- 解決了複雜性問題
- 分解巨大的單體應用爲多個服務
- 在功能不變情況下，應用被分解爲多個可管理的服務
- 每個服務通過RPC或者消息驅動API定義清楚的邊界
- 提供了一個模塊化的解決方案
- 開發分工更加靈活
- 每個服務可由單獨的開發團隊來開發
- 可自由的選用開發技術來提供API服務
- 自由表示不需要被迫使用開始的落後技術
- 單個服務相對簡單，用現在技術來重寫以前的代碼也不是一件很困難的事情
- 每個微服務獨立部署
- 開發者不再需要協調其他的服務部署對本服務的影響
- 加快部署的速度，可採用AB測試快速部署變化
- 微服務使得持續化部署成爲可能
- 每個微服務可獨立擴展
- 開發者可根據每個服務的規模來部署滿足需求的規模
- 開發者可使用更適合服務需求的硬件
微服務的不足
- 服務過小
- 分佈式系統固有的複雜性
- 分區數據庫方案
- 測試複雜
- 微服務之間的依賴傳遞
- 部署複雜
總結
- 微服務的目的是有效拆分應用來實現軟件的開發和部署，微服務是去中心化的分佈式軟件架構
- 對於業務還沒有理清楚，業務數據處理能力還沒有爆發式增長之前的創業公司不需要考慮微服務架構模式，更需要的是快速開發，部署和試錯
SOA與微服務的比較
| 功能 | SOA | 微服務 |
|---|---|---|
| 組件大小 | 大塊業務邏輯 | 單獨任務或小塊業務邏輯 |
| 耦合 | 通常松耦合 | 總是松耦合 |
| 公司架構 | 任何類型 | 小型、專注於功能交叉的團隊 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目標 | 確保應用能夠交互操作 | 執行新功能，快速拓展開發團隊 |
擴展
下圖是一個精彩的微服務架構
備註：圖片託管於github，請確保網絡的可訪問性