灰度釋出在UCloud大規模虛擬網路中的應用
本文主要詳細闡述了在UCloud的虛擬網路裡，如何利用ServiceMesh技術在虛擬網路控制面以及利用可程式設計交換機在轉發面實現灰度釋出。
ServiceMesh實現控制麵灰度
在控制面，早期灰度釋出採用APIGW的方式實現。APIGW通常僅部署在使用者流量的入口，完全灰度釋出就需要完整地部署兩套系統。但在微服務化的時代，任何一個微服務發生變更都需要完整地部署兩套系統，這不僅成本高且嚴重影響產品變更速度。ServiceMesh以類似於將APIGateway部署到本地，同時提供集中化控制的方式，完美地解決了這些問題。
UCloud的輕量級ServiceMesh平臺基於Istio，繼續使用Envoy代理，修改Pilot在保留完整的DSL支援的基礎上實現了脫離K8S執行。
因此網路團隊對Pilot做了高度訂製，從而更能滿足自身的需求。
訂製方案一： 按賬號灰度。在GRPC或者HTTP請求中新增⾃自定義Header x-ucloud-routeby，x-ucloud-routeby採用Cookie的編碼格式，在其中包含賬戶資訊，配置Envoy根據該Header進行策略路由。
訂製方案二： 採用顯式代理而不是IPTables透明引流的方式和Envoy整合，支援HTTP 1.0、HTTP 2.0和gRPC。在配置了Envoy的Proxy Port情況下，通過Envoy接入ServiceMesh；如果配置域名且沒有配置Envoy的Proxy，則自動採用ETCD gRPC naming and discovery的方式； 如果配置IP地址和埠，則直連指定地址；
訂製方案三：採用docker-compose管理container實現sidecar。新方案中仍然採用container的方式打包和部署微服務，但採用Host的網路方式簡化了現存服務的網路通訊方式。通過採用docker-compose管理container實現sidecar，實現了一個簡單的服務管理、版本管理、叢集管理、路由策略管理層，為叢集中的每臺Node（VM或物理伺服器）生成docker-compose配置檔案，從而部署和管理每臺Node的服務。
可程式設計交換機實現轉發麵灰度
在轉發麵灰度的方案選擇上，團隊採用了可程式設計交換機（基於Barefoot Tofino晶片）來實現灰度閘道器，替換普通交換機實現強灰度能力。
灰度閘道器最大提供64個100G的介面提供6.4T頻寬，PPS效能可達4400兆，延遲為us級別，能夠很好支援網路寬頻的高效能要求。灰度閘道器可以提供：一致性雜湊ECMP的能力；可以基於任意定製欄位（包括內層虛擬網路地址以及租戶ID）計算雜湊；在計算雜湊前優先應用灰度規則，可以根據任意欄位定製灰度規則，最小粒度可以做到按TCP流來灰度。
轉發麵灰度示例
有了上述這些新工具，可以通過部署新的策略實現更加細粒的灰度釋出，具體方案為：可程式設計交換機BGP宣告叢集VIP引流，根據選擇欄位計算一致性雜湊後將流量量分發給後端伺服器，並按照選擇欄位（VNI、源地址、目的地址）配置灰度規則。
灰度步驟如下：
按VM的粒度將流量量切換到灰度後端伺服器器
切換完成後立刻自動迴歸測試，根據路由表自動生成監測地址列表，並Ping檢測網路互通性
測試通過則逐步增加灰度的VM地址
直到整個VPC的流量量全部切換到灰度後端伺服器器
再切換一個新的VPC，直到所有分片內的VPC都切換到新的灰度後端伺服器
完成灰度釋出
以上內容最早發表於UCloud 10月12日在上海主辦的Tech Talk第一期活動。Tech Talk是UCloud面向使用者做深度技術交流的線下活動，後面也會繼續舉辦，歡迎參加。
【責任編輯：趙立京 TEL：（010）68476606】