云原生技術(shù)范式顛覆
——從Spring Cloud到
Service Mesh框架重構(gòu)之路
神州信息
徐超
02.Service Mesh遷移方案
對于還未涉足Service Mesh 的企業(yè)或產(chǎn)品,，其傳統(tǒng)微服務(wù)架構(gòu)如若已采用 Spring Cloud 框架構(gòu)建,，此時向Service Mesh 框架遷移又該如何做,？需要綜合考慮哪些因素,？是否有依可據(jù)？
接下來,，就構(gòu)建基于Spring Cloud向 Service Mesh 框架遷移提供一些建議方案和思路,，供大家參考。
2.1
遷移場景
傳統(tǒng)微服務(wù)框架,，以最為典型的Spring Cloud 框架為例進(jìn)行遷移說明,。首先，先看一下這樣的一個遷移場景,，目前的微服務(wù)架構(gòu)如下圖左邊部分：
● 應(yīng)用是部署在虛擬機(jī)或物理機(jī)上,。（服務(wù)還未容器化）。
● 框架是基于 Spring Cloud 框架開發(fā),。（服務(wù)中包含的業(yè)務(wù)邏輯和 Spring Cloud 組件相依賴,，業(yè)務(wù)和框架高度耦合）
● 開發(fā)語言以Java為主。（存在跨語言的問題）
● 注冊中心采用的是 Consul 或 Eureka,。（服務(wù)需引入注冊中心依賴包，存在一定的耦合）
目前開源 Istio 已經(jīng)成為 Service Mesh 事實上的標(biāo)準(zhǔn),，更是新一代微服務(wù)架構(gòu)發(fā)展的趨勢,，因此公司希望嘗試遷移到 Istio 框架，希望最終形成類似上圖的右邊部分,。
2.2
遷移路徑
面對上述遷移場景,，確定要引入 Service Mesh 前,，需要徹底搞清楚 Service Mesh 遷移的具體路徑。
首先,，要對自己項目做以下評估：
● 是否真的有必要引入遷移到 Service Mesh 上,？
● 當(dāng)前微服務(wù)架構(gòu)下，是否面臨傳統(tǒng)微服務(wù)架構(gòu)面臨的挑戰(zhàn),？
● 當(dāng)前微服務(wù)架構(gòu),，是否已經(jīng)阻礙或影響未來業(yè)務(wù)的發(fā)展？
● 公司或技術(shù)團(tuán)隊,，是否有能力,、人力、精力來投入到 Service Mesh 的遷移,？
其次,，完成 Service Mesh 微服務(wù)平臺的搭建。當(dāng)前所處階段是否已經(jīng)支持容器化和 Kubernetes,。如果當(dāng)前業(yè)務(wù)已經(jīng)運行在 Kubernetes 之上,，則 Service Mesh 的遷移將會比較順暢；如果當(dāng)前業(yè)務(wù)沒有運行在Kubernetes上,，因 Service Mesh 當(dāng)前典型的 Istio 框架對 Kubernetes 有著過度依賴,，所以可能就無法直接從 Spring Cloud 遷移到 Istio 框架，即使定制修改 Istio 以接觸對 Kubernetes 的依賴,，將會付出很大的代價,。這時通常有兩條遷移路徑可供選擇。
● 路徑一：非 Kubernetes 環(huán)境下,，先接入 Sidecar
如果當(dāng)前業(yè)務(wù)沒法快速容器化,，同時又有引入 Service Mesh 的迫切需求，可采取先接入 Sidecar,，來滿足當(dāng)前業(yè)務(wù)的痛點需求,。在引入 Sidecar 時，要注意其未來的演進(jìn)方向,，考慮后續(xù)可能繼續(xù)向 Service Mesh 遷移,，一旦時機(jī)成熟并引入 Kubernetes 容器化后，則能夠順利由 Sidecar 的方式直接演進(jìn)到 Service Mesh,。
Service Mesh 當(dāng)前典型的 Istio 框架在非 Kubernetes 下沒有很好的支持（據(jù)說未來會完全脫離對Kubernetes 的依賴）,，對 Istio 進(jìn)行定制化修改以支持非 Kubernetes 環(huán)境將會付出很大的代價，非特別強(qiáng)烈的需求和強(qiáng)大的技術(shù)儲備,，一般不建議這么做,，特別是對于一些中小公司而言。
如果一定要在非 Kubernetes 環(huán)境下引入 Service Mesh，數(shù)據(jù)平面可使用 Envoy,，控制平面可根據(jù) XDS 協(xié)議進(jìn)行自研,。
● 路徑二：先進(jìn)行 Kubernetes 容器化改造，再接入 Service Mesh
倘若公司有云平臺或容器化團(tuán)隊,，可采用公司資源共享的方式,，先借助其他團(tuán)隊來完成 Kubernetes 容器化改造，再接入 Service Mesh,。
最后,，基于構(gòu)建的 Service Mesh 框架，將業(yè)務(wù)應(yīng)用逐步遷移到 Service Mesh ,。
2.3
遷移原則
在實施遷移時,，必須要時刻遵守以下遷移原則。
● 漸進(jìn)式遷移： 為避免 Service Mesh 遷移過程中的風(fēng)險,，必須采用漸進(jìn)式遷移原則,，每次只遷移少量服務(wù)，待遷移后觀察足夠長的時間,，沒有問題后再繼續(xù)遷移,。
● 業(yè)務(wù)透明： 為減少 Service Mesh 遷移對業(yè)務(wù)的影響，減少業(yè)務(wù)的遷移阻力,，遷移初期必須確保業(yè)務(wù)完全透明且不需要過多的變更和修改,。
● 兼容性： 在遷移階段，必然會存在兩種模式（ Spring Cloud 和 Service Mesh 框架）并存,，在遷移過程中需要充分考慮兩者的兼容性,，使得遷移前后網(wǎng)絡(luò)打通，至少能夠滿足未遷移和已遷移部分能夠通信,。
2.4
遷移方案
從 Spring Cloud 向 Service Mesh 框架遷移,，大體上分為四個步驟：Spring Cloud 架構(gòu)分析、容器化改造,、Service Mesh 微服務(wù)平臺搭建和應(yīng)用遷移,。
2.4.1 Spring Cloud架構(gòu)分析
Spring Cloud 架構(gòu)分析的目的在于重新了解當(dāng)前微服務(wù)架構(gòu)下的所有功能，便于在向 Service Mesh 遷移時做準(zhǔn)備,，考慮哪些功能需要遷移,，哪些不需要遷移，哪些需要改造等,。如下圖所示是基于 Spring Cloud 完整構(gòu)建的微服務(wù)架構(gòu)解決方案,。
從上圖經(jīng)過分析，可以匯總得知它主要由以下幾部分組成：
● 代理&網(wǎng)關(guān)：提供統(tǒng)一對外或?qū)?nèi)的訪問入口,，包括路由,、鑒權(quán)、限流、熔斷,、降級等統(tǒng)一處理。
● 注冊中心：提供服務(wù)的注冊與發(fā)現(xiàn)功能,。
● 應(yīng)用服務(wù)：覆蓋整個業(yè)務(wù)服務(wù),，包括業(yè)務(wù)邏輯實現(xiàn)、框架SDK及外部組件依賴交互等,。
● 中間件&數(shù)據(jù)存儲：為應(yīng)用服務(wù)提供額外的支持能力,。
● CI&CD：持續(xù)集成、持續(xù)部署,。
上述這幾部分中哪些內(nèi)容是我們可以去掉或者是基于 Service Mesh （以 Istio 為例）能夠去做的,？經(jīng)過分析得知，可以替換的組件包括網(wǎng)關(guān)（Gateway 或者 Zuul,，由 Ingress gateway 或者 egress 替換）,，熔斷器（hystrix，由 Sidecar 替換）,，注冊中心（Eureka 及 Eureka client,，由 Polit，Sidecar 替換）,，負(fù)載均衡（ Ribbon,，由 Sidecar 替換）等。
此階段,，我們能夠大致知道 Spring Cloud 中的哪些內(nèi)容可以由 Istio 處理,，哪些內(nèi)容可以繼續(xù)沿用。
2.4.2 容器化改造
容器化改造,，主要針對目前還未引入 Kubernetes 容器化的場景,。在容器化改造之前，有必要知道改造的優(yōu)勢及要求,。
容器化改造優(yōu)勢：
● 更?。簶O大的資源利用效率， 最大限度榨取和共享物理資源,，多項目更能體現(xiàn)出容器化的優(yōu)勢,，節(jié)約部署 IT 成本。
● 更快：秒級啟動,，實現(xiàn)業(yè)務(wù)系統(tǒng)更快的開發(fā)迭代和交付部署,。
● 彈性：根據(jù)業(yè)務(wù)負(fù)載進(jìn)行彈性容器伸縮，彈性擴(kuò)展,。
● 方便：容器化業(yè)務(wù)部署支持藍(lán)綠/灰度/金絲雀等發(fā)布,，回滾，更加靈活方便。
● 靈活：監(jiān)控底層 node 節(jié)點健康狀態(tài),，靈活調(diào)度至最優(yōu)節(jié)點部署,。
● 強(qiáng)一致性：容器將環(huán)境和代碼打包在鏡像內(nèi)，保證了測試與生產(chǎn)環(huán)境的強(qiáng)一致性,。
容器化改造要求：
● 掌握 Docker 技術(shù)：開發(fā)人員需熟悉 Docker 容器化技術(shù),，熟練編寫 Dockerfile 文件。
● 掌握 Kubernetes 編排系統(tǒng)：熟悉 Kubernetes 容器化編排系統(tǒng),，熟悉各組件資源清單編寫,、高可用、 RBAC 安全策略等,。
容器化改造,，主要分為以下兩個階段：
● 容器化構(gòu)建：將基于 Spring Cloud 搭建的所有服務(wù)實現(xiàn)容器化構(gòu)建，實現(xiàn) Docker 鏡像打包,。
● 容器化管理：基于 Kubernetes 或容器云平臺進(jìn)行服務(wù)容器的管理,。
2.4.3 Service Mesh 微服務(wù)平臺搭建
Service Mesh 框架選取業(yè)界典型的 Istio 框架。
2.4.3.1 Istio基礎(chǔ)框架搭建
基于 Istio 框架搭建 Istio 基礎(chǔ)框架,，在控制平面和數(shù)據(jù)平臺分別提供以下能力：
● 控制平面：提供服務(wù)?格控制指令下發(fā),、服務(wù)配置、權(quán)限控制等功能,。
● 數(shù)據(jù)平臺：提供服務(wù)治理,、服務(wù)監(jiān)控及運維、流量管控等功能,。
上述Spring Cloud的功能在 Istio 框架上都能找到對應(yīng)的功能,，并通過適當(dāng)?shù)馁Y源清單配置即可完成。
Istio 架構(gòu)圖如下：
至此,，一個 Istio 基礎(chǔ)框架搭建完成,，能夠提供 Service Mesh 的所有能力。
2.4.3.2 Istio擴(kuò)展和定制
在遷移路徑中已經(jīng)提及過,，對于非Kubernetes 環(huán)境,，建議先引入 Sidecar，并采取 Istio 對虛擬機(jī)的支持方案,，在虛擬機(jī)環(huán)境下運行,。但如果有多平臺支持的場景，比如既有 Kubernetes 環(huán)境,，又有虛擬機(jī)環(huán)境,，需對 Istio 進(jìn)行定制化改造，去掉對 Kubernetes 的強(qiáng)依賴和耦合,，增加對其他平臺的支持,。（對于多平臺的支持,，目前Istio 還未支持，但從 Istio 官方相關(guān)文檔可以看出,，多平臺的支持最終肯定支持,，我們只需拭目以待。）
Istio對 Kubernetes 的耦合主要有以下幾個方面,，因此需要針對性的適配修改,。
（1）API資源管理層對 Kubernetes API Server 的依賴
資源管理層是Istio 對 Kubernetes 依賴最大的地方。Istio 對核心資源的管理,，是以 Kubernetes CRD 為基礎(chǔ)，并使用 kubectl 作為命令行操作入口,，kubectl 調(diào)用 API Server,，將資源存放在 etcd 中，并通過 Kubernetes CRD 機(jī)制觸發(fā)資源變更事件通知,，通知關(guān)心 Istio 資源變更事件的模塊進(jìn)行相關(guān)處理,。
如需解除Istio對 Kubernetes 的綁定，則需要自行實現(xiàn)這一套API管理方式,，并且做到平臺無關(guān),。
（2）通信訪問層面對kube DNS 的依賴
通信層面，在客戶端發(fā)送請求前,，先通過DNS 獲取服務(wù)的虛擬IP地址,，Istio 的 DNS 實現(xiàn)沿用Kubernetes DNS 方案，基于 DNS 通過服務(wù)名實現(xiàn)直接訪問,。因此需要在 DNS 方案層面接觸和Kubernetes 的耦合,，并使用平臺無關(guān)的 DNS 解決方案。
2.4.3.3 兩種框架并存
對于體量較大的業(yè)務(wù),，不可能一次性遷移完成,，需遵守“漸進(jìn)式遷移”原則，則實際遷移過程中可能面臨這樣的訴求：
● 一些存量老業(yè)務(wù)運行在虛擬機(jī)或者物理機(jī)上,，暫時沒有容器化改造計劃,，但希望通過 Service Mesh 來做服務(wù)治理。
● 新上的業(yè)務(wù)或者存量的非關(guān)鍵業(yè)務(wù)可以做為試點,，先容器化,、Service Mesh 化，其它業(yè)務(wù)依然采用原有的運行方式和微服務(wù)框架,。
● 對于未遷移的存量應(yīng)用和遷移完成的 Service Mesh 應(yīng)用依然能保持業(yè)務(wù)上的互通,。
面對上述這些真實而又合理的訴求，在進(jìn)行 Service Mesh 微服務(wù)平臺搭建時,，必然會存在兩種框架并存的場景,，如下圖所示,，左邊是未遷移的存量服務(wù)，右邊是容器化并 Service Mesh 化的試點服務(wù),，但這種模式服務(wù)間卻是互不相同,，且無法統(tǒng)一治理。
然而兩種框架并存時,，如何服務(wù)間互通,，統(tǒng)一治理？
在業(yè)內(nèi)流行這樣一句話：計算機(jī)科學(xué)領(lǐng)域的任何問題都可以通過增加一個間接的中間層來解決,。
同樣,，我們可以針對 Service Mesh 的控制平面做些文章，通過自定義控制插件（WASM）將 Spring Cloud 框架中原有注冊中心的功能納入進(jìn)來,，由控制平面提供原有服務(wù)注冊與發(fā)現(xiàn)的能力,，并結(jié)合 Istio 中入口網(wǎng)關(guān) Ingress 和 ServiceEntry 資源配置，以實現(xiàn)服務(wù)間互通,，統(tǒng)一治理,，整個實現(xiàn)邏輯架構(gòu)如下圖所示。
至此,，實現(xiàn)了基于Spring Cloud和 Istio 兩種框架的并存,。
2.4.4 應(yīng)用遷移
到這里，已經(jīng)完成了 Service Mesh 微服務(wù)平臺的搭建,，在這樣的平臺上我們?nèi)绾螌pring Cloud 應(yīng)用逐步向 Service Mesh 遷移,？
2.4.4.1 去除重疊功能
先來看一下 Spring Cloud 框架與 Istio 框架的功能重疊情況：
從上表功能對比分析，存在大量的重疊功能,，需將Spring Cloud 與 Istio 中重疊功能去除,，缺失功能保留，理論上可輕松去重,。對于 Spring Cloud 而言,，這些重疊功能大部分只需去除 pom.xml 中依賴包、相關(guān)配置及代碼中注解即可輕松完成,，剩余一個相對干凈的應(yīng)用,。
2.4.4.2 應(yīng)用注入
應(yīng)用注入是指在將應(yīng)用服務(wù)部署到網(wǎng)格時，將 Sidecar 注入到應(yīng)用服務(wù)中,，以實現(xiàn)網(wǎng)格的代理,。
Sidecar 注入，分為手動注入和自動注入：
● 手動注入：通過手動執(zhí)行 istioctl kube-inject 來重新構(gòu)造應(yīng)用的 CRD yaml,。
● 自動注入：通過 Kubernetes 的 mutable webhook 回調(diào) istio-sidecar-injector 服務(wù)來重新構(gòu)造應(yīng)用的 CRD yaml,。
如下圖所示：
無論是手動注入還是自動注入，Sidecar 注入的本質(zhì)是將運行 Sidecar 所需要的鏡像地址,、啟動參數(shù),、所連接的 Istio 集群及配置信息填充到注入模版,，并添加到應(yīng)用的 CRD yaml 中，最終通過 Kubernetes 持久化資源并拉起應(yīng)用和 Sidecar 的 POD,。
此時,，應(yīng)用已成功遷移部署到 Service Mesh 。
03.總結(jié)
正如《數(shù)字化的力量》一書中所說：
這種升級改造和技術(shù)范式的轉(zhuǎn)換并不是在一夜之間完成的,數(shù)字技術(shù)需要通過在社會經(jīng)濟(jì)的各個方面進(jìn)行逐步應(yīng)用,通過量的積累進(jìn)而最終引起質(zhì)的飛躍,使我們從新的技術(shù)范式的形成階段進(jìn)入到穩(wěn)定發(fā)展階段,。
郭為.數(shù)字化的力量[M]. 北京：機(jī)械工業(yè)出版社,，2022.
這篇文章從傳統(tǒng)微服務(wù)架構(gòu)開始一步步介紹到Service Mesh，并提出了傳統(tǒng)微服務(wù)架構(gòu)面臨的挑戰(zhàn),，針對現(xiàn)狀,，為了更好的滿足市場需求，而不被市場淘汰,，介紹了傳統(tǒng)微服務(wù)如何平滑遷移到 Service Mesh 的過程,，并給出了一些解決方案、步驟及思路,，供大家參考。
參考資料
郭為.數(shù)字化的力量[M]. 北京：機(jī)械工業(yè)出版社,，2022.
https://istio.io/latest/docs/concepts/what-is-istio/
劉俊海.Service Mesh微服務(wù)架構(gòu)設(shè)計[M].北京：機(jī)械工業(yè)出版社,，2019.
https://mp.weixin.qq.com/s/y9PZLgHhVcdsMuTzAyIMsQ
https://www.servicemesher.com/blog/service-mesh-rebuild-microservice-market/
https://mp.weixin.qq.com/s/-MszFJORuDJKf3V5ndyimw
https://www.servicemesher.com/blog/netease-yeation-service-mesh/
（下篇完）
