Istio，灰度發布從未如此輕松！！！
三個問題，回顧前情提要。
ServiceMesh解決什么問題?
SM本質是業務服務與底層技術體系的解耦：
- 一個進程實現業務邏輯(不管是調用方，還是服務提供方)，biz，即上圖白色方塊
- 一個進程實現底層技術體系，proxy，即上圖藍色方塊
畫外音：負載均衡、監控告警、服務發現與治理、調用鏈…等諸多基礎設施，都放到這一層實現。
什么是Istio?
Istio是ServiceMesh的產品化落地。
Istio的分層架構設計如何?
Istio采用實施與控制分離的數據平面與控制平面兩層架構。
(1) 數據平面：
- envoy(proxy)：負責高效轉發與策略落地[核心]
(2) 控制平面：
- mixer：適配組件，數據平面與控制平面通過它交互
- pilot：策略配置組件[核心]
- citadel：安全組件
- galley：底層平臺(例如：K8S)解耦組件
整個架構的核心是envoy與pilot。
今天起，聊聊Istio的流控，典型如灰度發布。
就如同ServiceMesh的設計初衷，是技術體系與業務服務解耦一樣，Istio流控模型的本質，是流量控制與服務實例擴展的解耦，更具體的：
- 用戶只需要通過控制平面中的Pilot設定期望流量要以什么規則進行路由
- 不需要規定服務實例(service pods)如何接收
- 數據平面Envoy將從Pilot中獲取規則和命令，然后落地各類分流策略
如上圖所示，最開始時，ServiceA訪問舊版的ServiceB。
畫外音，業務與底層解耦：
- 灰色圓形為業務Svc服務;
- 紫色六邊形為Envoy代理;
- 服務與代理之間都是本地訪問;
- 跨網段之間都是Envoy代理交互(藍色箭頭);
如何進行灰度發布呢?
如上圖所示，服務A調用服務B，服務B要發布一個灰度版本，需要5%的流量打到服務B的新版本，只需要：
- 部署服務B的新版本;
- 控制平面Pilot上進行策略配置，策略同步到Envoy;
- 數據平面Envoy接收到策略配置，實時分流策略;
畫外音：圖形上沒有畫出Pilot和Envoy的交互。
搞定，這個過程業務服務與流量控制策略完全解耦，完美!
除了基于按流量比例分流的灰度發布，基于應用層的灰度發布通過Istio也非常容易實現。
如上圖所示，服務B要發布一個灰度版本，需要把iPhone的流量打到B的新版本，操作流程完全一樣(部署服務，Pilot控制，Envoy實施)，非常方便。
如果Envoy原來只支持按照流量比例分流，不支持基于應用層協議分流，此時只需要：
- 升級Envoy的分流策略，以及策略控制端Pilot;
- 調用方服務A不需要升級;
- 服務方服務B也不需要升級;
業務與底層基礎設施完全解耦，完美!
畫外音：這是Service Mesh的核心理念之一，詳見《ServiceMesh究竟解決什么問題》。
如果是用傳統微服務框架的方式，需要框架升級，調用方與服務方均需要配合升級與重啟。
最近下班都比較晚，今天先寫到這里。Pilot的分層架構如何，它又是如何與Envoy配合實現流控的，且聽下回分解。
思路比結論重要。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
