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