## 采納和演進 **注意：本書中的 Service Mesh 章節已不再維護，請轉到 [istio-handbook](https://jimmysong.io/istio-handbook) 中瀏覽。** 沒有人會一下子采納Service Mesh架構的所有組件，或者一次性將所有的應用都改造成Service Mesh的，都是漸漸式采納，從非核心系統開始改造。采納Service Mesh就兩種路徑： - 全盤采納：通常對于新應用來說才會這樣做，也叫做Greenfiled項目 - 漸進式采納：舊系統改造，也叫做Brownfiled項目 通過價值驅動、開發人員的接受程度、自底向上的選擇你最急切需要的功能，可能是可觀察性或RPC的負載均衡等等，先采納部分功能，然后通過漸漸式的方式來演進。 **架構演進** 我們在前面看到了通過**客戶端庫**來治理服務的架構圖，那是我們在改造成Service Mesh架構前使用微服務架構通常的形式，下圖是使用Service Mesh架構的最終形式。  當然在達到這一最終形態之前我們需要將架構一步步演進，下面給出的是參考的演進路線。 ### Ingress或邊緣代理 如果你使用的是Kubernetes做容器編排調度，那么在進化到Service Mesh架構之前，通常會使用Ingress Controller，做集群內外流量的反向代理，如使用Traefik或Nginx Ingress Controller。  這樣只要利用Kubernetes的原有能力，當你的應用微服務化并容器化需要開放外部訪問且只需要L7代理的話這種改造十分簡單，但問題是無法管理服務間流量。 ### 路由器網格 Ingress或者邊緣代理可以處理進出集群的流量，為了應對集群內的服務間流量管理，我們可以在集群內加一個`Router`層，即路由器層，讓集群內所有服務間的流量都通過該路由器。  這個架構無需對原有的單體應用和新的微服務應用做什么改造，可以很輕易的遷移進來，但是當服務多了管理起來就很麻煩。 ### Proxy per Node 這種架構是在每個節點上都部署一個代理，如果使用Kubernetes來部署的話就是使用`DaemonSet`對象，Linkerd第一代就是使用這種方式部署的，一代的Linkerd使用Scala開發，基于JVM比較消耗資源，二代的Linkerd使用Go開發。  這種架構有個好處是每個節點只需要部署一個代理即可，比起在每個應用中都注入一個sidecar的方式更節省資源，而且更適合基于物理機/虛擬機的大型單體應用，但是也有一些副作用，比如粒度還是不夠細，如果一個節點出問題，該節點上的所有服務就都會無法訪問，對于服務來說不是完全透明的。 ### Sidecar代理/Fabric模型 這個一般不會成為典型部署類型，當企業的服務網格架構演進到這一步時通常只會持續很短時間，然后就會增加控制平面。跟前幾個階段最大的不同就是，應用程序和代理被放在了同一個部署單元里，可以對應用程序的流量做更細粒度的控制。  這已經是最接近Service Mesh架構的一種形態了，唯一缺的就是控制平面了。所有的sidecar都支持熱加載，配置的變更可以很容易的在流量控制中反應出來，但是如何操作這么多sidecar就需要一個統一的控制平面了。 ### Sidecar代理/控制平面 下面的示意圖是目前大多數Service Mesh的架構圖，也可以說是整個Service Mesh架構演進的最終形態。  這種架構將代理作為整個服務網格中的一部分，使用Kubernetes部署的話，可以通過以sidecar的形式注入，減輕了部署的負擔，可以對每個服務的做細粒度權限與流量控制。但有一點不好就是為每個服務都注入一個代理會占用很多資源，因此要想方設法降低每個代理的資源消耗。 ### 多集群部署和擴展 以上都是單個服務網格集群的架構，所有的服務都位于同一個集群中，服務網格管理進出集群和集群內部的流量，當我們需要管理多個集群或者是引入外部的服務時就需要[網格擴展](https://preliminary.istio.io/zh/docs/setup/kubernetes/mesh-expansion/)和[多集群配置](https://preliminary.istio.io/zh/docs/setup/kubernetes/multicluster-install/)。