目錄
下圖是Conduit Service Mesh（現在已合併到Linkerd2中了）的架構圖，這是Service Mesh的一種典型的架構。
圖片 - 服務網格架構示意圖
服務網格中分爲控制平面和數據平面，當前流行的兩款開源的服務網格 Istio 和 Linkerd 實際上都是這種構造，只不過 Istio 的劃分更清晰，而且部署更零散，很多組件都被拆分，控制平面中包括 Mixer、Pilot、Citadel，數據平面默認是用Envoy；而 Linkerd 中只分爲 Linkerd 做數據平面，namerd 作爲控制平面。
控制平面
控制平面的特點：
- 不直接解析數據包
- 與控制平面中的代理通信，下發策略和配置
- 負責網絡行爲的可視化
- 通常提供API或者命令行工具可用於配置版本化管理，便於持續集成和部署
數據平面
數據平面的特點：
- 通常是按照無狀態目標設計的，但實際上爲了提高流量轉發性能，需要緩存一些數據，因此無狀態也是有爭議的
- 直接處理入站和出站數據包，轉發、路由、健康檢查、負載均衡、認證、鑑權、產生監控數據等
- 對應用來說透明，即可以做到無感知部署
參考
服務網格的實現模式
我們在前面看到了通過客戶端庫來治理服務的架構圖，那是我們在改造成Service Mesh架構前使用微服務架構通常的形式，下圖是使用Service Mesh架構的最終形式。
圖片 - Service Mesh 架構示意圖
當然在達到這一最終形態之前我們需要將架構一步步演進，下面給出的是參考的演進路線。
Ingress或邊緣代理
如果你使用的是Kubernetes做容器編排調度，那麼在進化到Service Mesh架構之前，通常會使用Ingress Controller，做集羣內外流量的反向代理，如使用Traefik或Nginx Ingress Controller。
圖片 - Ingress 或邊緣代理架構示意圖
這樣只要利用Kubernetes的原有能力，當你的應用微服務化並容器化需要開放外部訪問且只需要L7代理的話這種改造十分簡單，但問題是無法管理服務間流量。
路由器網格
Ingress或者邊緣代理可以處理進出集羣的流量，爲了應對集羣內的服務間流量管理，我們可以在集羣內加一個Router層，即路由器層，讓集羣內所有服務間的流量都通過該路由器。
圖片 - 路由器網格架構示意圖
這個架構無需對原有的單體應用和新的微服務應用做什麼改造，可以很輕易的遷移進來，但是當服務多了管理起來就很麻煩。
Proxy per Node
這種架構是在每個節點上都部署一個代理，如果使用Kubernetes來部署的話就是使用DaemonSet對象，Linkerd第一代就是使用這種方式部署的，一代的Linkerd使用Scala開發，基於JVM比較消耗資源，二代的Linkerd使用Go開發。
圖片 - Proxy per node 架構示意圖
這種架構有個好處是每個節點只需要部署一個代理即可，比起在每個應用中都注入一個sidecar的方式更節省資源，而且更適合基於物理機/虛擬機的大型單體應用，但是也有一些副作用，比如粒度還是不夠細，如果一個節點出問題，該節點上的所有服務就都會無法訪問，對於服務來說不是完全透明的。
Sidecar代理/Fabric模型
這個一般不會成爲典型部署類型，當企業的服務網格架構演進到這一步時通常只會持續很短時間，然後就會增加控制平面。跟前幾個階段最大的不同就是，應用程序和代理被放在了同一個部署單元裏，可以對應用程序的流量做更細粒度的控制。
圖片 - Sidecar代理/Fabric模型示意圖
這已經是最接近Service Mesh架構的一種形態了，唯一缺的就是控制平面了。所有的sidecar都支持熱加載，配置的變更可以很容易的在流量控制中反應出來，但是如何操作這麼多sidecar就需要一個統一的控制平面了。
Sidecar代理/控制平面
下面的示意圖是目前大多數Service Mesh的架構圖，也可以說是整個Service Mesh架構演進的最終形態。
圖片 - Sidecar 代理/控制平面架構示意圖
這種架構將代理作爲整個服務網格中的一部分，使用Kubernetes部署的話，可以通過以sidecar的形式注入，減輕了部署的負擔，可以對每個服務的做細粒度權限與流量控制。但有一點不好就是爲每個服務都注入一個代理會佔用很多資源，因此要想方設法降低每個代理的資源消耗。
多集羣部署和擴展
以上都是單個服務網格集羣的架構，所有的服務都位於同一個集羣中，服務網格管理進出集羣和集羣內部的流量，當我們需要管理多個集羣或者是引入外部的服務時就需要網格擴展和多集羣配置。
Istio 架構解析
下面是以漫畫的形式說明 Istio 是什麼。
該圖中描繪了以下內容：
- Istio 可以在虛擬機和容器中運行
- Istio 的組成
- Pilot：服務發現、流量管理
- Mixer：訪問控制、遙測
- Citadel：終端用戶認證、流量加密
- Service mesh 關注的方面
- 可觀察性
- 安全性
- 可運維性
- Istio 是可定製可擴展的，組建是可拔插的
- Istio 作爲控制平面，在每個服務中注入一個 Envoy 代理以 Sidecar 形式運行來攔截所有進出服務的流量，同時對流量加以控制
- 應用程序應該關注於業務邏輯（這才能生錢），非功能性需求交給 Service Mesh