三個(gè)問題，回顧前情提要。

ServiceMesh解決什么問題？

SM本質(zhì)是業(yè)務(wù)服務(wù)與底層技術(shù)體系的解耦：

• 一個(gè)進(jìn)程實(shí)現(xiàn)業(yè)務(wù)邏輯（不管是調(diào)用方，還是服務(wù)提供方），biz，即上圖白色方塊

• 一個(gè)進(jìn)程實(shí)現(xiàn)底層技術(shù)體系，proxy，即上圖藍(lán)色方塊

畫外音：負(fù)載均衡、監(jiān)控告警、服務(wù)發(fā)現(xiàn)與治理、調(diào)用鏈…等諸多基礎(chǔ)設(shè)施，都放到這一層實(shí)現(xiàn)。

什么是Istio？

Istio是ServiceMesh的產(chǎn)品化落地。

Istio的分層架構(gòu)設(shè)計(jì)如何？

Istio采用實(shí)施與控制分離的數(shù)據(jù)平面與控制平面兩層架構(gòu)。

數(shù)據(jù)平面

• envoy(proxy)：負(fù)責(zé)高效轉(zhuǎn)發(fā)與策略落地[核心]

控制平面

• mixer：適配組件，數(shù)據(jù)平面與控制平面通過它交互

• pilot：策略配置組件[核心]

• citadel：安全組件

• galley：底層平臺（例如：K8S）解耦組件

整個(gè)架構(gòu)的核心是envoy與pilot。

今天起，聊聊Istio的流控，典型如灰度發(fā)布。

就如同ServiceMesh的設(shè)計(jì)初衷，是技術(shù)體系與業(yè)務(wù)服務(wù)解耦一樣，Istio流控模型的本質(zhì)，是流量控制與服務(wù)實(shí)例擴(kuò)展的解耦，更具體的：

• 用戶只需要通過控制平面中的Pilot設(shè)定期望流量要以什么規(guī)則進(jìn)行路由

• 不需要規(guī)定服務(wù)實(shí)例(service pods)如何接收

• 數(shù)據(jù)平面Envoy將從Pilot中獲取規(guī)則和命令，然后落地各類分流策略

如上圖所示，最開始時(shí)，ServiceA訪問舊版的ServiceB。

畫外音，業(yè)務(wù)與底層解耦：

（1）灰色圓形為業(yè)務(wù)Svc服務(wù)；

（2）紫色六邊形為Envoy代理；

（3）服務(wù)與代理之間都是本地訪問；

（4）跨網(wǎng)段之間都是Envoy代理交互（藍(lán)色箭頭）；

如何進(jìn)行灰度發(fā)布呢？

如上圖所示，服務(wù)A調(diào)用服務(wù)B，服務(wù)B要發(fā)布一個(gè)灰度版本，需要5%的流量打到服務(wù)B的新版本，只需要：

（1）部署服務(wù)B的新版本；

（2）控制平面Pilot上進(jìn)行策略配置，策略同步到Envoy；

（3）數(shù)據(jù)平面Envoy接收到策略配置，實(shí)時(shí)分流策略；

畫外音：圖形上沒有畫出Pilot和Envoy的交互。

搞定，這個(gè)過程業(yè)務(wù)服務(wù)與流量控制策略完全解耦，完美！

除了基于按流量比例分流的灰度發(fā)布，基于應(yīng)用層的灰度發(fā)布通過Istio也非常容易實(shí)現(xiàn)。

如上圖所示，服務(wù)B要發(fā)布一個(gè)灰度版本，需要把iPhone的流量打到B的新版本，操作流程完全一樣（部署服務(wù)，Pilot控制，Envoy實(shí)施），非常方便。

如果Envoy原來只支持按照流量比例分流，不支持基于應(yīng)用層協(xié)議分流，此時(shí)只需要：

（1）升級Envoy的分流策略，以及策略控制端Pilot；

（2）調(diào)用方服務(wù)A不需要升級；

（3）服務(wù)方服務(wù)B也不需要升級；

業(yè)務(wù)與底層基礎(chǔ)設(shè)施完全解耦，完美！

畫外音：這是Service Mesh的核心理念之一，詳見《ServiceMesh究竟解決什么問題》。

如果是用傳統(tǒng)微服務(wù)框架的方式，需要框架升級，調(diào)用方與服務(wù)方均需要配合升級與重啟。

最近下班都比較晚，今天先寫到這里。Pilot的分層架構(gòu)如何，它又是如何與Envoy配合實(shí)現(xiàn)流控的，且聽下回分解。

思路比結(jié)論重要。

架構(gòu)師之路-分享技術(shù)思路

調(diào)研：

大伙升級一個(gè)流控策略，業(yè)務(wù)服務(wù)要升級，要重啟么？