云原生技術范式顛覆

——從Spring Cloud到

Service Mesh框架重構之路

神州信息

徐超

郭總在《數字化的力量》一書提到過：

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

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

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

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

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

01.背景

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

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

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

1.1

傳統微服務架構面臨的挑戰

面對上述暴露出的問題，并在傳統微服務架構下，經過實踐的不斷沖擊，面臨了更多新的挑戰，綜上所述，產生這些問題的原因有以下這幾點：

● 過于綁定特定技術棧。當面對異構系統時，需要花費大量精力來進行代碼的改造，不同異構系統可能面臨不同的改造。

● 代碼侵入度過高。開發者往往需要花費大量的精力來考慮如何與框架或 SDK結合，并在業務中更好的深度融合，對于大部分開發者而言都是一個高曲線的學習過程。

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

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

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

1.2

迎來新一代微服務架構

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

1.2.1 耦合階段

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

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

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

● 每個微服務都重復實現了相同功能的代碼。

● 管理困難。如果某個服務的負載均衡發生變化，則調用它的相關服務都需要更新變化。

● 開發者不能集中精力只關注于業務邏輯開發。

1.2.2 公共庫SDK

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

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

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

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

● 公共庫SDK的管理和維護依然需要耗費開發者的大量精力，并需專門人員來進行管理維護。

1.2.3 Sidecar模式

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

這就是典型的Sidecar代理模式，也被翻譯為邊車代理，它作為與其他服務通信的橋梁，為服務提供額外的網絡特性，并與服務獨立部署，對服務零侵入，更不會受限于服務的開發語言和技術棧，如下圖所示：

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

于是，應用服務終于可以做到跨語言開發、并更專注于業務邏輯的開發。

1.2.4 Service Mesh

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

至此，迎來了全新一代微服務架構——Service Mesh，它將徹底解決了傳統微服務架構所面臨的問題。

1.3

什么是Service Mesh

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

1.3.1 Service Mesh介紹

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

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

在Service Mesh部署網絡結構圖中，綠色方塊為應用服務，藍色方塊為 Sidecar，應用服務之間通過Sidecar進行通信，整個服務通信形成圖中的藍色網絡連線，圖中所有藍色部分就形成了Service Mesh。其具備如下主要特點：

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

● 輕量級網絡代理。

● 應用程序無感知。

● 解耦應用程序的重試/超時、監控、追蹤和服務發現。

Service Mesh的出現解決了傳統微服務框架中的痛點，使得開發人員專注于業務本身，同時，將服務通信及相關管控功能從業務中分離到基礎設施層。

1.3.2 Service Mesh的功能

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

● 動態路由。可通過路由規則來動態路由到所請求的服務，便于不同環境、不同版本等的動態路由調整。

● 故障注入。通過引入故障來模擬網絡傳輸中的問題（如延遲）來驗證系統的健壯性，方便完成系統的各類故障測試。

● 熔斷。通過服務降級來終止潛在的關聯性錯誤。

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

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

● 多協議支持。同多語言一樣，也支持多協議。

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

概括起來，Service Mesh主要體現在以下4個方面：

● 可見性：運行時指標遙測、分布式跟蹤。

● 可管理性：服務發現、負載均衡、運行時動態路由等。

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

● 安全性：服務間訪問控制、TLS加密通信。

1.3.3 Service Mesh解決什么問題

Service Mesh主要解決用戶如下3個維度的痛點需求：

● 完善的微服務基礎設施

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

● 語言無關的通信和鏈路治理

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

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

Service Mesh避免了多語言服務治理上的重復建設，通過Service Mesh語言無關的通信和服務治理能力，助力于多語言技術棧的效率提升。

● 通信和服務治理的標準化

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

■ 標準化方面，Sidecar成為所有微服務流量通信的約束標準，同時Service Mesh的數據平臺和控制平面也通過標準協議進行交互。

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

通過標準化，帶來一致的服務治理體驗，減少多業務之間由于服務治理標準不一致帶來的溝通和轉換成本，提升全局服務治理的效率。

1.4

框架遷移迫在眉睫

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

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

（上篇完）