重磅!Spring Cloud 生態再添新套件:Spring Cloud Tencent

語言: CN / TW / HK
大家好,我是DD。
相信很多關注我的讀者,都是因為Spring Cloud而關注的,但由於Spring Cloud目前比較穩定,在Spring Boot 3.0沒有釋出之前,已經很久沒有大動作了!所以DD這邊的分享也少了很多,但最近Spring Cloud生態還是有大動作了!
Spring Cloud Tencent 於6月14日正式對外開源,作為騰訊開源的一站式微服務框架,Spring Cloud Tencent 實現了 Spring Cloud 標準微服務 SPI ,開發者可以基於 Spring Cloud Tencent 快速開發 Spring Cloud 微服務架構應用。Spring Cloud Tencent 的核心依託騰訊開源的一站式服務發現與治理平臺 Polarismesh ,實現各種分散式微服務場景。

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

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

這次Spring Cloud T encent釋出,DD也準備繼續把這塊內容加入到一直在維護的Spring Cloud專題教程中! 這些內容,我會繼續收錄在我部落格的這個頁面中找到:

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

當然了,公眾號上我會持續跟進這塊更新的推送,所以對Spring Cloud T encent感興趣的小夥伴,記得關注公眾號:程式猿DD,第一時間獲得內容更新!

作者簡介

張樂

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

張皓天

騰訊高階研發工程師,Spring Cloud Tencent PMC,Polaris Java PMC。

為什麼要做 Spring Cloud Tencent

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 主要提供了微服務領域常見的服務註冊與發現、配置中心、服務路由、限流熔斷以及元資料鏈路透傳能力。接下去會詳細介紹每一部分的能力。

(圖: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)

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

  • Namespace

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

  • FileGroup

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

  • File

配置檔案,例如 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 為了達到以上的目的,只需要每個服務部署的時候,增加以下兩個環境變數即可實現。

  • SCT_METADATA_CONTENT_ENV=dev1

  • SCT_METADATA_CONTENT_TRANSITIVE=ENV

Spring Cloud Tencent Polaris Router 元件會自動讀取以上環境變數,並在每次服務呼叫時優先呼叫到跟當前例項 ENV 值一樣的目標例項。

元資料路由使用的場景非常廣泛,更多的細節請查閱 Github Wiki。

規則路由

元資料路由本質上是基於服務例項的元資料進行篩選,是為了支援具體特定的場景而內建的服務路由能力。無需下發任何路由規則,使用起來非常簡單。

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

  • 內部員工路由到一套生產灰度環境,外部普通使用者則路由到生產正式環境

  • VIP 客戶路由到一套高保環境,普通客戶路由到普通環境

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

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

(圖:路由規則配置頁面)

上圖表達的含義是:HTTP Query Param 的 uid 引數值為 100 時,呼叫到 ENV=gray 的例項分組。通過路由規則能夠描述出絕大多數複雜的業務場景。

為了便於使用, Spring Cloud Tencent 內建了一套表示式標籤規則,自動從 HTTP 請求中解析標籤值。目前支援的表示式規則有:

  • ${http.query.xxx}

  • ${http.header.xxx}

  • ${http.cookie.xxx}

  • ${http.method}

  • ${http.uri}

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

就近路由

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

(圖:部署模型圖)

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

就近路由顧名思義,服務呼叫時按照同 Campus、同 Zone、同 Region 的優先順序從高到低依次選取目標服務例項。核心是減少服務呼叫因物理距離增加的網路耗時。本質上,就近路由是一種基於特定一組位置元資料的元資料路由。

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

  • SCT_METADATA_CAMPUS

  • SCT_METADATA_ZONE

  • SCT_METADATA_REGION

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 在很長一段時間內仍是微服務的主流方案。我們希望結合北極星一站式微服務能力,降低微服務架構門檻,為廣大企業提供開箱即用的全套微服務解決方案。從而使企業更加聚焦自身業務的發展,提高生產力。

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

(圖:SCT 規劃)

為什麼要做 Spring Cloud Tencent

  • 如果你也是 Spring Cloud 的愛好者

  • 如果你的公司正在使用 Spring Cloud 並且有一些好的實踐

  • 如果你的公司正在做微服務技術選型

  • ......

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

這次Spring Cloud T encent釋出,DD也準備繼續把這塊內容加入到一直在維護的Spring Cloud專題教程中! 這些內容,我會繼續收錄在我部落格的這個頁面中找到:

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

當然了,公眾號上我會持續跟進這塊更新的推送,所以對Spring Cloud T encent感興趣的小夥伴,記得關注公眾號:程式猿DD,第一時間獲得內容更新!

我們建立了一個高質量的技術交流群,與優秀的人在一起,自己也會優秀起來,趕緊點選加群,享受一起成長的快樂。另外,如果你最近想跳槽的話,年前我花了2周時間收集了一波大廠面經,節後準備跳槽的可以點選這裡領取!

推薦閱讀

··································

你好,我是程式猿DD,10年開發老司機、阿里雲MVP、騰訊雲TVP、出過書創過業、國企4年網際網路6年 從普通開發到架構師、再到合夥人。一路過來,給我最深的感受就是一定要不斷學習並關注前沿。只要你能堅持下來,多思考、少抱怨、勤動手,就很容易實現彎道超車! 所以,不要問我現在幹什麼是否來得及。如果你看好一個事情,一定是堅持了才能看到希望,而不是看到希望才去堅持。相信我,只要堅持下來,你一定比現在更好! 如果你還沒什麼方向,可以先關注我, 這裡會經常分享一些前沿資訊,幫你積累彎道超車的資本。

點選 領取2022最新 10000T 學習資料