云原生技術(shù)范式顛覆
——從Spring Cloud到
Service Mesh框架重構(gòu)之路
神州信息
徐超
郭總在《數(shù)字化的力量》一書提到過：
數(shù)字化時(shí)代的新技術(shù)范式最典型的特征是以云原生為核心，以大數(shù)據(jù)、物聯(lián)網(wǎng)、云計(jì)算、可穿戴設(shè)備、區(qū)塊鏈、人工智能等多種數(shù)字技術(shù)為通用技術(shù)。與一百多年前的電力技術(shù)、兩百多年前的蒸汽機(jī)技術(shù)一樣，這種新技術(shù)范式所包含的一系列通用技術(shù)正日益滲透到經(jīng)濟(jì)、社會(huì)和生活的各個(gè)角落，廣泛應(yīng)用于傳統(tǒng)產(chǎn)業(yè)的各個(gè)領(lǐng)域。
郭為.數(shù)字化的力量[M]. 北京：機(jī)械工業(yè)出版社，2022.
作為新一代微服務(wù)架構(gòu)體系，Service Mesh技術(shù)有效地解決了Spring Cloud微服務(wù)架構(gòu)和服務(wù)治理過程中的痛點(diǎn)問題，一經(jīng)推出便引起了很大的反響。近幾年來，伴隨著云原生的熱火朝天，Service Mesh被推向了巔峰，從陌生走向大家的視界。對于初創(chuàng)企業(yè)或全新產(chǎn)品，選擇 Service Mesh變得相對輕松很多，畢竟不存在遷移的問題。但對于大部分企業(yè)或成熟的產(chǎn)品體系，這樣大的架構(gòu)轉(zhuǎn)型就變得很難以實(shí)施，需要多加權(quán)衡利弊，面對Service Mesh帶來的好處，不得不迫使向它靠攏。
目前很多企業(yè)或產(chǎn)品還是采用基于SDK的傳統(tǒng)微服務(wù)框架（例如，Dubbo、Spring Cloud等）進(jìn)行服務(wù)治理，而隨著Service Mesh的普及，越來越多的企業(yè)開始布局自己的Service Mesh框架體系，但多數(shù)企業(yè)剛開始不會(huì)激進(jìn)地將所有業(yè)務(wù)遷移至Serivice Mesh，畢竟這樣風(fēng)險(xiǎn)太大、收益太慢。像Java技術(shù)棧應(yīng)用依然保留原框架，而非Java技術(shù)棧應(yīng)用采用Service Mesh框架，不同開發(fā)語言可以用不同的技術(shù)框架，但業(yè)務(wù)不能被框架割裂，那么在這兩種架構(gòu)體系下應(yīng)用服務(wù)如何互聯(lián)互通？微服務(wù)如何統(tǒng)一治理？傳統(tǒng)微服務(wù)又如何平滑遷移至Service Mesh呢？
如何解決上述問題呢？今天我們就針對構(gòu)建基于Spring Cloud向Service Mesh框架遷移過程中的諸多問題展開討論，盡可能提供一套完善的解決方案和遷移思路，供大家參考。
01.背景
微服務(wù)是一個(gè)很大的概念，不同人對它的理解都各不相同，甚至在早期微服務(wù)架構(gòu)中出現(xiàn)了一批四不像的微服務(wù)架構(gòu)產(chǎn)品，有人把單純引入Spring Boot、Spring Cloud框架也叫做微服務(wù)架構(gòu)，實(shí)際上卻只是將它作為服務(wù)的Web運(yùn)行環(huán)境而已。
微服務(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ù)雜性的提升及需求的多樣性等（如，對接第三方異構(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)
面對上述暴露出的問題，并在傳統(tǒng)微服務(wù)架構(gòu)下，經(jīng)過實(shí)踐的不斷沖擊，面臨了更多新的挑戰(zhàn)，綜上所述，產(chǎn)生這些問題的原因有以下這幾點(diǎn)：
● 過于綁定特定技術(shù)棧。當(dāng)面對異構(gòu)系統(tǒng)時(shí)，需要花費(fèi)大量精力來進(jìn)行代碼的改造，不同異構(gòu)系統(tǒng)可能面臨不同的改造。
● 代碼侵入度過高。開發(fā)者往往需要花費(fèi)大量的精力來考慮如何與框架或 SDK結(jié)合，并在業(yè)務(wù)中更好的深度融合，對于大部分開發(fā)者而言都是一個(gè)高曲線的學(xué)習(xí)過程。
● 多語言支持受限。微服務(wù)提倡不同組件可以使用最適合它的語言開發(fā)，但是在Spring Cloud框架下就是Java的天下，多語言的支持難度很大。這也就導(dǎo)致在面對異構(gòu)系統(tǒng)對接時(shí)的無奈，或退而求其次的方案。
● 老舊系統(tǒng)維護(hù)難。面對老舊系統(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)、新的機(jī)遇，讓大家紛紛尋找其他解決方案。
1.2
迎來新一代微服務(wù)架構(gòu)
為了解決傳統(tǒng)微服務(wù)面臨的問題，以應(yīng)對全新的挑戰(zhàn)，微服務(wù)架構(gòu)也進(jìn)一步演化，最終催生了Service Mesh的出現(xiàn)，迎來了新一代微服務(wù)架構(gòu)。為了更好地理解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
基于上面存在的問題，便想到將基礎(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)，缺乏多語言的支持，在對現(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ú)立部署，對服務(wù)零侵入，更不會(huì)受限于服務(wù)的開發(fā)語言和技術(shù)棧，如下圖所示：
● 以Sidecar模式進(jìn)行通信代理，實(shí)現(xiàn)了基礎(chǔ)實(shí)施層與業(yè)務(wù)邏輯的完全隔離，在部署、升級時(shí)帶來了便利，做到了真正的基礎(chǔ)設(shè)施層與業(yè)務(wù)邏輯層的徹底解耦。另一方面，Sidecar可以更加快速地為應(yīng)用服務(wù)提供更靈活的擴(kuò)展，而不需要應(yīng)用服務(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ù)雜的通信，最終得到一個(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)為有必要再對Service Mesh進(jìn)行統(tǒng)一的闡述，這樣將有助于理解它，更加便于閱讀接下來的內(nèi)容。
1.3.1 Service Mesh介紹
Service Mesh翻譯為“服務(wù)網(wǎng)格”，作為服務(wù)間通信的基礎(chǔ)設(shè)施層。輕量級高性能網(wǎng)絡(luò)代理，提供安全的、快速的、可靠地服務(wù)間通訊，與實(shí)際應(yīng)用部署一起，但對應(yīng)用透明。應(yīng)用作為服務(wù)的發(fā)起方，只需要用最簡單的方式將請求發(fā)送給本地的服務(wù)網(wǎng)格代理，然后網(wǎng)格代理會(huì)進(jìn)行后續(xù)的操作，如服務(wù)發(fā)現(xiàn)，負(fù)載均衡，最后將請求轉(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)用程序間通訊的中間層。
● 輕量級網(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作為微服務(wù)架構(gòu)中負(fù)責(zé)網(wǎng)絡(luò)通信的基礎(chǔ)設(shè)施層，具備網(wǎng)絡(luò)處理的大部分功能。下面列舉了一些主要功能：
● 動(dòng)態(tài)路由。可通過路由規(guī)則來動(dòng)態(tài)路由到所請求的服務(wù)，便于不同環(huán)境、不同版本等的動(dòng)態(tài)路由調(diào)整。
● 故障注入。通過引入故障來模擬網(wǎng)絡(luò)傳輸中的問題（如延遲）來驗(yàn)證系統(tǒng)的健壯性，方便完成系統(tǒng)的各類故障測試。
● 熔斷。通過服務(wù)降級來終止?jié)撛诘年P(guān)聯(lián)性錯(cuò)誤。
● 安全。在Service Mesh上實(shí)現(xiàn)了安全機(jī)制（如TLS），并且很容易在基礎(chǔ)設(shè)施層完成安全機(jī)制更新。
● 多語言支持。作為獨(dú)立運(yùn)行且對業(yè)務(wù)透明的Sidecar代理，Service Mesh很輕松地支持多語言的異構(gòu)系統(tǒng)。
● 多協(xié)議支持。同多語言一樣，也支持多協(xié)議。
● 指標(biāo)和分布式鏈路追蹤。
概括起來，Service Mesh主要體現(xiàn)在以下4個(gè)方面：
● 可見性：運(yùn)行時(shí)指標(biāo)遙測、分布式跟蹤。
● 可管理性：服務(wù)發(fā)現(xiàn)、負(fù)載均衡、運(yùn)行時(shí)動(dòng)態(tài)路由等。
● 健壯性：超時(shí)、重試、熔斷等彈性能力。
● 安全性：服務(wù)間訪問控制、TLS加密通信。
1.3.3 Service Mesh解決什么問題
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)度、流量降級、監(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)化的方式提供，屏蔽不同語言、不同平臺的差異性，有利于通信和服務(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)化、體系化、無侵入的分布式治理平臺。
■ 標(biāo)準(zhǔn)化方面，Sidecar成為所有微服務(wù)流量通信的約束標(biāo)準(zhǔn)，同時(shí)Service Mesh的數(shù)據(jù)平臺和控制平面也通過標(biāo)準(zhǔn)協(xié)議進(jìn)行交互。
■ 體系化方面，從全局考慮，提供多維度立體的微服務(wù)可觀測能力（Metric、Trace、Logging），并提供體系化的服務(wù)治理能力，如限流、熔斷、安全、灰度等。
通過標(biāo)準(zhǔn)化，帶來一致的服務(wù)治理體驗(yàn)，減少多業(yè)務(wù)之間由于服務(wù)治理標(biāo)準(zhǔn)不一致帶來的溝通和轉(zhuǎn)換成本，提升全局服務(wù)治理的效率。
1.4
框架遷移迫在眉睫
為了更好的占領(lǐng)市場，滿足更多業(yè)務(wù)場景的需求，傳統(tǒng)微服務(wù)架構(gòu)（如，基于Spring Cloud框架的微服務(wù)架構(gòu)）面臨了眾多新的挑戰(zhàn)，而Service Mesh的出現(xiàn)正好解決了這些問題。面對新的框架體系，對于傳統(tǒng)微服務(wù)架構(gòu)該如何應(yīng)對？
對于Spring Cloud框架的微服務(wù)向Service Mesh框架遷移必將迫在眉睫，是推翻重來，還是循序遷移？如果遷移，又該如何？
（上篇完）
