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 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”