Spring Cloud怎么向Service Mesh框架遷移

這篇文章主要講解了“Spring Cloud怎么向Service Mesh框架遷移”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Spring Cloud怎么向Service Mesh框架遷移”吧！

1、背景

微服務(wù)是近些年來軟件架構(gòu)中的熱名詞，也是一個(gè)很大的概念，不同人對(duì)它的理解都各不相同，甚至在早期微服務(wù)架構(gòu)中出現(xiàn)了一批四不像的微服務(wù)架構(gòu)產(chǎn)品，有人把單純引入Spring Boot、Spring Cloud框架也叫做微服務(wù)架構(gòu)，卻只是將它作為服務(wù)的 Web 容器而已。

隨著微服務(wù)的火熱，越來越多的團(tuán)隊(duì)開始實(shí)踐，將微服務(wù)紛紛落地，并投入生產(chǎn)。但隨著微服務(wù)規(guī)模的不斷壯大，每增加一個(gè)微服務(wù)，就可能會(huì)增加一些依賴的基礎(chǔ)設(shè)施和第三方的配置，比如 Kafka實(shí)例等，相應(yīng)CI/CD的配置也會(huì)增加或調(diào)整。 同時(shí)隨著微服務(wù)數(shù)量增多、業(yè)務(wù)復(fù)雜性的提升及需求的多樣性等（如，對(duì)接第三方異構(gòu)系統(tǒng)等），服務(wù)間通信的錯(cuò)綜復(fù)雜，一步步地將微服務(wù)變得更加臃腫，服務(wù)治理也是難上加難，而這些問題在單體架構(gòu)中很容易解決。為此，有人開始懷疑當(dāng)初微服務(wù)化是否是明智之選，甚至考慮回歸到傳統(tǒng)單體應(yīng)用。

正如下圖所示，PPT 中的微服務(wù)總是美好的，但現(xiàn)實(shí)中的微服務(wù)卻是一團(tuán)糟糕，想甩甩不掉，越看越糟心。難道就沒有辦法了么？

1.1 傳統(tǒng)微服務(wù)架構(gòu)面臨的挑戰(zhàn)

面對(duì)上述暴露出的問題，并在傳統(tǒng)微服務(wù)架構(gòu)下，經(jīng)過實(shí)踐的不斷沖擊，面臨了更多新的挑戰(zhàn)，綜上所述，產(chǎn)生這些問題的原因有以下這幾點(diǎn)：

• 過于綁定特定技術(shù)棧。 當(dāng)面對(duì)異構(gòu)系統(tǒng)時(shí)，需要花費(fèi)大量精力來進(jìn)行代碼的改造，不同異構(gòu)系統(tǒng)可能面臨不同的改造。

• 代碼侵入度過高。 開發(fā)者往往需要花費(fèi)大量的精力來考慮如何與框架或 SDK 結(jié)合，并在業(yè)務(wù)中更好的深度融合，對(duì)于大部分開發(fā)者而言都是一個(gè)高曲線的學(xué)習(xí)過程。

• 多語言支持受限。 微服務(wù)提倡不同組件可以使用最適合它的語言開發(fā)，但是在 Spring Cloud 框架下就是 Java 的天下，多語言的支持難度很大。這也就導(dǎo)致在面對(duì)異構(gòu)系統(tǒng)對(duì)接時(shí)的無奈，或退而求其次的方案了。

• 老舊系統(tǒng)維護(hù)難。 面對(duì)老舊系統(tǒng)，很難做到統(tǒng)一維護(hù)、治理、監(jiān)控等，在過度時(shí)期往往需要多個(gè)團(tuán)隊(duì)分而管之，維護(hù)難度加大。

上述這些問題都是在所難免，我們都知道技術(shù)演進(jìn)來源于實(shí)踐中不斷的摸索，將功能抽象、解耦、封裝、服務(wù)化。 隨著傳統(tǒng)微服務(wù)架構(gòu)暴露出的這些問題，將迎來新的挑戰(zhàn)，讓大家紛紛尋找其他解決方案。

1.2 迎來新一代微服務(wù)架構(gòu)

為了解決傳統(tǒng)微服務(wù)面臨的問題，以應(yīng)對(duì)全新的挑戰(zhàn)，微服務(wù)架構(gòu)也進(jìn)一步演化，最終催生了Service Mesh 的出現(xiàn)，迎來了新一代微服務(wù)架構(gòu)，也被稱為下一代微服務(wù)。為了更好地理解 Service Mesh 的概念和存在的意義，我們來回顧一下這一演進(jìn)過程。

1.2.1 耦合階段

在微服務(wù)架構(gòu)中，服務(wù)發(fā)現(xiàn)、熔斷、治理等能力是微服務(wù)架構(gòu)重要的組成部分。微服務(wù)化之后，服務(wù)更加的分散，復(fù)雜度變得更高，起初開發(fā)者將諸如熔斷、超時(shí)等功能和業(yè)務(wù)代碼封裝在一起，使服務(wù)具備了網(wǎng)絡(luò)控制能力，如下圖所示。

這種方案雖然易于實(shí)現(xiàn)，但從設(shè)計(jì)角度來講卻存在一定的缺陷。

• 基礎(chǔ)設(shè)施功能（如，服務(wù)發(fā)現(xiàn)，負(fù)載均衡、熔斷等）和業(yè)務(wù)邏輯高度耦合。

• 每個(gè)微服務(wù)都重復(fù)實(shí)現(xiàn)了相同功能的代碼。

• 管理困難。如果某個(gè)服務(wù)的負(fù)載均衡發(fā)生變化，則調(diào)用它的相關(guān)服務(wù)都需要更新變化。

• 開發(fā)者不能集中精力只關(guān)注于業(yè)務(wù)邏輯開發(fā)。

1.2.2 公共庫 SDK

基于上面存在的問題，很容易會(huì)想到將基礎(chǔ)設(shè)施功能設(shè)計(jì)為一個(gè)公共庫 SDK，讓服務(wù)的業(yè)務(wù)邏輯與這些功能降低耦合度，提高重復(fù)利用率，更重要的是開發(fā)者只需要關(guān)注公共庫 SDK 的依賴及使用，而不必關(guān)注實(shí)現(xiàn)這些公共功能，從而更加專注于業(yè)務(wù)邏輯的開發(fā)，比如 Spring Cloud 框架是類似的方式。如下圖所示：

實(shí)際上即便如此，它仍然有一些不足之處。

• 這些公共庫 SDK 存在較為陡峭的學(xué)習(xí)成本，需要耗費(fèi)開發(fā)人員一定的時(shí)間和人力與現(xiàn)有系統(tǒng)集成，甚至需要考慮修改現(xiàn)有代碼進(jìn)行整合。

• 這些公共庫 SDK 一般都是通過特定語言實(shí)現(xiàn)，缺乏多語言的支持，在對(duì)現(xiàn)有系統(tǒng)整合時(shí)有一定的局限性。

• 公共庫 SDK 的管理和維護(hù)依然需要耗費(fèi)開發(fā)者的大量精力，并需專門人員來進(jìn)行管理維護(hù)。

1.2.3 Sidecar 模式

有了上面公共庫 SDK 的啟發(fā)，加上跨語言問題、更新后的發(fā)布和維護(hù)等問題，人們發(fā)現(xiàn)更好的解決方案是把它作為一個(gè)代理，服務(wù)通過這個(gè)透明的代理完成所有流量的控制。

這就是典型的 Sidecar 代理模式，也被翻譯為邊車代理，它作為與其他服務(wù)通信的橋梁，為服務(wù)提供額外的網(wǎng)絡(luò)特性，并與服務(wù)獨(dú)立部署，對(duì)服務(wù)零侵入，更不會(huì)受限于服務(wù)的開發(fā)語言和技術(shù)棧，如下圖所示。

以 Sidecar 模式進(jìn)行通信代理，實(shí)現(xiàn)了基礎(chǔ)實(shí)施層與業(yè)務(wù)邏輯的完全隔離，在部署、升級(jí)時(shí)帶來了便利，做到了真正的基礎(chǔ)設(shè)施層與業(yè)務(wù)邏輯層的徹底解耦。另一方面，Sidecar 可以更加快速地為應(yīng)用服務(wù)提供更靈活的擴(kuò)展，而不需要應(yīng)用服務(wù)的大量改造。Sidecar 可以實(shí)現(xiàn)以下主要功能：

• 服務(wù)注冊(cè)。 幫助服務(wù)注冊(cè)到相應(yīng)的服務(wù)注冊(cè)中心，并對(duì)服務(wù)做相關(guān)的健康檢查。

• 服務(wù)路由。 當(dāng)應(yīng)用服務(wù)調(diào)用其它服務(wù)時(shí)，Sidecar 可以幫助從服務(wù)發(fā)現(xiàn)中找到相應(yīng)的服務(wù)地址，完成服務(wù)路由功能。

• 服務(wù)治理。 Sidecar 可以完全攔截服務(wù)進(jìn)出的流量，并對(duì)其進(jìn)行相應(yīng)的調(diào)用鏈跟蹤、熔斷、降級(jí)、日志監(jiān)控等操作，將服務(wù)治理功能集中在 Sidecar 中實(shí)現(xiàn)。

• 集中管控。 整個(gè)微服務(wù)架構(gòu)體系下的所有服務(wù)完全可以通過 Sidecar 來進(jìn)行集中管控，完成對(duì)服務(wù)的流控、下線等。

于是，應(yīng)用服務(wù)終于可以做到跨語言開發(fā)、并更專注于業(yè)務(wù)邏輯的開發(fā)。

1.2.4 Service Mesh

把 Sidecar 模式充分應(yīng)用于一個(gè)龐大的微服務(wù)架構(gòu)系統(tǒng)，為每個(gè)應(yīng)用服務(wù)配套部署一個(gè) Sidecar 代理，完成服務(wù)間復(fù)雜的通信，最終就會(huì)得到一個(gè)如下所示的網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)，這就是 Service Mesh，又稱之為“服務(wù)網(wǎng)格“。

至此，迎來了新一代微服務(wù)架構(gòu)——Service Mesh，它徹底解決了傳統(tǒng)微服務(wù)架構(gòu)所面臨的問題。

1.3 什么是 Service Mesh

在開始進(jìn)入主題之前，我認(rèn)為有必要再對(duì) Service Mesh 進(jìn)行統(tǒng)一的闡述，這樣將有助于理解它，更加便于閱讀接下來的內(nèi)容。

1.3.1 Service Mesh 介紹

Service Mesh翻譯為“服務(wù)網(wǎng)格”，作為服務(wù)間通信的基礎(chǔ)設(shè)施層。輕量級(jí)高性能網(wǎng)絡(luò)代理，提供安全的、快速的、可靠地服務(wù)間通訊，與實(shí)際應(yīng)用部署一起，但對(duì)應(yīng)用透明。應(yīng)用作為服務(wù)的發(fā)起方，只需要用最簡(jiǎn)單的方式將請(qǐng)求發(fā)送給本地的服務(wù)網(wǎng)格代理，然后網(wǎng)格代理會(huì)進(jìn)行后續(xù)的操作，如服務(wù)發(fā)現(xiàn)，負(fù)載均衡，最后將請(qǐng)求轉(zhuǎn)發(fā)給目標(biāo)服務(wù)。

Service Mesh目的是解決系統(tǒng)架構(gòu)微服務(wù)化后的服務(wù)間通信和治理問題。服務(wù)網(wǎng)格由Sidecar節(jié)點(diǎn)組成，這個(gè)模式的精髓在于實(shí)現(xiàn)了數(shù)據(jù)面（業(yè)務(wù)邏輯）和控制面的解耦。具體到微服務(wù)架構(gòu)中，即給每一個(gè)微服務(wù)實(shí)例同步部署一個(gè)Sidecar。

在Service Mesh部署網(wǎng)絡(luò)結(jié)構(gòu)圖中，綠色方塊為應(yīng)用服務(wù)，藍(lán)色方塊為 SideCar，應(yīng)用服務(wù)之間通過Sidecar進(jìn)行通信，整個(gè)服務(wù)通信形成圖中的藍(lán)色網(wǎng)絡(luò)連線，圖中所有藍(lán)色部分就形成了Service Mesh。其具備如下主要特點(diǎn)：

• 應(yīng)用程序間通訊的中間層。

• 輕量級(jí)網(wǎng)絡(luò)代理。

• 應(yīng)用程序無感知。

• 解耦應(yīng)用程序的重試/超時(shí)、監(jiān)控、追蹤和服務(wù)發(fā)現(xiàn)。

Service Mesh的出現(xiàn)解決了傳統(tǒng)微服務(wù)框架中的痛點(diǎn)，使得開發(fā)人員專注于業(yè)務(wù)本身，同時(shí)，將服務(wù)通信及相關(guān)管控功能從業(yè)務(wù)中分離到基礎(chǔ)設(shè)施層。

1.3.2 Service Mesh 的功能

那么 Service Mesh 到底能夠做什么呢？

Service Mesh 作為微服務(wù)架構(gòu)中負(fù)責(zé)網(wǎng)絡(luò)通信的基礎(chǔ)設(shè)施層，具備網(wǎng)絡(luò)處理的大部分功能。下面列舉了一些主要的功能：

• 動(dòng)態(tài)路由。 可通過路由規(guī)則來動(dòng)態(tài)路由到所請(qǐng)求的服務(wù)，便于不同環(huán)境、不同版本等的動(dòng)態(tài)路由調(diào)整。

• 故障注入。 通過引入故障來模擬網(wǎng)絡(luò)傳輸中的問題（如延遲）來驗(yàn)證系統(tǒng)的健壯性，方便完成系統(tǒng)的各類故障測(cè)試。

• 熔斷。 通過服務(wù)降級(jí)來終止?jié)撛诘年P(guān)聯(lián)性錯(cuò)誤。

• 安全。 在Service Mesh上實(shí)現(xiàn)安全機(jī)制（如TLS），并且很容易在基礎(chǔ)設(shè)施層完成安全機(jī)制更新。

• 多語言支持。 作為獨(dú)立運(yùn)行且對(duì)業(yè)務(wù)透明的 Sidecar 代理，Service Mesh 很輕松地支持多語言的異構(gòu)系統(tǒng)。

• 多協(xié)議支持。 同多語言一樣，也支持多協(xié)議。

• 指標(biāo)和分布式鏈路追蹤。

概括起來，Service Mesh 主要體現(xiàn)在以下 4 個(gè)方面：

• 可見性： 運(yùn)行時(shí)指標(biāo)遙測(cè)、分布式跟蹤。

• 可管理性： 服務(wù)發(fā)現(xiàn)、負(fù)載均衡、運(yùn)行時(shí)動(dòng)態(tài)路由等。

• 健壯性： 超時(shí)、重試、熔斷等彈性能力。

• 安全性： 服務(wù)間訪問控制、TLS 加密通信。

1.3.3 Service Mesh 解決什么問題

從上述Service Mesh的介紹和功能來看：

• 基礎(chǔ)設(shè)施層是Service Mesh的定位，致力于解決微服務(wù)基礎(chǔ)設(shè)施標(biāo)準(zhǔn)化、配置化、服務(wù)化和產(chǎn)品化的問題。

• 服務(wù)間通信是Service Mesh技術(shù)層面對(duì)的問題，對(duì)微服務(wù)屏蔽通信的復(fù)雜度，解決微服務(wù)的通信治理問題。

• 請(qǐng)求的可靠傳遞是Service Mesh的目標(biāo)。

• 輕量級(jí)網(wǎng)絡(luò)代理是Service Mesh的部署方式。

• 對(duì)應(yīng)用程序透明是Service Mesh的亮點(diǎn)和特色，實(shí)現(xiàn)對(duì)業(yè)務(wù)無侵入。

綜合上述，Service Mesh主要解決用戶如下 3 個(gè)維度的痛點(diǎn)需求：

• 完善的微服務(wù)基礎(chǔ)設(shè)施

通過將微服務(wù)通信下沉到基礎(chǔ)設(shè)施層，屏蔽了微服務(wù)處理各種通信問題的復(fù)雜度，形成微服務(wù)之間的抽象協(xié)議層。開發(fā)者無需關(guān)心通信層的具體實(shí)現(xiàn)，也無需關(guān)注RPC通信（包含服務(wù)發(fā)現(xiàn)、負(fù)載均衡、流量調(diào)度、流量降級(jí)、監(jiān)控統(tǒng)計(jì)等）的一切細(xì)節(jié)，真正像本地調(diào)用一樣使用微服務(wù)，通信相關(guān)的一起工作直接交給Service Mesh。

• 語言無關(guān)的通信和鏈路治理

功能上，Service Mesh并沒有提供任何新的特性和能力，Service Mesh提供的所有通信和服務(wù)治理能力在Service Mesh之前的技術(shù)中均能找到，比如Spring Cloud就實(shí)現(xiàn)了完善的微服務(wù)RPC通信和服務(wù)治理支持。

Service Mesh改變的是通信和服務(wù)治理能力提供的方式，通過將這些能力實(shí)現(xiàn)從各語言業(yè)務(wù)實(shí)現(xiàn)中解耦，下沉到基礎(chǔ)設(shè)施層面，以一種更加通用和標(biāo)準(zhǔn)化的方式提供，屏蔽不同語言、不同平臺(tái)的差異性，有利于通信和服務(wù)治理能力的迭代和創(chuàng)新，使得業(yè)務(wù)實(shí)現(xiàn)更加方便。

Service Mesh避免了多語言服務(wù)治理上的重復(fù)建設(shè)，通過Service Mesh語言無關(guān)的通信和服務(wù)治理能力，助力于多語言技術(shù)棧的效率提升。

• 通信和服務(wù)治理的標(biāo)準(zhǔn)化

• 微服務(wù)治理層面，Service Mesh是標(biāo)準(zhǔn)化、體系化、無侵入的分布式治理平臺(tái)。

• 標(biāo)準(zhǔn)化方面，Sidecar成為所有微服務(wù)流量通信的約束標(biāo)準(zhǔn)，同時(shí)Service Mesh的數(shù)據(jù)平臺(tái)和控制平面也通過標(biāo)準(zhǔn)協(xié)議進(jìn)行交互。

• 體系化方面，從全局考慮，提供多維度立體的微服務(wù)可觀測(cè)能力（Metric、Trace、Logging），并提供體系化的服務(wù)治理能力，如限流、熔斷、安全、灰度等。

通過標(biāo)準(zhǔn)化，帶來一致的服務(wù)治理體驗(yàn)，減少多業(yè)務(wù)之間由于服務(wù)治理標(biāo)準(zhǔn)不一致帶來的溝通和轉(zhuǎn)換成本，提升全局服務(wù)治理的效率。

1.3.4 Service Mesh 框架選型

下面對(duì)針對(duì)目前市面上常見的 Service Mesh 框架進(jìn)行的比較匯總，見下表所示：

上述任何一個(gè) Service Mesh 框架都能夠滿足您的基本需求。到?前為?，Istio 具有這幾個(gè)服務(wù)?格框架中最多的功能和靈活性，靈活性意味著復(fù)雜性，因此需要團(tuán)隊(duì)更為充?的準(zhǔn)備。如果只想使?基本的 Service Mesh 治理功能，Linkerd 可能是最佳選擇。如果您想?持同時(shí)包含 Kubernetes 和 VM 的異構(gòu)環(huán)境，并且不需要 Istio 的復(fù)雜性，那么 Consul 可能是您的最佳選擇，?前 Istio 也提供了同時(shí)包含 Kubernetes 和 VM 的異構(gòu)環(huán)境的?持。

從另一個(gè)角度來看，目前 Istio 社區(qū)正在快速迭代以應(yīng)對(duì)各種場(chǎng)景，并力爭(zhēng)作為 Service Mesh 的標(biāo)桿，本文以選取 Istio 框架作為最終遷移框架。

1.4 框架遷移迫在眉睫

為了更好的占領(lǐng)市場(chǎng)，滿足更多業(yè)務(wù)場(chǎng)景的需求，傳統(tǒng)微服務(wù)架構(gòu)（如，基于 Spring Cloud 框架的微服務(wù)架構(gòu)）面臨了眾多新的挑戰(zhàn)，而 Service Mesh 的出現(xiàn)正好解決了這些問題。面對(duì)新的框架體系，對(duì)于傳統(tǒng)微服務(wù)架構(gòu)該如何應(yīng)對(duì)？

對(duì)于 Spring Cloud 框架的微服務(wù)向 Service Mesh 框架遷移必將迫在眉睫，是推翻重來，還是循序遷移？如果遷移，又該如何？

2、Service Mesh 遷移方案

對(duì)于還未涉足 Service Mesh 的企業(yè)或產(chǎn)品，其傳統(tǒng)微服務(wù)架構(gòu)如若已采用 Spring Cloud 框架構(gòu)建，此時(shí)向Service Mesh 框架遷移該如何做呢？需要綜合考慮哪些因素？是否有依可據(jù)呢？

接下來，我們就構(gòu)建基于Spring Cloud 向 Service Mesh 框架遷移提供一些建議方案和思路，供大家參考。

2.1 遷移場(chǎng)景

傳統(tǒng)微服務(wù)框架，我們以最為典型的 Spring Cloud 框架為例進(jìn)行遷移說明。首先，我們先看一下這樣的一個(gè)遷移場(chǎng)景，目前的微服務(wù)架構(gòu)是這樣的，如下圖左邊部分：

• 應(yīng)用是部署在虛擬機(jī)或物理機(jī)上。（服務(wù)還未容器化）

• 框架是基于 Spring Cloud 框架開發(fā)。（服務(wù)中包含的業(yè)務(wù)邏輯和 Spring Cloud 組件相依賴，業(yè)務(wù)和框架耦合度過高）

• 開發(fā)語言是以 Java 為主。（存在跨語言的問題）

• 注冊(cè)中心采用的是 Consul 或 Eureka。（服務(wù)需引入注冊(cè)中心依賴包，存在一定的耦合）

目前開源 Istio 已經(jīng)成為 Service Mesh 事實(shí)上的標(biāo)準(zhǔn)，更是新一代微服務(wù)架構(gòu)發(fā)展的趨勢(shì)，因此公司希望嘗試遷移到 Istio 框架，希望最終形成類似下圖右邊部分。

2.2 遷移路徑

面對(duì)上述遷移場(chǎng)景，確定要引入 Service Mesh 時(shí)，就要徹底搞清楚 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)阻礙或影響未來業(yè)務(wù)的發(fā)展？

• 公司或技術(shù)團(tuán)隊(duì)，是否有能力、人力、精力來投入到 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ù)沒有運(yùn)行在Kubernetes上，因 Service Mesh 當(dāng)前典型的 Istio 框架對(duì) Kubernetes 有著過度依賴，所以可能就無法直接從 Spring Cloud 遷移到 Istio 框架，即使定制修改 Istio 以接觸對(duì) Kubernetes 的依賴，將會(huì)付出很大的代價(jià)。這時(shí)通常有兩條遷移路徑可以選擇。

路徑一：非 Kubernetes 環(huán)境下，先接入 Sidecar

如果當(dāng)前業(yè)務(wù)沒法快速容器化，同時(shí)又有引入 Service Mesh 的迫切需求，可采取先接入 Sidecar，來滿足當(dāng)前業(yè)務(wù)的痛點(diǎn)需求。在引入 Sidecar 時(shí)，要注意其未來的演進(jìn)方向，考慮后續(xù)可能繼續(xù)向 Service Mesh 遷移，一旦時(shí)機(jī)成熟并引入 Kubernetes 容器化后，則能夠順利由 Sidecar 的方式直接演進(jìn)到 Service Mesh。

Service Mesh 當(dāng)前典型的 Istio 框架在非 Kubernetes 下沒有很好的支持（據(jù)說未來會(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ì)來完成 Kubernetes 容器化改造，再接入 Service Mesh。

最后， 基于構(gòu)建的 Service Mesh 框架，將業(yè)務(wù)應(yīng)用逐步遷移到 Service Mesh 上來。

2.3 遷移原則

在實(shí)施遷移時(shí)，必須要時(shí)刻遵守以下遷移原則。

• 漸進(jìn)式遷移： 為了避免 Service Mesh 遷移過程中的風(fēng)險(xiǎn)，必須采用漸進(jìn)式遷移原則，每次只遷移少量服務(wù)，待遷移后觀察足夠長(zhǎng)的時(shí)間，沒有問題后再繼續(xù)遷移。

• 業(yè)務(wù)透明： 為減少 Service Mesh 遷移對(duì)業(yè)務(wù)的影響，減少業(yè)務(wù)的遷移阻力，遷移初期必須確保業(yè)務(wù)完全透明且不需要過多的變更和修改。

• 方案上，為保證遷移對(duì)業(yè)務(wù)的完全透明，在數(shù)據(jù)平面通信上可采用支持透明攔截的方式，對(duì)業(yè)務(wù)請(qǐng)求流量透明攔截。

• 兼容性： 在遷移階段，必然會(huì)存在兩種模式（ Spring Cloud 和 Service Mesh 框架）并存，在遷移過程中需要充分考慮兩者的兼容性，使得遷移前后網(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)過分析，我們可以匯總得知它主要由以下幾部分組成：

• 代理 &網(wǎng)關(guān)： 提供統(tǒng)一對(duì)外或?qū)?nèi)的訪問入口，包括路由、鑒權(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)過分析得知，可以替換的組件包括網(wǎng)關(guān)（Gateway 或者 Zuul，由 Ingress gateway 或者 egress 替換），熔斷器（hystrix，由 Sidecar 替換），注冊(cè)中心（Eureka 及 Eureka client，由 Polit，Sidecar 替換），負(fù)責(zé)均衡（ Ribbon，由 Sidecar 替換）等。

此階段，我們能夠大致知道 Spring Cloud 中的哪些內(nèi)容可以由 Istio 處理，哪些內(nèi)容可以繼續(xù)沿用。

2.4.2 容器化改造

容器化改造，主要針對(duì)目前還未引入 Kubernetes 容器化的場(chǎng)景。

在容器化改造之前，我們有必要知道改造的優(yōu)勢(shì)及要求。

容器化改造優(yōu)勢(shì)：

• 更?。?/strong> 極大的資源利用效率， 最大限度榨取和共享物理資源，多項(xiàng)目更能體現(xiàn)出容器化多優(yōu)勢(shì)，節(jié)約部署 IT 成本。

• 更快： 秒級(jí)啟動(dòng)，實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)更快的開發(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ù)：開發(fā)人員需熟悉 Docker 容器化技術(shù)，熟練編寫 Dockerfile 文件。

• 掌握 Kubernetes 編排系統(tǒng)：熟悉 Kubernetes 容器化編排系統(tǒng)， 熟悉各組件資源清單編寫、高可用、 RBAC 安全策略等。

容器化改造，主要分為以下兩個(gè)階段：

• 容器化構(gòu)建： 將基于 Spring Cloud 搭建的所有服務(wù)實(shí)現(xiàn)容器化構(gòu)建，實(shí)現(xiàn) Docker 鏡像打包。

• 容器化管理： 基于 Kubernetes 進(jìn)行服務(wù)容器的管理。

2.4.2.1 容器化構(gòu)建

容器化構(gòu)建需借助編寫的 Dockerfile 文件，并通過 Jenkins 自動(dòng)化完成對(duì) Docker 鏡像的制作。這里以一個(gè)簡(jiǎn)單的serviceProvider服務(wù)（基于 Spring Cloud 框架開發(fā)）為例說明構(gòu)建過程：

（1）創(chuàng)建 Dockerfile 文件。

在服務(wù)serviceProvider/src/main/docker目錄下創(chuàng)建一個(gè) Dockerfile 文件，內(nèi)容如下：

FROM java:8RUN mkdir /microserviceWORKDIR /microserviceADD /service-provider-1.0.jar /microservice/EXPOSE 8001ENTRYPOINT ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/microservice/service-provider-1.0.jar"]

（2）配置 pom docker-maven-plugin插件。

在服務(wù)serviceProvider 的 pom.xml 中配置 build 部分，內(nèi)容如下：

<!-- 打包配置 -->  <build>    <defaultGoal>install</defaultGoal>    <!-- build后的文件名，默認(rèn)值是${artifactId}-${version}。  -->      <finalName>service-provider-${project.version}</finalName>        <plugins>      <plugin>        <groupId>org.springframework.boot</groupId>        <artifactId>spring-boot-maven-plugin</artifactId>      </plugin>            <!-- 配置docker maven插件，綁定install生命周期，在運(yùn)行maven install時(shí)生成docker鏡像 -->          <plugin>              <groupId>com.spotify</groupId>              <artifactId>docker-maven-plugin</artifactId>              <version>0.4.13</version>              <executions>                  <execution>                      <phase>install</phase>                      <goals>                          <goal>build</goal>                          <goal>tag</goal>                      </goals>                  </execution>              </executions>              <configuration>                  <!-- 修改這里的docker節(jié)點(diǎn)ip，需要打開docker節(jié)點(diǎn)的遠(yuǎn)程管理端口2375?？稍趆osts中進(jìn)行dockerip的配置 -->                  <dockerHost>http://dockerip:2375</dockerHost>                  <imageName>${project.build.finalName}</imageName>                  <baseImage>java</baseImage>                  <!-- 這里的entryPoint定義了容器啟動(dòng)時(shí)的運(yùn)行命令，容器啟動(dòng)時(shí)運(yùn)行 java -jar 包名 , -Djava.security.egd這個(gè)配置解決tomcat8啟動(dòng)時(shí)，因?yàn)樾枰占h(huán)境噪聲來生成安全隨機(jī)數(shù)導(dǎo)致啟動(dòng)過慢的問題-->                  <entryPoint>                      ["java", "-Djava.security.egd=file:/dev/./urandom", "-jar", "/${project.build.finalName}.jar"]                  </entryPoint>                  <resources>                      <resource>                          <targetPath>/</targetPath>                          <directory>${project.build.directory}</directory>                          <include>${project.build.finalName}.jar</include>                      </resource>                  </resources>                  <image>${docker.image.prefix}/${project.build.finalName}</image>                  <newName>${docker.image.prefix}/${project.build.finalName}:${docker.tag}</newName>                  <forceTags>true</forceTags>                  <!-- 如果需要在生成鏡像時(shí)推送到遠(yuǎn)程庫，pushImage設(shè)為true -->                  <pushImage>false</pushImage>              </configuration>          </plugin>    </plugins>  </build>

（3）打包。

在執(zhí)行 mvn package 的時(shí)候，會(huì)根據(jù) pom.xml 中 build 配置自動(dòng)打包 Docker 鏡像，并推送到 Docker 服務(wù)器上。

至此，就順利地完成了容器化構(gòu)建，這一步對(duì)于原有服務(wù)基本沒有影響，打包成功后只需進(jìn)行驗(yàn)證測(cè)試即可，以確保鏡像打包存在問題。

2.4.2.2 容器化管理

容器化管理實(shí)際上就是將服務(wù)容器通過 Kubernetes編排系統(tǒng)，完成對(duì)服務(wù)部署、管理等，需要對(duì) Kubernetes 有一定的了解，會(huì)熟練使用它，看參考之前寫的”Kubernetes從入門到精通“系列文章。

2.4.3 Service Mesh 微服務(wù)平臺(tái)搭建

Service Mesh 我們選取 Istio 框架，關(guān)于選型方案可參考之前文章：Service Mesh 框架選型對(duì)比分析：Linkerd、Envoy、Istio、Conduit。

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)維、流量管控等功能。

上述功能在 Istio 框架上都能找到對(duì)應(yīng)的功能，并通過適當(dāng)?shù)馁Y源清單配置即可完成。

Istio 架構(gòu)圖如下：

至此，一個(gè) Istio 基礎(chǔ)框架搭建完成，能夠提供 Service Mesh 的所有能力。

2.4.3.2 istio 擴(kuò)展和定制

在遷移路徑中已經(jīng)提及過，對(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 中，并通過 Kubernetes CRD 機(jī)制觸發(fā)資源變更事件通知，通知關(guān)心 Istio 資源變更事件的模塊進(jìn)行相關(guān)處理。

如需解除Istio 對(duì) Kubernetes 的綁定，則需要自行實(shí)現(xiàn)這一套 API 管理方式，并且做到平臺(tái)無關(guān)。

（2）通信訪問層面對(duì) kube DNS 的依賴

通信層面，在客戶端發(fā)送請(qǐng)求前，先通過 DNS 獲取服務(wù)的虛擬 IP 地址，Istio 的 DNS 實(shí)現(xiàn)沿用Kubernetes DNS 方案，基于 DNS 通過服務(wù)名實(shí)現(xiàn)直接訪問。因此需要在 DNS 方案層面接觸和Kubernetes 的耦合，并使用平臺(tái)無關(guān)的 DNS 解決方案。

2.4.3.3 兩種框架并存

對(duì)于體量較大的業(yè)務(wù)，不可能一次性遷移完成，需遵守“漸進(jìn)式遷移”原則，逐步遷移，所以實(shí)際遷移過程中可能面臨這樣的訴求：

• 一些存量老業(yè)務(wù)運(yùn)行在虛擬機(jī)或者物理機(jī)上，暫時(shí)沒有容器化改造計(jì)劃，但希望通過 Service Mesh 來做服務(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ù)間卻是互不相同，且無法統(tǒng)一治理。

那么兩種框架并存時(shí)，如何服務(wù)間互通，統(tǒng)一治理呢？

在業(yè)內(nèi)流行這樣一句話：計(jì)算機(jī)科學(xué)領(lǐng)域的任何問題都可以通過增加一個(gè)間接的中間層來解決。

同樣，我們可以針對(duì) Service Mesh 的控制平面做些文章，通過自定義控制插件（WASM）將 Spring Cloud 框架中原有注冊(cè)中心的功能納入進(jìn)來，由控制平面提供原有服務(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)绾螌?yīng)用 Spring Cloud 應(yīng)用逐步向 Service Mesh 遷移呢？

2.4.4.1 去除重疊功能

我們先來看一下 Spring Cloud 框架與 Istio 框架的功能重疊情況：

從上表功能情況，存在大量重疊功能，需將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)注入： 通過手動(dòng)執(zhí)行 istioctl kube-inject 來重新構(gòu)造應(yīng)用的 CRD yaml。

• 自動(dòng)注入： 通過 Kubernetes 的 mutable webhook 回調(diào) istio-sidecar-injector 服務(wù)來重新構(gòu)造應(yīng)用的 CRD yaml。

如下圖所示：

無論是手動(dòng)注入還是自動(dòng)注入，Sidecar 注入的本質(zhì)是將運(yùn)行 Sidecar 所需要的鏡像地址、啟動(dòng)參數(shù)、所連接的 Istio 集群（Pilot、Citadel、Galley）及配置信息填充到注入模版，并添加到應(yīng)用的 CRD yaml 中，最終通過 Kubernetes 持久化資源并拉起應(yīng)用和 Sidecar 的 POD。

此時(shí)，應(yīng)用已成功遷移部署到 Service Mesh中了。

3、總結(jié)

這篇文章從傳統(tǒng)微服務(wù)架構(gòu)開始一步步介紹到 Service Mesh，并提出了傳統(tǒng)微服務(wù)架構(gòu)面臨的挑戰(zhàn)，針對(duì)現(xiàn)狀，如何能夠更好的滿足市場(chǎng)需求，而不被市場(chǎng)淘汰，介紹了傳統(tǒng)微服務(wù)如何平滑遷移至 Service Mesh 的過程，并給出了一些解決方案、步驟及思路，供大家參考。

希望能夠幫您解決實(shí)際遷移過程中遇到的問題，能夠幫助大家在做架構(gòu)演進(jìn)或遷移時(shí)帶來一些思考和啟發(fā)。

感謝各位的閱讀，以上就是“Spring Cloud怎么向Service Mesh框架遷移”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)Spring Cloud怎么向Service Mesh框架遷移這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！