什麼是服務網格？
服務網格是用於處理服務間通信的專用基礎設施層。它負責通過包含現代雲原生應用程序的複雜服務拓撲來可靠地傳遞請求。實際上，服務網格通常通過一組輕量級網絡代理來實現，這些代理與應用程序代碼一起部署，而不需要感知應用程序本身。
服務網格的特點
服務網格有如下幾個特點：
- 應用程序間通訊的中間層
- 輕量級網絡代理
- 應用程序無感知
- 解耦應用程序的重試/超時、監控、追蹤和服務發現
理解服務網格
如果用一句話來解釋什麼是服務網格，可以將它比作是應用程序或者說微服務間的 TCP/IP，負責服務之間的網絡調用、限流、熔斷和監控。
服務網格的架構如下圖所示：
爲何使用服務網格？
服務網格並沒有給我們帶來新功能，它是用於解決其他工具已經解決過的問題，只不過這次是在雲原生的 Kubernetes 環境下的實現。
在傳統的 MVC 三層 Web 應用程序架構下，服務之間的通訊並不複雜，在應用程序內部自己管理即可，但是在現今的複雜的大型網站情況下，單體應用被分解爲衆多的微服務，服務之間的依賴和通訊十分複雜，出現了 twitter 開發的 Finagle、Netflix 開發的 Hystrix 和 Google 的 Stubby 這樣的 “胖客戶端” 庫，這些就是早期的服務網格，但是它們都僅適用於特定的環境和特定的開發語言，並不能作爲平臺級的服務網格支持。
在雲原生架構下，容器的使用給予了異構應用程序的更多可行性，Kubernetes 增強的應用的橫向擴容能力，用戶可以快速的編排出複雜環境、複雜依賴關係的應用程序，同時開發者又無須過多關心應用程序的監控、擴展性、服務發現和分佈式追蹤這些繁瑣的事情而專注於程序開發，賦予開發者更多的創造性。
服務網格架構
服務網格中分爲控制平面和數據平面，當前流行的兩款開源的服務網格 Istio 和 Linkerd 實際上都是這種架構，只不過 Istio 的劃分更清晰，而且部署更零散，很多組件都被拆分，控制平面中包括 Mixer、Pilot、Citadel，數據平面默認是用 Envoy；而 Linkerd 中只分爲 Linkerd 做數據平面，namerd 作爲控制平面。
控制平面的特點
- 不直接解析數據包
- 與數據平面中的代理通信，下發策略和配置
- 負責網絡行爲的可視化
- 通常提供 API 或者命令行工具可用於配置版本化管理，便於持續集成和部署
數據平面的特點
- 通常是按照無狀態目標設計的，但實際上爲了提高流量轉發性能，需要緩存一些數據，因此無狀態也是有爭議的
- 直接處理入站和出站數據包，轉發、路由、健康檢查、負載均衡、認證、鑑權、產生監控數據等
- 對應用來說透明，即可以做到無感知部署
服務網格的實現模式
Service Mesh 架構示意圖：
Istio 架構解析
- Istio 是獨立於平臺的，可以在 Kubernetes 、 Consul 、虛擬機上部署的服務
- Istio 的組成
- Envoy：智能代理、流量控制
- Pilot：服務發現、流量管理
- Mixer：訪問控制、遙測
- Citadel：終端用戶認證、流量加密
- Galley（1.1新增）：驗證、處理和分配配置
- Service mesh 關注的方面
- 可觀察性
- 安全性
- 可運維性
- 可拓展性
- Istio 的策略執行組件可以擴展和定製，同時也是可拔插的
- Istio 在數據平面爲每個服務中注入一個 Envoy 代理以 Sidecar 形式運行來劫持所有進出服務的流量，同時對流量加以控制，通俗的講就是應用程序你只管處理你的業務邏輯，其他的事情 Sidecar 會彙報給 Istio 控制平面處理
- 應用程序只需關注於業務邏輯（這才能生錢）即可，非功能性需求交給 Istio
設計目標
- 最大化透明度
- 可擴展性
- 可移植性
- 策略一致性
從邊車模式到 Service Mesh
什麼是邊車模式
Deploy components of an application into a separate process or container to provide isolation and encapsulation.
— Sidecar pattern
邊車模式設計
有兩種方法來實現邊車模式：
- 通過 SDK、Lib 等軟件包的形式，在開發時引入該軟件包依賴，使其與業務服務集成起來。
- 以 Sidecar 的形式，在運維的時候與應用服務集成在一起。
邊車模式解決了什麼問題
- 控制與邏輯分離的問題
- 業務代碼只需要關心其複雜的業務邏輯
- 日誌記錄、監控、流量控制、服務註冊、服務發現、服務限流、服務熔斷、鑑權、訪問控制等交給邊車
- 解決服務之間調用越來越複雜的問題
- 隨着分佈式架構越來越複雜和微服務越拆越細，我們越來越迫切的希望有一個統一的控制面來管理我們的微服務，來幫助我們維護和管理所有微服務
從邊車模式到 Service Mesh
遵循邊車模式進行實踐從很早以前就開始了，開發人員一直試圖將服務治理等通用功能提取成一個標準化的 Sidecar ，通過 Sidecar 代理來與其他系統進行交互，這樣可以大大簡化業務開發和運維。而隨着分佈式架構和微服務被越來越多的公司和開發者接受並使用，這一需求日益凸顯。這就是 Service Mesh 服務網格誕生的契機，它是 CNCF（Cloud Native Computing Foundation，雲原生基金會）目前主推的新一代微服務架構。
Service Mesh 將底層那些難以控制的網絡通訊統一管理，諸如：流量管控，丟包重試，訪問控制等。而上層的應用層協議只需關心業務邏輯即可。Service Mesh 是一個用於處理服務間通信的基礎設施層，它負責爲構建複雜的雲原生應用傳遞可靠的網絡請求。
Kubernetes vs Service Mesh
Kubernetes 管理的對象是 Pod，Service Mesh 中管理的對象是 Service。
- Kubernetes 的本質是應用的生命週期管理，具體來說就是部署和管理（擴縮容、自動恢復、發佈）。
- Kubernetes 爲微服務提供了可擴展、高彈性的部署和管理平臺。
- Service Mesh 的基礎是透明代理，通過 sidecar proxy 攔截到微服務間流量後再通過控制平面配置管理微服務的行爲。
- Service Mesh 將流量管理從 Kubernetes 中解耦，Service Mesh 內部的流量無需 kube-proxy 組件的支持，通過爲更接近微服務應用層的抽象，管理服務間的流量、安全性和可觀察性。
- Service Mesh 是對 Kubernetes 中的 service 更上層的抽象，它的下一步是 serverless。
本文是針對ServiceMesher社區系列文章而整理的學習筆記，文章地址：https://www.servicemesher.com/istio-handbook/intro/service-mesh-the-microservices-in-post-kubernetes-era.html