參考：微信公眾號:架構師之路
ServiceMesh(1)
ServiceMesh究竟解決什么問題？
服務網格（ServiceMesh）這兩年異常之火，號稱是下一代微服務架構，接下來兩個月，准備系統性的寫寫這個東西，希望能夠讓大家對最新的架構技術，有個初步的了解。
畫外音：我的行文的風格了，“為什么”往往比“怎么樣”更重要。
互聯網公司，經常使用的是微服務分層架構。
畫外音：為什么要服務化，詳見《服務化到底解決什么問題？》。
隨着數據量不斷增大，吞吐量不斷增加，業務越來越復雜，服務的個數會越來越多，分層會越來越細，除了數據服務層，還會衍生出業務服務層，前后端分離等各種層次結構。
畫外音：分層的細節，詳見《互聯網分層架構演進》。
不斷發現主要矛盾，抽離主要矛盾，解決主要矛盾，架構自然演進了，微服務架構，潛在的主要矛盾會是什么呢？
引入微服務架構，一般會引入一個RPC框架，來完成整個RPC的調用過程。
如上圖粉色部分所示，RPC分為：
-
RPC-client，它嵌在調用方進程里
-
RPC-server，是服務進程的基礎
畫外音：《離不開的微服務架構，脫不開的RPC細節》。
不只是微服務，MQ也是類似的架構：
如上圖粉色部分所示，MQ分為：
-
MQ-send-client
-
MQ-server
-
MQ-recv-client
畫外音：《MQ，互聯網架構解耦神器》。
框架只是第一步，越來越多和RPC，和微服務相關的功能，會被加入進來。
例如：負載均衡
如果要擴展多種負載均衡方案，例如：
-
輪詢
-
隨機
-
取模
-
一致性哈希
RPC-client需要進行升級。
例如：數據收集
如果要對RPC接口處理時間進行收集，來實施統一監控與告警，也需要對RPC-client進行升級。
畫外音，處理時間分為：
-
客戶端視角處理時間
-
服務端視角處理時間
如果要收集后者，RPC-server也要修改與上報。
又例如：服務發現
服務新增一個實例，通知配置中心，配置中心通知已注冊的RPC-client，將流量打到新啟動的服務實例上去，迅猛完成擴容。
再例如：調用鏈跟蹤
如果要做全鏈路調用鏈跟蹤，RPC-client和RPC-server都需要進行升級。
下面這些功能：
-
負載均衡
-
數據收集
-
服務發現
-
調用鏈跟蹤
-
…
其實都不是業務功能，所以互聯網公司一般會有一個類似於“架構部”的技術部門去研發和升級相關功能，而業務線的技術部門直接使用相關框架、工具與平台，享受各種“黑科技”帶來的便利。
完美！！！
理想很豐滿，現實卻很骨感，由於：
-
RPC-client，它嵌在調用方進程里
-
RPC-server，是服務進程的基礎
往往會面臨以下一些問題：
-
業務技術團隊，仍需要花時間去學習、使用基礎框架與各類工具，而不是全心全意將精力花在業務和產品上
-
client要維護m個版本， server要維護n個版本，兼容性要測試m*n個版本
-
如果要支持不同語言，往往要開發C-client，Python-client，go-client，Java-client多語言版本
-
每次“黑科技”的升級，都需要推動上下游進行升級，這個周期往往是以季度、半年、又甚至更久，整體效率極低
畫外音：兄弟，貴司推廣一個技術新產品，周期要多長？
這些耦合，這些通用的痛點，有沒有辦法解決呢？
一個思路是，將服務拆分成兩個進程，解耦。
-
一個進程實現業務邏輯（不管是調用方，還是服務提供方），biz，即上圖白色方塊
-
一個進程實現底層技術體系，proxy，即上圖藍色方塊
畫外音：負載均衡、監控告警、服務發現與治理、調用鏈…等諸多基礎設施，都放到這一層實現。
-
biz和proxy共同誕生，共同消亡，互為本地部署，即上圖虛線方框
-
biz和proxy之間，為本地通訊，即上圖黑色箭頭
-
所有biz之間的通訊，都通過proxy之間完成，proxy之間才存在遠端連接，即上圖紅色箭頭
這樣就實現了“業務的歸業務，技術的歸技術”，實現了充分解耦，如果所有節點都實現了解耦，整個架構會演變為：
-
綠色為biz
-
藍色為proxy
整個服務集群變成了網格狀，這就是Service Mesh服務網格的由來。
架構演進，永無窮盡，痛點多了，自然要分層解耦。希望大家有收獲，后續再細聊SM的設計與架構細節。
思路比結論更重要。
ServiceMesh(2)
Istio究竟是干嘛的？
上一篇介紹了《ServiceMesh究竟解決什么問題？》，當微服務架構體系越來越復雜的時候，需要將“業務服務”和“基礎設施”解耦，將一個微服務進程一分為二：
-
一個進程實現業務邏輯，biz，即上圖白色方塊
-
一個進程實現底層技術體系，proxy，即上圖藍色方塊，負載均衡、監控告警、服務發現與治理、調用鏈…等諸多基礎設施，都放到這一層實現
如此解耦之后：
-
biz不管是調用服務，還是提供服務，都只與本地的proxy進行本地通信
-
所有跨網的通信，都通過proxy之間進行
要聊ServiceMesh，就不得不提Istio，它是ServiceMesh目前最流行的實踐，今天說說Istio是干啥的。
畫外音：不能落伍。
什么是Istio？
Istio是ServiceMesh的產品化落地，它的一些關鍵性描述是：
-
幫助微服務之間建立連接，幫助研發團隊更好的管理與監控微服務，並使得系統架構更加安全
畫外音：Istio helps you to connect, secure, control, and observe microservices.
-
幫助微服務分層解耦，解耦后的proxy層能夠更加專注於提供基礎架構能力，例如：
（1）服務發現(discovery);
（2）負載均衡(load balancing);
（3）故障恢復(failure recovery);
（4）服務度量(metrics);
（5）服務監控(monitoring);
（6）A/B測試(A/B testing);
（7）灰度發布(canary rollouts);
（8）限流限速(rate limiting);
（9）訪問控制(access control);
（10）身份認證(end-to-end authentication);
畫外音：佩服，硬是湊齊了十條，其實SM還能提供更多基礎服務功能。
-
使得業務工程團隊與基礎架構團隊都更加高效的工作，各自專注於自己的工作，更好的彼此賦能
畫外音：說的還是解耦。
Istio官網是怎么吹噓自己的？
畫外音：這個問題的另一個問法是“為什么大家要來用Istio”。
Istio非常牛逼，如果要實施ServiceMesh，必須用Istio，因為：
-
可以通過，在現有服務器新增部署邊車代理(sidecar proxy)，應用程序不用改代碼，或者只需要改很少的代碼，就能實現上述N項基礎功能
畫外音：你信了么？
-
可以通過，控制后台，簡單改改配置，點點按鈕，就能管理和查看上述N項基礎功能
-
以下特性，Istio在這個環節里進行了附加說明：
（1）負載均衡支持多協議，HTTP, gRPC, WebSocket, TCP；
（2）通過路由、重試、故障轉移對流量進行細粒度流控；
（3）通過可插拔策略層以及可配置API，能夠支持流量訪問控制、限速、配額管理；
（4）自動度量、日志收集、調用跟蹤；
（5）服務到服務的身份認證；
Istio的核心特性是什么？
Istio強調了它提供的五項關鍵特性：
-
流控(traffic management)
畫外音：斷路器(circuit breakers)、超時、重試、高可用、多路由規則、AB測試、灰度發布、按照百分比分配流量等。
-
安全(security)
畫外音：加密、身份認證、服務到服務的權限控制、K8S里容器到容器的權限控制等。
-
可觀察(observability)
畫外音：追蹤、監控、數據收集，通過控制后台全面了解上行下行流量，服務鏈路情況，服務運行情況，系統性能情況，國內微服務架構體系，這一塊做得比較缺乏。
-
平台無關系(platform support)
畫外音：K8s，物理機，自己的虛機都沒問題。
-
集成與定制(integration and customization)
畫外音：可定制化擴展功能。
Istio的吹噓與特性，對於國外很多通過RESTful提供內網服務的公司，很有吸引力，但相對於國內微服務架構，未必達到了很好的拉攏效果：
（1）國內基本都是TCP的RPC框架，多協議支持未必是必須的；
（2）RPC框架里，路由、重試、故障轉移、負載均衡、高可用都是最基礎的；
（3）流控、限速、配額管理，是服務治理的內容，在微服務架構初期是錦上添花；
（4）自動度量，系統入口出口數據收集，調用跟蹤，可觀察和可操控的后台確實是最吸引人的；
（5）服務到服務的身份認證，微服務基本是內網訪問，在架構初期也只是錦上添花；
另外一個花邊，為什么代理會叫sidecar proxy？
看了上圖就容易懂了，biz和proxy相生相伴，就像摩托車(motor)與旁邊的車廂(sidecar)。未來，sidecar和proxy就指微服務進程解耦成兩個進程之后，提供基礎能力的那個代理進程。
Istio這么牛逼，它的核心架構如何呢？
且聽下回分解。
ServiceMesh(3)
Istio分層架構？80%的人有誤解
前篇：
Istio是ServiceMesh的產品化落地：
-
它幫助微服務之間建立連接，幫助研發團隊更好的管理與監控微服務，並使得系統架構更加安全
-
它幫助微服務分層解耦，解耦后的proxy層能夠更加專注於提供基礎架構能力，例如：
（1）服務發現(discovery)
（2）負載均衡(load balancing)
（3）故障恢復(failure recovery)
（4）服務度量(metrics)
（5）服務監控(monitoring)
（6）A/B測試(A/B testing)
（7）灰度發布(canary rollouts)
（8）限流限速(rate limiting)
（9）訪問控制(access control)
（10）身份認證(end-to-end authentication)
等功能。
-
它使得業務工程團隊與基礎架構團隊都更加高效的工作，各自專注於自己的工作，更好的彼此賦能
今天來說一下Istio的核心架構設計。
關於Istio的架構設計，官網用了這樣一句話：
邏輯上，Istio分為：
-
數據平面(data plane)
-
控制平面(control plane)
這兩個詞，是Istio架構核心，但又是大家被誤導最多的地方。
數據平面和控制平面，不是ServiceMesh和Istio第一次提出，它是計算機網絡，報文路由轉發里很成熟的概念：
-
數據平面(data plane)：一般用來做快速轉發
-
控制平面(control plane)：為快速轉發提供必要的信息
畫外音：上兩圖為路由器架構。
它的設計原則是：
-
在一個路由設備里，轉發是最重要的工作，它具備最高的優先級，數據平面(data plane)的設計核心就是高效轉發，如何在最短的時間里處理最多的包，往往使用高效內存管理、隊列管理、超時管理等技術實現在硬件里
-
控制平面(control plane)則不然，它要實現路由協議，設備管理，IGMP，ARP協議的，它更偏向於控制與應用，往往由軟件實現
畫外音：
IGMP（Internet GroupManagement Protocol），一個組播協議；
ARP（Address ResolutionProtocol），這個大家比較熟悉，根據IP地址獲取MAC地址；
Istio的架構核心與路由器非常類似：
-
服務（最上面的小紅框），通過本地通訊與proxy交互
-
數據平面，由一系列proxy組成（中間一層的兩個小紅框），核心職責是：
（1）高效轉發；
（2）接收和實施來自mixer的策略；
-
控制平面（底下的大紅框），核心是控制與應用，核心職責是：
（1）管理和配置邊車代理；
（2）通過mixer實施策略與收集來自邊車代理的數據；
畫外音：
（1）sidecar proxy，原文使用的是envoy，后文envoy表示代理；
（2）mixer，不確定要怎么翻譯了，有些文章叫“混音器”，后文直接叫mixer；
（3）pilot，galley，citadel，不敢翻譯為飛行員，廚房，堡壘，后文直接用英文；
如架構圖所示，該兩層架構中，有五個核心組件。
數據平面，有一個核心組件：
Envoy (proxy)
Envoy的核心職責是高效轉發，更具體的，它具備這樣一些能力：
（1）服務發現
（2）負載均衡
（3）安全傳輸
（4）多協議支持，例如HTTP/2，gRPC
（5）斷路器(Circuit breakers)
（6）健康檢查
（7）百分比分流路由
（8）故障注入(Fault injection)
（9）系統度量
大部分能力是RPC框架都具備，或者比較好理解的，這里面重點介紹下斷路器和故障注入。
斷路器設計
它是軟件架構設計中，一個服務自我保護，或者說降級的設計思路。
舉個例子：當系統檢測出某個接口有大量超時時，斷路器策略可以終止對這個接口的調用（斷路器打開），經過一段時間后，再次嘗試調用，如果接口不再超時，則慢慢恢復調用（斷路器關閉）。
故障注入設計
它是軟件架構設計中，一種故意引入故障，以擴大測試覆蓋范圍，保障系統健壯性的方法，主要用於測試。
國內大部分互聯網公司，架構設計中不太會考慮故障注入，在操作系統內核開發與調試，路由器開發與調試中經常使用，可以用來模擬內存分配失敗、磁盤IO錯誤等一些非常難出現的異常，以確保測試覆蓋度。
控制平面，有四個核心組件：
Mixer
Mixer的一些核心能力是：
（1）跨平台，作為其他組件的adapter，實現Istio跨平台的能力；
（2）和Envoy通訊，實時各種策略
（3）和Envoy通訊，收集各種數據
Mixer的設計核心在於“插件化”，這種模型使得Istio能夠適配各種復雜的主機環境，以及后端基礎設施。
Pilot
Pilot作為非常重要的控制平面組件，其核心能力是：
（1）為Envoy提供服務發現能力；
（2）為Envoy提供各種智能路由管理能力，例如A/B測試，灰度發布；
（3）為Envoy提供各種彈性管理能力，例如超時，重試，斷路策略；
Pilot的設計核心在於“標准化”，它會將各種流控的控制命令轉化為Envoy能夠識別的配置，並在運行時，將這些指令擴散到所有的Envoy。Pilot將這些能力抽象成通用配置的好處是，所有符合這種標准的Envoy都能夠接入到Pilot來。
潛台詞是，任何第三方可以實現自己的proxy，只要符合相關的API標准，都可以和Pilot集成。
Citadel
Citadel組件，它提供終端用戶身份認證，以及服務到服務的訪問控制。總之，這是一個和安全相關的組件。
Galley
Gally組件，它是一個配置獲取、校驗、處理、分發的組件，它的設計核心在於“解耦”，它將“從底層平台（例如：K8S）獲取用戶配置”與Istio解耦開來。
花邊：為什么80%的中文用戶對Istio的二層架構的了解是錯的？
很多朋友問我，通過什么渠道學習最新的技術知識，我的回答一直是，英文官網。
畫外音：本文所有信息來源於Istio1.1英文官網。
我在百度搜了下Istio，80%的資料，將二層架構翻譯為：
-
數據面板
-
控制面板
畫外音：大家可以百度搜一下“istio 控制面板”
一開始我極其蒙圈，因為“數據平面”和“控制平面”是非常成熟的翻譯，路由器就是使用這個二層架構，ServiceMesh使用相同的架構設計進行解耦，應該不需要創造性翻譯呀。
后來，我懂了：
-
控制平面(control plane)
-
控制面板(control panel)
半吊子英語的程序員，二手的技術文檔，真害人，唉。
總結
Istio采用二層架構，五大模塊，進行微服務ServiceMesh解耦：
-
數據平面，主要負責高效轉發
（1）envoy模塊：即proxy；
-
控制平面，主要負責控制與應用
（2）mixer模塊：支持跨平台，標准化API的adapter；
（3）pilot模塊：控制與配置envoy的大部分策略；
（4）citadel模塊：安全相關；
（5）galley模塊：與底層平台（例如：K8S）配置解耦；
實施與控制分離，經典的架構設計方法，GOT？
思路比結論重要。
Istio，灰度發布從未如此輕松
三個問題，回顧前情提要。
ServiceMesh解決什么問題？
SM本質是業務服務與底層技術體系的解耦：
-
一個進程實現業務邏輯（不管是調用方，還是服務提供方），biz，即上圖白色方塊
-
一個進程實現底層技術體系，proxy，即上圖藍色方塊
畫外音：負載均衡、監控告警、服務發現與治理、調用鏈…等諸多基礎設施，都放到這一層實現。
什么是Istio？
Istio是ServiceMesh的產品化落地。
Istio的分層架構設計如何？
Istio采用實施與控制分離的數據平面與控制平面兩層架構。
數據平面
-
envoy(proxy)：負責高效轉發與策略落地[核心]
控制平面
-
mixer：適配組件，數據平面與控制平面通過它交互
-
pilot：策略配置組件[核心]
-
citadel：安全組件
-
galley：底層平台（例如：K8S）解耦組件
整個架構的核心是envoy與pilot。
今天起，聊聊Istio的流控，典型如灰度發布。
就如同ServiceMesh的設計初衷，是技術體系與業務服務解耦一樣，Istio流控模型的本質，是流量控制與服務實例擴展的解耦，更具體的：
-
用戶只需要通過控制平面中的Pilot設定期望流量要以什么規則進行路由
-
不需要規定服務實例(service pods)如何接收
-
數據平面Envoy將從Pilot中獲取規則和命令，然后落地各類分流策略
如上圖所示，最開始時，ServiceA訪問舊版的ServiceB。
畫外音，業務與底層解耦：
（1）灰色圓形為業務Svc服務；
（2）紫色六邊形為Envoy代理；
（3）服務與代理之間都是本地訪問；
（4）跨網段之間都是Envoy代理交互（藍色箭頭）；
如何進行灰度發布呢？
如上圖所示，服務A調用服務B，服務B要發布一個灰度版本，需要5%的流量打到服務B的新版本，只需要：
（1）部署服務B的新版本；
（2）控制平面Pilot上進行策略配置，策略同步到Envoy；
（3）數據平面Envoy接收到策略配置，實時分流策略；
畫外音：圖形上沒有畫出Pilot和Envoy的交互。
搞定，這個過程業務服務與流量控制策略完全解耦，完美！
除了基於按流量比例分流的灰度發布，基於應用層的灰度發布通過Istio也非常容易實現。
如上圖所示，服務B要發布一個灰度版本，需要把iPhone的流量打到B的新版本，操作流程完全一樣（部署服務，Pilot控制，Envoy實施），非常方便。
如果Envoy原來只支持按照流量比例分流，不支持基於應用層協議分流，此時只需要：
（1）升級Envoy的分流策略，以及策略控制端Pilot；
（2）調用方服務A不需要升級；
（3）服務方服務B也不需要升級；
業務與底層基礎設施完全解耦，完美！
畫外音：這是Service Mesh的核心理念之一，詳見《ServiceMesh究竟解決什么問題》。
如果是用傳統微服務框架的方式，需要框架升級，調用方與服務方均需要配合升級與重啟。
最近下班都比較晚，今天先寫到這里。Pilot的分層架構如何，它又是如何與Envoy配合實現流控的，且聽下回分解。
Istio流控，服務發現，負載均衡，核心流程是如何實現的？
前情提要：
Istio架構體系中，流控(Traffic Management)雖然是數據平面的Envoy Proxy實施的，但整個架構的核心其實在於控制平面的Pilot。
灰度發布的過程在《Istio，灰度發布》一文中已經有過描述，今天重點說說Pilot和Envoy的交互流程與內部結構。
一、通用交互流程
圖示：
-
灰色圓形，為業務服務
-
紫色六邊形，為Envoy代理
二者相生相伴。
起初，上游調用方ServiceA訪問下游服務提供方ServiceB的V1版本，在ServiceB的V2版本部署好之后，調用方如何知道“SvcA切分1%的流量至SvcB的V2版本”這個指令的呢？
整個過程主要分為三大步驟：
（1）用戶在控制平面的后台，通過Pilot的API，修改A到B的路由策略（標號1）；
（2）Pilot將路由策略固化存儲，以便未來新注冊的調用方A能夠知道當前最新的路由策略；對於已經存在的調用方A，Pilot則通過主動通知的方式告之調用方A對應的Envoy（標號2）；
（3）Envoy作為數據平面，實施最新的路由策略（標號3），在本例中，即將1%的流量導給灰度版本Bv2；
二、服務發現與負載均衡
講了通用的流控策略實施通用流程，而服務發現與負載均衡，只是一個種策略實施的特例：
（1）提供服務的SvcB新增一個Pod（標號1）；
（2）在Pilot后台修改SvcB的集群配置（標號2）；
（3）Pilot將SvcB的最新信息同步給該配置的訂閱方（標號3），即SvcB的調用方SvcA對應的Proxy；
（4）SvcA對應的Proxy增加到SvcB的鏈接（標號4），並實施負載均衡；
畫外音：實際是鏈接到SvcB對應的Proxy。
整個過程，與使用配置中心來實施服務發現基本類似。
三、請求的入口及出口
ServiceMesh的核心，是技術基礎設施與業務服務的解耦，服務A調用服務B，再次強調：
-
一個容器Pod內的一個服務，服務進程（SrvA/SrvB）和邊車進程（Proxy）是相生相伴的，他們之間的交互是本地交互（標號1）
-
跨容器Pod之間的遠程調用，必須通過Proxy進行（標號2）
言下之意，服務A調用服務B，請求的流程是：
SvcA -> SvcA Proxy -> SvcB Proxy -> SvcB
響應的流程則反過來：
SvcB -> SvcB Proxy -> SvcA Proxy -> SvcA
跨網之間調用，請求的入口和出口，都是Proxy。
四、Pilot內部結構
Pilot它的內部結構並不復雜：
（1）Pilot的核心，是各種流控策略的維護，Abstract Model；
（2）必然，Pilot需要提供接口給用戶，增刪查改這些策略，Rules API；
（3）一方面，Pilot需要保持各類底層基礎設施的兼容性，Platform Adapter；
（4）另一方面，Pilot又需要保持不同Proxy實接口的兼容性，Envoy API；
這么設計的好處是：
-
Istio設計時已經考慮了異構的基礎設施，不管底層是K8s還是其他體系，都可以兼容
-
任何第三方可以實現自己的proxy，只要符合相關的API標准，都可以和Pilot集成
Pilot與Envoy的配合，是Istio的核心，如此一來：
-
服務發現(discovery)
-
負載均衡(load balancing)
-
故障恢復(failure recovery)
-
服務度量(metrics)
-
服務監控(monitoring)
-
A/B測試(A/B testing)
-
灰度發布(canary rollouts)
-
限流限速(rate limiting)
等很多能力都可以實現了。
MerviceMesh並沒有大家想的復雜。