鑽石舞台

Github 地址：https://github.com/Tencent/spring-cloud-tencent

DD自出版了國內第一本Spring Cloud書籍以來，對於Spring Cloud生態的關注沒有斷過，在國產套件Spring Cloud Alibaba發布之後，也是第一時間跟進，發布了國內最早的Spring Cloud Alibaba教程，幫助大家快速的入門學習。

這次Spring CloudTencent發布，DD也準備繼續把這塊內容加入到一直在維護的Spring Cloud專題教程中！這些內容，我會繼續收錄在我博客的這個頁面中找到：

https://blog.didispace.com/spring-cloud-learning/

當然了，公眾號上我會持續跟進這塊更新的推送，所以對Spring CloudTencent感興趣的小夥伴，記得關注公眾號：程序猿DD，第一時間獲得內容更新！

張樂

騰訊雲技術專家，Spring Cloud Tencent 社區負責人，騰訊雲微服務引擎 TSE 核心研發。一直致力於微服務領域研發工作，例如配置中心、註冊中心、服務治理等領域。

張皓天

騰訊高級研發工程師，Spring Cloud Tencent PMC，Polaris Java PMC。

1. Spring Boot + Spring Cloud 仍是 Java 生態最主流的框架

2014 年 4 月 Spring Boot 發布 1.0 版本，經過 8 年時間的發展，Spring Boot 已然成為 Java 開發框架的事實標準。在分布式微服務領域，2016 年 1 月 Spring Cloud 發布 Angel.SR5 版本。Spring Cloud 延承了 Spring Boot 最核心的組件化、低配置快速集成的核心思想，同時定義了一套標準的微服務 SPI。基於這套 SPI 出現了 Spring Cloud Netfix 等優秀的微服務解決方案實現套件。在遠程服務調用框架方面，Feign 和 RestTemplate 基於普適的 HTTP 協議，在易用性、可觀測性、跨語言等方面具備天然的優勢。所以 Spring Cloud 自 2016 年發布第一個版本之後蓬勃發展。

從行業情況看，Spring Boot + Spring Cloud 是目前 Java 使用最廣泛的開發框架之一。

2018 年開始以 Istio 為代表的 ServiceMesh 開始在社區中孵化，到 2022 年已經有非常多的 ServiceMesh 產品。ServiceMesh 核心思想是下沉服務調用相關的基礎能力到獨立的 Sidecar 進程，通過流量代理的方式治理流量。任何一種方案都不是萬能藥， Sidecar 模式也存在一些問題。例如：高度依賴底層 Paas 能力治理 Sidecar （注入、版本管理、升級等）、Sidecar 需要額外占用一定的資源、增加一定的網絡延遲、增加排障難度等。所以國內真正能夠落地 ServiceMesh 的企業並不多。

綜上所述，我們認為在未來很長一段時間內 Spring Boot + Spring Cloud 仍是 Java 主流的微服務解決方案，雖然它看上去沒有像 Istio、Dapr 那樣的先進。在滿足企業業務發展訴求的前提下，低成本、高效、穩定的架構方案才是最好的方案。

2. 騰訊 2021 年開源的北極星（PolarisMesh）提供了一站式微服務解決方案

北極星是一款集註冊中心、配置中心、服務治理中心為一體的一站式微服務解決方案，在騰訊內部已覆蓋 90% 的業務，註冊的實例節點數更是達到了 500 萬的規模。在 21 年開源之後，在社區內也有外部公司生產落地。

公司內部的架構師經常會做一些技術選型，比如註冊中心用 Zookeeper、Consul、Nacos 等，配置中心用 Apollo、Nacos，限流熔斷用 Sentinel 。多組件也意味着需要維護多套服務，占用更多的資源，用戶體驗上也難以做到一致性。

所以一站式微服務解決方案能夠大大簡化技術選型、運維、資源成本。當然也可以把北極星當做方案里的一部分，例如只用北極星的服務註冊發現，配置中心仍然選型 Apollo。畢竟還是那個道理，沒有萬能的方案，適合企業業務自身訴求的方案才是最好的方案。

另外北極星在某些能力橫向對比上也有一定的優勢。例如完全無狀態的註冊中心更加便於運維，強大的服務路由能力支持複雜的業務場景等。具體的產品功能在第二部分會更加詳細的介紹。

3. 小結

基於以上兩點核心原因，把北極星作為 Spring Cloud 一個開箱即用的實現套件就順理成章了。既能滿足 Spring Cloud 的用戶，又能滿足北極星 Java 的用戶。當然 Spring Cloud Tencent 目前只對接了北極星的能力，後續會支持更多騰訊開源的優秀產品。

為什麼要做 Spring Cloud Tencent

目前 Spring Cloud Tencent 主要提供了微服務領域常見的服務註冊與發現、配置中心、服務路由、限流熔斷以及元數據鏈路透傳能力。接下去會詳細介紹每一部分的能力。

2.1 服務註冊與發現 (Spring Cloud Tencent Polaris Discovery)

服務註冊與發現是 Spring Cloud Tencent 最為核心的功能之一，通過實現 Spring Cloud 的服務註冊與發現的標準接口，提供微服務應用快速接入北極星服務註冊中心的能力。開發者通過簡單的引入 Spring Cloud Tencent 服務註冊與發現的依賴，即可使用北極星的服務註冊與發現功能。接入服務註冊與發現之後，還能按需使用北極星提供的強大服務治理能力，例如場景化的服務路由能力、服務熔斷能力等。方便開發者針對微服務的實際生產場景作出個性化的服務治理配置。

北極星的服務模型包括命名空間、服務和服務實例。

命名空間

命名空間提供了一種在同一個註冊中心下資源的邏輯隔離的機制，同一命名空間下的服務命名必須唯一，但是跨命名空間允許存在同名的服務。命名空間常用於區分不同的環境或者多個業務之間的服務隔離。

服務

服務也是邏輯的概念，提供一個特定業務領域的服務能力。例如訂單服務，用戶服務，轉賬服務等。

服務實例

服務實例是服務下的一個具體的物理節點

Spring Cloud Tencent 在基礎的服務註冊發現上，提供了一些拓展能力。首先，Spring Cloud Tencent 集成了北極星的一些路由插件，通過在北極星控制台頁面更改服務實例的隔離狀態或者權重值，都可以實現服務實例的動態上下線的特性，如上圖所示。

Spring Cloud Tencent 還提供了多服務註冊與發現的進階功能。舉個例子，公司內部多個部門或組織使用了不同的服務註冊中心，當決策技術棧統一或是遷移到北極星註冊中心時，需要使用平滑的方式進行業務改造，而非直接替換原有的 SDK 接入北極星註冊中心。此時可以使用 Spring Cloud Tencent 的多服務註冊與發現的能力，幫助開發者的微服務應用過渡技術棧轉換的尷尬期。

Spring Cloud Tencent 提供的這樣一系列針對服務註冊與發現的周邊功能，完善了微服務架構的治理與管控能力。

2.2 配置中心 (Spring Cloud Tencent Polaris Config)

今年上半年北極星開始支持配置中心的能力。北極星配置中心核心配置三元組模型為：

用於邏輯隔離集群的能力，例如常用於隔離環境。

配置文件組，一組配置文件的集合。在 Spring Cloud Tencent 里，我們推薦的最佳實踐是一個應用為一個 FileGroup。對於框架類的配置，以框架名作為一個 FileGroup， 例如 dubbo。

配置文件，例如 properties 、yml 格式的配置文件。配置文件為最小管理單元，而不是配置文件里的配置項。

[Namespace, FileGroup, File] 唯一定位一份配置文件。我們在設計模型的時候，參考了業界主流的配置中心產品，我們認為配置文件、配置文件組的概念，是開發者廣泛認知且理解成本最低的配置領域模型，例如本地磁盤的文件夾和文件的概念。

配置中心核心能力是配置管理能力以及動態實時推送能力。在配置管理方面，一個應用往往具有非常多的配置文件，如何清晰的管理配置文件是一個非常重要的能力。我們在管控台設計 UI 時，開創性的把文件名以 / 作為分隔符樹狀形式展示。如下圖所示，可以按應用模塊劃分目錄，通過目錄方式能夠清晰管理一個應用下雜亂的配置文件。

另外在 Spring Cloud 集成方面，眾所周知 Spring Boot 會自動加載應用 resources 目錄下的 application.yml、application.properties 以及優先級更高的 application-{activeProfile}.yml 文件到 Spring 容器里。用戶在做遷移時，只需把 resources 目錄下所有的配置文件原封不動的上傳到北極星即可。

2.3 服務路由 (Spring Cloud Tencent Polaris Router)

在微服務領域，由於服務做了細粒度的拆分部署服務變的非常的輕量靈活。在結合 k8s 雲原生極速彈性能力之後變的更加的強大。但是底層的 Paas 能力只是提供了基礎彈性能力，真正發揮能力需要依賴上層的流量調配的能力。

放眼 Spring Cloud 生態，能夠深度整合 Spring Cloud 提供場景化服務路由能力的組件套件並不多。這裡解釋一下場景化，服務調用框架根據一定的規則實現服務路由的能力我們稱之為底層原子能力。原子能力是非常通用的能力，但是很多時候並不能直接用於具體的業務場景。例如常見的測試環境分組，就近路由，藍綠髮布等稱之為場景。服務路由只有做了場景化之後，才能真正做到開箱即用服務於業務。

Spring Cloud Tencent Polaris Router 目前實現了兩種場景化的路由能力以及一種非常靈活的規則路由的能力。

元數據路由

服務實例都會附屬一組元數據，例如環境信息，機房信息等等。元數據路由簡單的講就是以元數據信息作為路由的依據進來路由。這樣講還是有些抽象，我們以一個測試環境例子來解釋一下。

上圖是非常經典的用於解決測試環境衝突的方案。一次迭代中 SvcA 需要和 SvcD 聯調，當團隊人數少的時候，可以直接把 stable 環境部署成開發分支代碼然後進行聯調。但是當多個開發任務並行的情況下就會出現環境爭搶的情況。一種解決方式是每個開發任務獨立部署一套全鏈路的環境，這種方式耗時耗力效果還很差。業界最主流的做法就是上圖所示，每個開發任務子環境只需要部署聯調的應用即可，鏈路上不在子環境裡的服務都路由回 stable 穩定環境。

使用 Spring Cloud Tencent 為了達到以上的目的，只需要每個服務部署的時候，增加以下兩個環境變量即可實現。

Spring Cloud Tencent Polaris Router 組件會自動讀取以上環境變量，並在每次服務調用時優先調用到跟當前實例 ENV 值一樣的目標實例。

元數據路由使用的場景非常廣泛，更多的細節請查閱 Github Wiki。

規則路由

元數據路由本質上是基於服務實例的元數據進行篩選，是為了支持具體特定的場景而內置的服務路由能力。無需下發任何路由規則，使用起來非常簡單。

而實際業務場景非常複雜，例如以下幾種典型的業務場景：

以上兩種業務場景，則無法通過元數據路由實現。因為涉及到業務請求參數，而不是系統維度的環境變量。規則路由就是用於滿足複雜業務場景而實現的一套基於規則的服務路由實現。

一個典型的規則如下圖所示：

上圖表達的含義是：HTTP Query Param 的 uid 參數值為 100 時，調用到 ENV=gray 的實例分組。通過路由規則能夠描述出絕大多數複雜的業務場景。

為了便於使用， Spring Cloud Tencent 內置了一套表達式標籤規則，自動從 HTTP 請求中解析標籤值。目前支持的表達式規則有：

規則路由相對比較複雜，更多的細節請查閱 Github Wiki。

就近路由

生產環境服務為了高可用、容災等能力往往需要多機櫃、多機房、多地域部署。

如上圖所示，範圍從小到大依次為: Campus < Zone < Region < All其中 Campus、Zone、Region 在服務註冊發現領域模型里統一定義為元數據，是一種特殊的位置元數據（Location Metadata）。

就近路由顧名思義，服務調用時按照同 Campus、同 Zone、同 Region 的優先級從高到低依次選取目標服務實例。核心是減少服務調用因物理距離增加的網絡耗時。本質上，就近路由是一種基於特定一組位置元數據的元數據路由。

通過 Spring Cloud Tencent 實現就近路由，只需要在服務實例上打上以下環境變量即可。

2.4 服務限流（Spring Cloud Tencent Polaris Ratelimit）

隨着業務發展的日益壯大，網絡請求量也越來越多，導致在某些場景下，業務應用的服務端會出現爆發式的流量湧入，因此需要對服務提供方的給予一些保護手段。通過服務限流功能，開發者可以通過控制 QPS 的方式，以避免被瞬時的流量高峰衝垮，從而保障系統的高可用性。服務限流主要有兩個應用場景，過載保護和業務防刷。過載保護是保護業務不被突發流量打垮，業務防刷是防止惡意用戶發送過多流量影響其他正常用戶。Spring Cloud Tencent 內置了針對 Spring Web 和 Spring WebFlux 場景的限流 Filter 幫助業務快速接入北極星的限流能力。

Spring Cloud Tencent 支持北極星提供的兩種類型的服務限流能力，即單機限流與分布式限流。

單機限流

單機限流是針對單個被調實例的級別的限流，流量限額只針對當前被調實例生效，不共享，如下圖所示。單機限流一般適用於保護服務自身不被打垮，按照每個服務集群單機的容量來計算配額。

單機限流的效果分為快速失敗和勻速排隊。快速失敗指的是當 QPS 到達限流規則指定的配額時，立刻返回一個限流類型錯誤響應給所有超過閾值的請求。而勻速排隊是一種基於漏桶算法實現的削峰填谷限流方式，幫助服務端能夠在流量洪峰到達時，還能保證一個勻速處理的狀態，讓一部分請求在一段排隊等待時間後還能被處理，而不是直接失敗。關於勻速排隊的詳細介紹可以參考 Github 官方 Wiki。

分布式限流

分布式限流是針對服務下所有實例級別的限流，多個服務實例共享同一個全局流量限額，如下圖所示。分布式限流一般適用於保護第三方服務或者公共服務（比如保護數據庫）；或者是在網關層進行限流，對通過網關接入的後端服務進行保護。

Spring Cloud Tencent 提供了自定義限流規則能力，開發者可以根據自身的業務場景定製對應的限流規則。

2.5 服務熔斷（Spring Cloud Tencent Polaris Circuitbreaker）

在微服務架構的運維場景下，有時候會遇到單點服務實例故障的情況，如果不能及時剔除，那麼仍舊會有請求轉發到故障的服務實例上。Spring Cloud Tencent 提供了服務熔斷的能力，通過上報每次服務間調用的結果，判斷被調方服務是否出現故障，進而將其屏蔽，並啟動定時任務對熔斷實例進行探活。在達到恢復條件後對其進行半開恢復。在半開恢復後，釋放少量請求去進行真實業務請求探測。並根據真實業務探測結果去判斷是否完全恢復。這個功能能有效剔除異常的服務實例，為服務治理提供了重要的幫助。

2.6 小結

以上只是簡單介紹了 Spring Cloud Tencent 部分能力，想詳細了解更多的能力請訪問我們 Github 官方主頁。

文章開頭提到我們為什麼要做 Spring Cloud Tencent。我們堅信在 Java 領域 Spring Cloud 在很長一段時間內仍是微服務的主流方案。我們希望結合北極星一站式微服務能力，降低微服務架構門檻，為廣大企業提供開箱即用的全套微服務解決方案。從而使企業更加聚焦自身業務的發展，提高生產力。

一款好用的產品需要經受豐富的場景打磨穩定性、易用性，以及不斷完善自身的產品力。以下是我們目前想到的一些需要支持和完善的點。當然隨着產品的發展、使用的用戶越來越多，會有更多的訴求，我們會持續不斷的迭代下去。

為什麼要做 Spring Cloud Tencent

請加入我們，你的一個建議、Issue、Pull Request 甚至只是一個小小的 Star 都是對我們最大的支持，也是我們持續迭代的動力。

這次Spring CloudTencent發布，DD也準備繼續把這塊內容加入到一直在維護的Spring Cloud專題教程中！這些內容，我會繼續收錄在我博客的這個頁面中找到：

https://blog.didispace.com/spring-cloud-learning/

當然了，公眾號上我會持續跟進這塊更新的推送，所以對Spring CloudTencent感興趣的小夥伴，記得關注公眾號：程序猿DD，第一時間獲得內容更新！

如果您也正在學習，也歡迎來社區發帖分享你的學習筆記，也可以提出學習中的問題，一起交流一起成長：http://spring4all.com/