云原生技術(shù)范式顛覆

——從Spring Cloud到

Service Mesh框架重構之路

神州信息

徐超

郭總在《數字化的力量》一書(shū)提到過(guò)：

數字化時(shí)代的新技術(shù)范式最典型的特征是以云原生為核心，以大數據、物聯(lián)網(wǎng)、云計算、可穿戴設備、區塊鏈、人工智能等多種數字技術(shù)為通用技術(shù)。與一百多年前的電力技術(shù)、兩百多年前的蒸汽機技術(shù)一樣，這種新技術(shù)范式所包含的一系列通用技術(shù)正日益滲透到經(jīng)濟、社會(huì )和生活的各個(gè)角落，廣泛應用于傳統產(chǎn)業(yè)的各個(gè)領(lǐng)域。

郭為.數字化的力量[M]. 北京：機械工業(yè)出版社，2022.

作為新一代微服務(wù)架構體系，Service Mesh技術(shù)有效地解決了Spring Cloud微服務(wù)架構和服務(wù)治理過(guò)程中的痛點(diǎn)問(wèn)題，一經(jīng)推出便引起了很大的反響。近幾年來(lái)，伴隨著(zhù)云原生的熱火朝天，Service Mesh被推向了巔峰，從陌生走向大家的視界。對于初創(chuàng )企業(yè)或全新產(chǎn)品，選擇 Service Mesh變得相對輕松很多，畢竟不存在遷移的問(wèn)題。但對于大部分企業(yè)或成熟的產(chǎn)品體系，這樣大的架構轉型就變得很難以實(shí)施，需要多加權衡利弊，面對Service Mesh帶來(lái)的好處，不得不迫使向它靠攏。

目前很多企業(yè)或產(chǎn)品還是采用基于SDK的傳統微服務(wù)框架（例如，Dubbo、Spring Cloud等）進(jìn)行服務(wù)治理，而隨著(zhù)Service Mesh的普及，越來(lái)越多的企業(yè)開(kāi)始布局自己的Service Mesh框架體系，但多數企業(yè)剛開(kāi)始不會(huì )激進(jìn)地將所有業(yè)務(wù)遷移至Serivice Mesh，畢竟這樣風(fēng)險太大、收益太慢。像Java技術(shù)棧應用依然保留原框架，而非Java技術(shù)棧應用采用Service Mesh框架，不同開(kāi)發(fā)語(yǔ)言可以用不同的技術(shù)框架，但業(yè)務(wù)不能被框架割裂，那么在這兩種架構體系下應用服務(wù)如何互聯(lián)互通？微服務(wù)如何統一治理？傳統微服務(wù)又如何平滑遷移至Service Mesh呢？

如何解決上述問(wèn)題呢？今天我們就針對構建基于Spring Cloud向Service Mesh框架遷移過(guò)程中的諸多問(wèn)題展開(kāi)討論，盡可能提供一套完善的解決方案和遷移思路，供大家參考。

01.背景

微服務(wù)是一個(gè)很大的概念，不同人對它的理解都各不相同，甚至在早期微服務(wù)架構中出現了一批四不像的微服務(wù)架構產(chǎn)品，有人把單純引入Spring Boot、Spring Cloud框架也叫做微服務(wù)架構，實(shí)際上卻只是將它作為服務(wù)的Web運行環(huán)境而已。

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

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

1.1

傳統微服務(wù)架構面臨的挑戰

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

● 過(guò)于綁定特定技術(shù)棧。當面對異構系統時(shí)，需要花費大量精力來(lái)進(jìn)行代碼的改造，不同異構系統可能面臨不同的改造。

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

● 多語(yǔ)言支持受限。微服務(wù)提倡不同組件可以使用最適合它的語(yǔ)言開(kāi)發(fā)，但是在Spring Cloud框架下就是Java的天下，多語(yǔ)言的支持難度很大。這也就導致在面對異構系統對接時(shí)的無(wú)奈，或退而求其次的方案。

● 老舊系統維護難。面對老舊系統，很難做到統一維護、治理、監控等，在過(guò)度時(shí)期往往需要多個(gè)團隊分而管之，維護難度加大。

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

1.2

迎來(lái)新一代微服務(wù)架構

為了解決傳統微服務(wù)面臨的問(wèn)題，以應對全新的挑戰，微服務(wù)架構也進(jìn)一步演化，最終催生了Service Mesh的出現，迎來(lái)了新一代微服務(wù)架構。為了更好地理解Service Mesh的概念和存在的意義，我們來(lái)回顧一下這一演進(jìn)過(guò)程。

1.2.1 耦合階段

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

這種方案雖然易于實(shí)現，但從設計角度來(lái)講卻存在一定的缺陷。

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

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

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

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

1.2.2 公共庫SDK

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

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

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

● 這些公共庫SDK一般都是通過(guò)特定語(yǔ)言實(shí)現，缺乏多語(yǔ)言的支持，在對現有系統整合時(shí)有一定的局限性。

● 公共庫SDK的管理和維護依然需要耗費開(kāi)發(fā)者的大量精力，并需專(zhuān)門(mén)人員來(lái)進(jìn)行管理維護。

1.2.3 Sidecar模式

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

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

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

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

1.2.4 Service Mesh

把Sidecar模式充分應用于一個(gè)龐大的微服務(wù)架構系統，為每個(gè)應用服務(wù)配套部署一個(gè)Sidecar代理，完成服務(wù)間復雜的通信，最終得到一個(gè)如下所示的網(wǎng)絡(luò )拓撲結構，這就是Service Mesh，又稱(chēng)之為“服務(wù)網(wǎng)格”。

至此，迎來(lái)了全新一代微服務(wù)架構——Service Mesh，它將徹底解決了傳統微服務(wù)架構所面臨的問(wèn)題。

1.3

什么是Service Mesh

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

1.3.1 Service Mesh介紹

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

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

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

● 應用程序間通訊的中間層。

● 輕量級網(wǎng)絡(luò )代理。

● 應用程序無(wú)感知。

● 解耦應用程序的重試/超時(shí)、監控、追蹤和服務(wù)發(fā)現。

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

1.3.2 Service Mesh的功能

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

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

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

● 熔斷。通過(guò)服務(wù)降級來(lái)終止潛在的關(guān)聯(lián)性錯誤。

● 安全。在Service Mesh上實(shí)現了安全機制（如TLS），并且很容易在基礎設施層完成安全機制更新。

● 多語(yǔ)言支持。作為獨立運行且對業(yè)務(wù)透明的Sidecar代理，Service Mesh很輕松地支持多語(yǔ)言的異構系統。

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

● 指標和分布式鏈路追蹤。

概括起來(lái)，Service Mesh主要體現在以下4個(gè)方面：

● 可見(jiàn)性：運行時(shí)指標遙測、分布式跟蹤。

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

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

● 安全性：服務(wù)間訪(fǎng)問(wèn)控制、TLS加密通信。

1.3.3 Service Mesh解決什么問(wèn)題

Service Mesh主要解決用戶(hù)如下3個(gè)維度的痛點(diǎn)需求：

● 完善的微服務(wù)基礎設施

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

● 語(yǔ)言無(wú)關(guān)的通信和鏈路治理

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

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

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

● 通信和服務(wù)治理的標準化

■ 微服務(wù)治理層面，Service Mesh是標準化、體系化、無(wú)侵入的分布式治理平臺。

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

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

通過(guò)標準化，帶來(lái)一致的服務(wù)治理體驗，減少多業(yè)務(wù)之間由于服務(wù)治理標準不一致帶來(lái)的溝通和轉換成本，提升全局服務(wù)治理的效率。

1.4

框架遷移迫在眉睫

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

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

（上篇完）