天天看點

基于Istio的灰階釋出架構方案實踐之路

作者:京東雲開發者

1. 背景介紹

灰階釋出,又名金絲雀釋出,是指能夠平滑過渡的一種釋出方式。基于系統穩定性和快速業務疊代的綜合考慮,業務應用開發團隊采取了新版本服務灰階上線的方式,即新版本服務并非全量釋出到線上環境,而是釋出少數幾個執行個體進行灰階驗證,沒有問題後再全量釋出。在部分核心服務進行接口更新和邏輯遷移時,還會通過在業務邏輯代碼中增加黑白名單或者流量百分比控制的方式,逐漸将舊版本接口實作遷移至新版本接口實作。尤其是對于toB業務和SAAS類平台,很多情況需要根據租戶或使用者次元進行灰階控制,實作業務上的A/Best功能。

對于之前我們業務中實作的傳統的灰階釋出, 較好地權衡了服務穩定性和業務疊代效率,但仍存在以下問題:

a. 系統侵入性強,業務開發人員在服務接口中編碼大量與業務邏輯無關的黑白名單或流量百分比控制代碼。

b. 當新版本接口出現波動或異常,通常需要業務團隊通過緊急修改代碼和緊急釋出,來更新黑白名單和流量百分比控制政策,時間較長,業務影響較大。

c. 調整黑白名單或流量控制百分比,需要業務團隊釋出代碼或者接入動态配置中心,過程複雜、可複用性差、操作靈活性差.

d. 對于單體應用來說,灰階釋出方案實作還算簡單,但對于微服務應用,每次釋出版本可能不是全部服務需要灰階釋出,實作微服務灰階釋出的原子次元控制,也是導緻微服務架構下灰階方案不能很好落地的原因。

筆者實際業務項目(采靈通系統)采用的是微服務的架構設計,總計服務個數60+,技術底座采用K8s+Istio的服務治理方案。如果采用傳統的灰階釋出方案,每個服務上下遊依賴過多,相對于傳統的灰階釋出方案,并不能很好滿足業務訴求。是以,探索了一條基于Istio的服務流量治理方案下的靈活可配置的灰階釋出方案。

2. 方案詳情

先上一個方案簡介圖:

基于Istio的灰階釋出架構方案實踐之路



本發明的技術方案以k8s服務部署為基礎,以istio服務流量治理為核心,以Mysql為資料存儲,同時結合jenkins的自動化部署方案,可以實作低成本動态的高效微服務釋出方案,并且帶業務服務無代碼侵入。

本發明的技術方案以activiti開源工作流引擎為基礎, 以Mysql作為資料存儲, 通過自定義的一套規則引擎架構, 可以實作流程規則的的快速搭建和動态修改功能.

a. 如圖所示,k8s management實作對服務的pod管理,在k8s管理中,正式環境和灰階環境分别隸屬兩個命名空間,通過deployment實作服務的建立,建立中,灰階和正式的pod執行個體會打上prod或gray的标簽。Deployment建立過程通過jenkins管理,可以實作部署的自動化流程。具體deployment配置方案詳情請跳轉至3.2.2

b. 如圖所示,istio控制平面可以建立虛拟服務,通過對虛拟服務的路由政策的配置不同,可以實作不同的灰階政策,配置下發通過jenkins管理,可以實作配置的自動化下發。具體政策詳情請跳轉至2.1

c. 如圖所示,具體業務請求實作流程如上:

1. 使用者首先需要登入請求,請求發動到我們自建的認證中心服務中。如圖中1标所示。

2. 認證中心接收到請求會到cookie生成器中擷取使用者認證的cookie,如圖中2标所示

3. Cookie生成器會到資料庫中讀取灰階白名單資訊,來确定是否在cookie中打灰階标簽。如圖中3标所示。

4. 認證中心拿到cookie後傳回給前端使用者 ,如圖中4,5标所示。

5. 使用者帶着cookie請求業務請求到虛拟服務A.虛拟服務A中存在istio控制台下發的的灰階配置資訊,通過配置資訊,決定目前的請求流量是流入正式環境執行個體A還是灰階環境執行個體A。如圖中6,7标所示。

6. 服務A中存在調用服務B的業務邏輯,是以服務A會請求到虛拟服務B中,虛拟服務B中存在istio控制台下發的的灰階配置資訊,通過配置資訊,決定目前的請求流量是流入正式環境執行個體B還是灰階環境執行個體B。如圖中8标所示。

通過以上8個步驟,我們完成了灰階方案下的流量管控,該方案對于業務服務A和業務服務B無任何代碼侵入,同時,灰階的配置方案可以實時快速的通過jenkins管理頁面進行自動化下發,實作灰階釋出的動态靈活切換.

至于灰階環境的低成本,當代碼完成灰階拉平線上後,通過更改灰階下發政策,可以實作灰階環境和正式環境的負載均衡,共同承擔正式環境的業務流量,保證了灰階環境的主機資源不會被浪費。

2.1 k8s Management管理

在k8s管理方面,要建立兩個命名空間,一個是prod環境,一個是gray環境,通過命名空間隔離正式環境和灰階環境資源,主要原因是可以更好的管理。當然此處并不強制。同時,需要配置一下deployment的标簽項,在标簽項增加一個profile鍵,根據場景,profile可以配置為prod和gray,具體配置demo如下圖所示。

基于Istio的灰階釋出架構方案實踐之路

2.2 基于istio灰階整體配置方案

基于Istio的灰階釋出架構方案實踐之路



灰階整體方案流程圖如上圖所屬,該流程圖中主要分為三大整體方案,包括:基于使用者白名單的灰階方案,按照流量百分比灰階方案,灰階拉平線上的負載均衡方案。以上灰階環境可以滿足之前提到的多場景,低成本,動态,無侵入的灰階方案要求。

以下2.3,2.4,2.5将分别詳細介紹三種灰階方案的具體配置政策。

2.3 基于使用者白名單的灰階方案政策

基于Istio的灰階釋出架構方案實踐之路



1. cookie中打标簽。

通過認證中心,可以實作業務次元的灰階控制,cookie中會根據使用者白名單,進行灰階打标簽。Cookie格式如下:

cookie:tenantGray=0;rememberMe=*************;channel=****

當tenantGray=0時,表示目前使用者不是灰階使用者,當tenantGray=1時,表示目前使用者是灰階使用者。

2. 當選擇根據cookie動态配置灰階服務時,根據選中的服務,virtualService配置如下:

基于Istio的灰階釋出架構方案實踐之路



如圖所示,當請求的cookie資訊比對到tenantGray=1時,根據istio的虛拟服務規則,走test-A.gray.svc.cluster.local路由,然後請求會打到灰階環境的服務執行個體上。當tennatGray=0時,根據istio的虛拟服務規則,走test-A.prod.svc.cluster.local的路由,然後請求會打到正式環境的服務執行個體上。

3. 如果使用者選擇根據灰階标簽進行灰階方案選擇,配置方案如下:

基于Istio的灰階釋出架構方案實踐之路



在k8s叢集中我們之前建立灰階服務的deployment時,當時增加過一個标簽,标簽為profile: pray,用來标記該服務為灰階服務。

如圖所示配置,match條件為,當請求來源是來自帶有灰階标簽的deployment服務時,走test-A.gray.svc.cluster.local路由,然後請求會打到灰階環境的服務執行個體上。反之,走test-A.prod.svc.cluster.local的路由,然後請求會打到正式環境的服務執行個體上。

4. 然後把所有需要灰階釋出的服務對應的vistualService的配置資訊通過jenkins的自動化流程下發到k8s叢集中。

2.4 按照流量百分比的灰階方案

基于Istio的灰階釋出架構方案實踐之路



當我們的業務場景不需要針對具體的使用者進行灰階時,尤其是我們隻是在一定範圍内做A/Btest,這樣的話,我們可以更改配置資訊,實作業務的按照流量比例進行灰階控制,具體的配置virtualService方案如下:

基于Istio的灰階釋出架構方案實踐之路



2.5 灰階拉平線上的負載均衡方案

基于Istio的灰階釋出架構方案實踐之路



該灰階方案比較明确,就是當該服務不再需要灰階時,為了不浪費伺服器資源,将灰階服務跟線上服務代碼拉平,然後通過流量管理,正式環境的流量實作負載均衡的目的。假設灰階服務跟正式服務的服務執行個體數比率為1:1,具體virtualService配置如下:

基于Istio的灰階釋出架構方案實踐之路



2.6 微服務灰階釋出治理方案

衆所周知,對于單體應用來說,灰階釋出隻需要對單一服務進行灰階控制就會要了。但是到了微服務架構下,會存在衆多服務,服務之間存在複雜的網絡拓撲關系,是以當我們進行服務的灰階釋出時,需要控制服務之間的灰階調用關系,實作灰階釋出的服務治理功能,解決了微服務架構下動态管理多服務之間的灰階方案串聯問題。

以下舉例三種不同的灰階治理場景。

a. 下圖執行個體場景是,服務A采用基于灰階白名單的灰階政策,服務B采用灰階拉平線上的灰階政策,然後服務A通路服務B,可以實作服務A的灰階釋出,服務B為正式環境。

基于Istio的灰階釋出架構方案實踐之路



b. 下圖執行個體場景是,服務A采用基于灰階白名單的灰階政策,服務B采用基于服務灰階标簽的通路政策,然後服務A通路服務B,可以實作灰階服務A的流量通路灰階服務B,正式服務A的流量通路正式服務B。

基于Istio的灰階釋出架構方案實踐之路

c. 圖執行個體場景是,服務A采用基于流量比率的灰階政策正式環境和灰階環境的比率為8:2,服務B采用基于灰階白名單的灰階政策,然後服務A通路服務B時,在灰階白名單中的使用者,在灰階服務B,不在灰階白名單中的使用者,走正式服務B。

基于Istio的灰階釋出架構方案實踐之路

3. 總結

通過本次基于Istio的灰階方案的實踐,最大感觸就是基于服務網格的第二代微服務架構的優秀潛力。Service Mesh對流量的管理可以下沉至運維次元,并且靈活度是第一代微服務架構不可比拟的。通過這次時間,很好的解決了筆者現實業務中的灰階釋出問題,實作了通過配置自動化下發,無代碼侵入,實作動态切換等多種靈活政策。

4. 名詞解釋

k8s:kubernates的簡稱。k8s是一個開源的,用于管理雲平台中多個主機上的容器化的應用,Kubernetes的目标是讓部署容器化的應用簡單并且高效(powerful),Kubernetes提供了應用部署,規劃,更新,維護的一種機制

istio:Istio 是一個開源服務網格,它透明地分層到現有的分布式應用程式上。

負載均衡:意思是将負載(工作任務,通路請求)進行平衡、分攤到多個操作單元(伺服器,元件)上進行執行

virtualService:istio内置的一種配置類型,叫做虛拟服務,可以設定單獨的路由指向。通過virtualService可以實作istio的流量管理。

灰階拉平:是指将正式環境的服務代碼跟灰階環境的服務代碼拉成一緻的。

繼續閱讀