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