GitHub 標星 11000+，阿里開源的微服務組件如何連續 10 年扛住雙十一大促？

做者 | 宿何  阿里雲高級開發工程師

導讀：疫情期間，「卡」成了不少人線上體驗的關鍵詞。線上預定購買口罩時，忽然不能付款了；在線選課，被提示請求過多，系統沒法響應；在線辦公/教學時，圖像或聲音卡住了……這些可用性降低的場景嚴重的影響了用戶體驗，也下降了公司的工做效率。面對「卡」住了的狀況 ，做爲開發者的咱們，須要預先經過一些手段來提早對不穩定的因素進行防禦，同時在突發流量的狀況下，也要具有快速止損的能力。

近年來，微服務的穩定性一直是開發者很是關注的話題。隨着業務從單體架構向分佈式架構演進以及部署方式的變化，服務之間的依賴關係變得愈來愈複雜，業務系統也面臨着巨大的高可用挑戰。

如何保障服務的可用性？這是一個很是龐大的話題，涉及到方方面面，其中一個重要的手段就是流控降級。

爲何要進行流控降級？

流量是很是隨機性的、不可預測的。前一秒可能還風平浪靜，後一秒可能就出現流量洪峯了（例如 雙11 零點的場景）。

然而咱們的系統容量老是有限的，若是突如其來的流量超過了系統的承受能力，就可能會致使請求處理不過來，堆積的請求處理緩慢，CPU/Load 飆高，最終致使系統崩潰。所以，咱們須要針對這種突發的流量來進行限制，在儘量處理請求的同時來保障服務不被打垮。

一個服務經常會調用別的模塊，多是另外的一個遠程服務、數據庫，或者第三方 API 等。

例如，支付的時候，可能須要遠程調用銀聯提供的 API；查詢某個商品的價格，可能須要進行數據庫查詢。然而，這個被依賴服務的穩定性是不能保證的。若是依賴的服務出現了不穩定的狀況，請求的響應時間變長，那麼調用服務的方法的響應時間也會變長，線程會產生堆積，最終可能耗盡業務自身的線程池，服務自己也變得不可用。

現代微服務架構都是分佈式的，由很是多的服務組成。不一樣服務之間相互調用，組成複雜的調用鏈路。以上的問題在鏈路調用中會產生放大的效果。複雜鏈路上的某一環不穩定，就可能會層層級聯，最終致使整個鏈路都不可用。所以咱們須要對不穩定的服務進行熔斷降級，暫時切斷不穩定調用，避免局部不穩定因素致使總體的雪崩。

那麼是否是服務的量級很小就不用進行限流防禦了呢？是否是微服務的架構比較簡單就不用引入熔斷保護機制了呢？

其實，這與請求的量級、架構的複雜程度無關。不少時候，可能正是一個很是邊緣的服務出現故障而致使總體業務受影響，形成巨大損失。咱們須要具備面向失敗設計的意識，在平時就作好容量規劃和強弱依賴的梳理，合理地配置流控降級規則，作好事前防禦，而不是在線上出現問題之後再進行補救。

那麼你們可能想問：有沒有什麼方法來快速進行高可用防禦呢？如何作到均勻平滑的用戶訪問？如何預防這些不穩定因素帶來的影響？今天咱們就來你們具體分享承載阿里巴巴近 10 年雙十一大促穩定性場景的流量控制組件 —— Sentinel 的實踐。

Sentinel：面向雲原生微服務的流量控制、熔斷降級組件

Sentinel 是阿里巴巴開源的，面向分佈式服務架構的流量控制組件，目前在 GitHub 已收穫 11,071 Star。

該組件主要以流量爲切入點，從流量控制、流量整形、熔斷降級、系統自適應保護等多個維度來幫助開發者保障微服務的穩定性。Sentinel 承接了阿里巴巴近 10 年的 雙11 大促流量的核心場景，例如秒殺、冷啓動、消息削峯填谷、集羣流量控制、實時熔斷下游不可用服務等，是保障微服務高可用的利器。

Sentinel 裏的兩個核心概念 —— 資源與規則。資源（Resource）能夠理解爲須要進行防禦的代碼塊（或調用），好比 SQL 訪問、REST API 訪問、Dubbo 服務調用、Reactive 響應式服務、API 網關的路由訪問，甚至是任意的代碼塊，均可以做爲 Sentinel 的資源。

用戶能夠經過 Sentinel API 或註解手動進行資源埋點，或者經過 Sentinel 提供的框架適配模塊引入依賴一鍵接入。規則則是針對某個資源進行的控制手段，好比咱們能夠針對某個服務、方法來配置流控規則、降級規則等來達到高可用防禦的效果。

其核心特性與技術以下：

• 基於滑動窗口結構的實時統計，性能好的同時又能夠保證統計的準確性；
• 高度可擴展能力：基礎核心 + SPI 接口擴展能力，用戶能夠方便地擴展流控、通訊、監控等功能；
• 多樣化的流量控制策略（資源粒度、調用關係、流控指標、流控效果等多個維度），提供分佈式集羣流控的能力，同時提供熱點流量探測和防禦的能力；
• 對不穩定服務進行熔斷降級和隔離；

• 全局維度的系統負載自適應保護，根據系統水位實時調節流量；
• 覆蓋 API Gateway 場景，爲 Spring Cloud Gateway、Zuul 提供網關流量控制的能力；
• 雲原生場景提供 Envoy 服務網格集羣流量控制的能力；
• 實時監控和規則動態配置管理能力。

同時，Sentinel 提供一個簡單的所見即所得的控制檯，能夠接入控制檯對服務進行實時監控，同時能夠在控制檯實時配置、管理規則：

下面介紹 Sentinel 的一些常見的使用場景和最佳實踐：

在服務提供方（Service Provider）的場景下，咱們須要保護服務提供方自身不被流量洪峯打垮。這時候一般根據服務提供方的服務能力進行流量控制，或針對特定的服務調用方進行限制。咱們能夠結合前期壓測評估核心接口的承受能力，配置 QPS 模式的限流，當每秒的請求量超過設定的閾值時，會自動拒絕多餘的請求。

爲了不調用其餘服務時被不穩定的服務拖垮自身，須要在服務調用端（Service Consumer）對不穩定服務依賴進行隔離和熔斷。手段包括信號量隔離、異常比例降級、RT 降級等多種手段。

當系統長期處於低水位的狀況下，流量忽然增長時，直接把系統拉昇到高水位可能瞬間把系統壓垮。這時候咱們能夠藉助 Sentinel 的 WarmUp 流控模式控制經過的流量緩慢增長，在必定時間內逐漸增長到閾值上限，而不是在一瞬間所有放行。這樣能夠給冷系統一個預熱的時間，避免冷系統被壓垮。

利用 Sentinel 的勻速排隊模式進行「削峯填谷」，把請求突刺均攤到一段時間內，讓系統負載保持在請求處理水位以內，同時儘量地處理更多請求。

利用 Sentinel 的網關流控特性，在網關入口處進行流量防禦，同時能夠針對不一樣用戶、IP 來分別限制 API 的調用頻率。在 Istio+Envoy 架構下快速接入 Sentinel RLS token server，爲 Envoy 集羣提供全局流量控制的能力。

Sentinel 的開源生態

Sentinel 有着豐富的開源生態，覆蓋微服務、API Gateway 與 Service Mesh 幾大核心生態。

Sentinel 開源不久就被歸入 CNCF Landscape 版圖，而且也成爲 Spring Cloud 官方推薦的流控降級組件之一。社區提供 Spring Cloud、Dubbo、gRPC 等經常使用框架的適配，開箱即用；同時支持 Reactive 生態，支持 Reactor、Spring WebFlux 異步響應式架構。Sentinel 也在逐漸覆蓋 API Gateway 和 Service Mesh 場景，在雲原生架構中發揮更大的做用。

Sentinel 多語言演進及將來展望

Sentinel 初期主要面向 Java 微服務，同時也在朝着多語言擴展的方向不斷探索。去年中旬，Sentinel 推出 C++ 原生版本，同時針對 Service Mesh 場景，Sentinel 也推出了 Envoy 集羣流量控制的支持，能夠解決 Service Mesh 架構下多語言限流的問題。

近期，Sentinel 多語言俱樂部又迎來新的一員 —— Sentinel Go 首個原生版本正式發佈，爲 Go 語言的微服務提供流控降級、系統保護等特性的原生支持。開發者只需簡單的幾步便可快速接入 Sentinel，享受到如下能力：

• 精確限制接口級別的 QPS，防止打垮核心接口；
• 削峯填谷，激增的請求排隊等待處理；
• 自適應的系統維度流量保護，結合 load 等系統指標以及服務實時的請求量和響應時間來自動拒絕多餘的流量，儘量地提高吞吐量的同時保證服務不掛；
• 實時的秒級監控能力，經過監控日誌瞭解系統的實時流量狀況。

在接下來的版本中，Sentinel Go 將會陸續推出熔斷降級、熱點參數統計與流控等一系列的穩定性保障能力。同時，社區也會陸續提供與經常使用的框架和雲原生組件的整合模塊。

將來，Sentinel 還會朝着多語言和雲原生的方向持續演進。

Sentinel 目前已支持 Java、Go、C++ 三種語言，將來社區還會支持更多語言。同時咱們會不斷完善 API Gateway 及 Service Mesh 的流控場景，如原生 Istio Service Mesh 整合，方便開發者在各類雲原生場景下快速接入 Sentinel 享受高可用防禦的能力。

社區後面也計劃提供與 Prometheus 等雲原生監控組件的整合，能夠利用 Sentinel 的指標統計數據進行接口級別的監控，同時結合 K8S HPA 彈性機制、自適應流控等，來提供自動化的穩定性保障。

雲原生團隊招人啦

若是你符合如下條件，歡迎投遞簡歷加入咱們！

• 3 年以上分佈式系統相關經驗，熟悉高併發，分佈式通訊，存儲等相關技術；
• 熟練掌握 Golang/Java 語言開發，具有 Python, Shell 等其它一種或多種語言開發經驗；
• 對容器和基礎設施相關領域的技術充滿熱情，有 PaaS 平臺相關經驗，在相關的領域如 Kubernetes、Serverless 平臺、容器技術、應用管理平臺等有豐富的積累和實踐經驗（如產品落地，創新的技術實現，開源的突出貢獻，領先的學術研究成果等）。

簡歷投遞通道：cloudnativehire@list.alibaba-inc.com

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」