三個問題，回顧前情提要。
sm本質是業務服務與底層技術體系的解耦：
畫外音：負載均衡、監控告警、服務發現與治理、呼叫鏈…等諸多基礎設施，都放到這一層實現。
istio是servicemesh的產品化落地。
istio採用實施與控制分離的資料平面與控制平面兩層架構。
資料平面
控制平面
整個架構的核心是envoy與pilot。
今天起，聊聊istio的流控，典型如灰度發布。
就如同servicemesh的設計初衷，是技術體系與業務服務解耦一樣，istio流控模型的本質，是流量控制與服務例項擴充套件的解耦，更具體的：
如上圖所示，最開始時，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配合實現流控的，且聽下回分解。
思路比結論重要。
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布 灰度很簡單，發布很複雜
什麼是灰度發布，其要點有哪些？最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了乙個話題 灰度發布 因為筆者所負責的產品還沒有達到他們產品使用者的量級上 最低的都在1千萬 也就談不上灰度發布這一環節，所以只有聽的份。雖然筆者暫時沒有涉及到，但...
灰度發布入門
我們的產品是個比較典型的網際網路產品，產品公升級採用 小步快跑 的方式，一般採用保持每週或每兩周一次的發布頻率，同時，每週會有數次bug上線。系統上線總是伴隨著風險，系統重大bug的風險，新舊版本相容的風險，使用者使用習慣突然改變而造成使用者流失的風險等等，因為這些風險的存在，很多次上線都是通宵達旦...