云原生技術范式顛覆
——從Spring Cloud到
Service Mesh框架重構(gòu)之路
神州信息
徐超
郭總在《數(shù)字化的力量》一書提到過：
數(shù)字化時代的新技術范式最典型的特征是以云原生為核心，以大數(shù)據(jù)、物聯(lián)網(wǎng)、云計算、可穿戴設備、區(qū)塊鏈、人工智能等多種數(shù)字技術為通用技術。與一百多年前的電力技術、兩百多年前的蒸汽機技術一樣，這種新技術范式所包含的一系列通用技術正日益滲透到經(jīng)濟、社會和生活的各個角落，廣泛應用于傳統(tǒng)產(chǎn)業(yè)的各個領域。
郭為.數(shù)字化的力量[M]. 北京：機械工業(yè)出版社，2022.
作為新一代微服務架構(gòu)體系，Service Mesh技術有效地解決了Spring Cloud微服務架構(gòu)和服務治理過程中的痛點問題，一經(jīng)推出便引起了很大的反響。近幾年來，伴隨著云原生的熱火朝天，Service Mesh被推向了巔峰，從陌生走向大家的視界。對于初創(chuàng)企業(yè)或全新產(chǎn)品，選擇 Service Mesh變得相對輕松很多，畢竟不存在遷移的問題。但對于大部分企業(yè)或成熟的產(chǎn)品體系，這樣大的架構(gòu)轉(zhuǎn)型就變得很難以實施，需要多加權(quá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è)務不能被框架割裂，那么在這兩種架構(gòu)體系下應用服務如何互聯(lián)互通？微服務如何統(tǒng)一治理？傳統(tǒng)微服務又如何平滑遷移至Service Mesh呢？
如何解決上述問題呢？今天我們就針對構(gòu)建基于Spring Cloud向Service Mesh框架遷移過程中的諸多問題展開討論，盡可能提供一套完善的解決方案和遷移思路，供大家參考。
01.背景
微服務是一個很大的概念，不同人對它的理解都各不相同，甚至在早期微服務架構(gòu)中出現(xiàn)了一批四不像的微服務架構(gòu)產(chǎn)品，有人把單純引入Spring Boot、Spring Cloud框架也叫做微服務架構(gòu)，實際上卻只是將它作為服務的Web運行環(huán)境而已。
微服務紛紛落地，并投入生產(chǎn)，但隨著微服務規(guī)模的不斷壯大，每增加一個微服務，就可能會增加一些依賴的基礎設施和第三方的配置，比如Kafka實例配置等，相應CI/CD的配置也會增加或調(diào)整。同時隨著微服務數(shù)量增多、業(yè)務復雜性的提升及需求的多樣性等（如，對接第三方異構(gòu)系統(tǒng)等），服務間通信的錯綜復雜，一步步地將微服務變得更加臃腫，服務治理也是難上加難，而這些問題在單體架構(gòu)中卻是很容易解決。為此，有人開始懷疑當初微服務化是否是明智之選，甚至考慮回歸到傳統(tǒng)單體應用。
正如下圖所示，PPT中的微服務總是美好的，但現(xiàn)實中的微服務卻是一團糟糕，想甩甩不掉，越看越糟心。難道就沒有辦法了么？
1.1
傳統(tǒng)微服務架構(gòu)面臨的挑戰(zhàn)
面對上述暴露出的問題，并在傳統(tǒng)微服務架構(gòu)下，經(jīng)過實踐的不斷沖擊，面臨了更多新的挑戰(zhàn)，綜上所述，產(chǎn)生這些問題的原因有以下這幾點：
● 過于綁定特定技術棧。當面對異構(gòu)系統(tǒng)時，需要花費大量精力來進行代碼的改造，不同異構(gòu)系統(tǒng)可能面臨不同的改造。
● 代碼侵入度過高。開發(fā)者往往需要花費大量的精力來考慮如何與框架或 SDK結(jié)合，并在業(yè)務中更好的深度融合，對于大部分開發(fā)者而言都是一個高曲線的學習過程。
● 多語言支持受限。微服務提倡不同組件可以使用最適合它的語言開發(fā)，但是在Spring Cloud框架下就是Java的天下，多語言的支持難度很大。這也就導致在面對異構(gòu)系統(tǒng)對接時的無奈，或退而求其次的方案。
● 老舊系統(tǒng)維護難。面對老舊系統(tǒng)，很難做到統(tǒng)一維護、治理、監(jiān)控等，在過度時期往往需要多個團隊分而管之，維護難度加大。
上述這些問題都是在所難免，眾所周知技術演進來源于實踐中不斷的摸索，將功能抽象、解耦、封裝、服務化。隨著傳統(tǒng)微服務架構(gòu)暴露出的這些問題，將迎來新的挑戰(zhàn)、新的機遇，讓大家紛紛尋找其他解決方案。
1.2
迎來新一代微服務架構(gòu)
為了解決傳統(tǒng)微服務面臨的問題，以應對全新的挑戰(zhàn)，微服務架構(gòu)也進一步演化，最終催生了Service Mesh的出現(xiàn)，迎來了新一代微服務架構(gòu)。為了更好地理解Service Mesh的概念和存在的意義，我們來回顧一下這一演進過程。
1.2.1 耦合階段
在微服務架構(gòu)中，服務發(fā)現(xiàn)、熔斷、治理等能力是微服務架構(gòu)重要的組成部分。微服務化之后，服務更加的分散，復雜度變得更高，起初開發(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模式充分應用于一個龐大的微服務架構(gòu)系統(tǒng)，為每個應用服務配套部署一個Sidecar代理，完成服務間復雜的通信，最終得到一個如下所示的網(wǎng)絡拓撲結(jié)構(gòu)，這就是Service Mesh，又稱之為“服務網(wǎng)格”。
至此，迎來了全新一代微服務架構(gòu)——Service Mesh，它將徹底解決了傳統(tǒng)微服務架構(gòu)所面臨的問題。
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)架構(gòu)微服務化后的服務間通信和治理問題。服務網(wǎng)格由Sidecar節(jié)點組成，這個模式的精髓在于實現(xiàn)了數(shù)據(jù)面（業(yè)務邏輯）和控制面的解耦。具體到微服務架構(gòu)中，即給每一個微服務實例同步部署一個Sidecar。
在Service Mesh部署網(wǎng)絡結(jié)構(gòu)圖中，綠色方塊為應用服務，藍色方塊為 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作為微服務架構(gòu)中負責網(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很輕松地支持多語言的異構(gòu)系統(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)微服務架構(gòu)（如，基于Spring Cloud框架的微服務架構(gòu)）面臨了眾多新的挑戰(zhàn)，而Service Mesh的出現(xiàn)正好解決了這些問題。面對新的框架體系，對于傳統(tǒng)微服務架構(gòu)該如何應對？
對于Spring Cloud框架的微服務向Service Mesh框架遷移必將迫在眉睫，是推翻重來，還是循序遷移？如果遷移，又該如何？
（上篇完）
