摘要：?1、當服務量大到一定程度，流量扛不住的時候，該如何處理？ 2、應用之間相互依賴，當應用A出現響應時間過長，影響到應用B的響應，進而產生連鎖反應影響整個依賴鏈上的所有應用，該如何處理？

隨著微服務的流行，服務和服務之間的穩定性變得越來越重要。Sentinel以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。Sentinel 作為阿里巴巴“大中臺、小前臺”架構中的基礎模塊，覆蓋了阿里的所有核心場景，也因此積累了大量的流量歸整場景以及生產實踐。

在近期的Aliware Open Source?深圳站-Apache Dubbo & ApacheRocketMQ開發者沙龍上，阿里巴巴中間件高級技術專家 子矜 宣布將Sentinel 進行開源，并發布了首個社區版本v0.1.0，以下是根據子矜的現場分享所整理，為大家回顧分享中的精彩內容。

分享嘉賓介紹：

林佳梁（子矜），阿里巴巴中間件高級技術專家，參與阿里巴巴多年雙十一大促，對流量的管控、高可用架構有著豐富的經驗，目前負責流量管控軟件Sentinel的開發和商業化。

一、Sentinel 的產生背景

在過去的 10 多年里，阿里巴巴投入了集團大量的精英人力用于提升淘寶、天貓平臺服務的穩定性，正是有了多年來上萬名阿里技術人才的持續創新和技術沉淀，在一系列秒殺大促中，特別是雙11 這樣現象級的電商大促中，才打造出了今天大家所看到的可輕松應對雙11的平臺穩定性體系，包括限流和降級、流量調度、業務開關、容量壓測和評估、全鏈路壓測、業務一致性平臺等，而Sentinel正是在這種背景下產生的限流降級框架，目前已接入集團幾乎所有的核心應用。

二、Sentinal 可以解決什么問題？

? 限流：
當我們設計了一個函數，準備上線，這時候這個函數會消耗一些資源，處理上限是1秒服務3000個QPS，但如果實際情況遇到高于3000的QPS該如何解決呢？Sentinel提供了兩種流量統計方式，一種是統計并發線程數，另外一種則是統計 QPS，當并發線程數超出某個設定的閥值，新的請求會被立即拒絕，當QPS超出某個設定的閥值，系統可以通過直接拒絕、冷啟動、勻速器三種方式來應對，從而起流量控制的作用。

? 熔斷降級：
接觸過Spring Cloud、Service Mesh的同學，都知道熔斷降級的概念。服務之間會有相互依賴關系，例如服務A做到了1秒上萬個QPS，但這時候服務B并無法滿足1秒上萬個QPS，那么如何保證服務A在高頻調用服務B時，服務B仍能正常工作呢？一種比較常見的情況是，服務A調用服務B時，服務B因無法滿足高頻調用出現響應時間過長的情況，導致服務A也出現響應過長的情況，進而產生連鎖反應影響整個依賴鏈上的所有應用，這時候就需要熔斷和降級的方法。Sentinel通過并發線程數進行限制和響應時間對資源進行降級兩種手段來對服務進行熔斷或降級。

? 塑形
通常我們遇到的流量具有隨機性、不規則、不受控的特點，但系統的處理能力往往是有限的，我們需要根據系統的處理能力對流量進行塑形，即規則化，從而根據我們的需要來處理流量。Sentinel通過資源的調用關系、運行指標、控制的效果三個維度來對流量進行控制，開發者可以自行靈活組合，從而達到理想的效果。

? 系統負載保護
平時系統運行都沒問題，但遇到大促的時候，發現機器的load非常高，這時候對系統的負載保護就顯得非常重要，以防止雪崩。Sentinel 提供了對應的保護機制，讓系統的入口流量和系統的負載達到一個平衡，保證系統在能力范圍之內處理最多的請求。需要注意的是，Sentinel在系統負載保護方面的判斷機制是根據系統能夠處理的請求，和允許進來的請求，來做平衡，而不是根據一個間接的指標（系統load）來做限流。因為我們最終追求的目標是在系統不被拖垮的情況下，提高系統的吞吐率，而不是load一定要到低于某個閥值。

三、一個好的流量管理框架應該具備哪些特點？

? 輕巧
輕巧指的是對性能影響小和對應用零入侵。

限流框架是寄宿在應用上的，這時候要求限流框架不能對系統資源有過多的消耗。就像汽車上的安全氣囊如果會耗油、導致汽車跑得慢，這就不是一個好氣囊，Sentinel的接入對系統資源的消耗極少。

除了對性能的影響要優化到最低以外，還有一個特征，就是需要保證他對應用的零入侵。零入侵是讓開發者幾乎意識不到這個框架的存在。如果讓開發者一邊開發，一邊還要想著限流降級，這就非常累了。優秀的限流就像是汽車上的安全氣囊，平時系統工作正常的時候我們感受不到他的存在，只有當系統出現無法應對當前流量的時候，才會出現，這就是對應用零入侵的體現，開發者無需關心如何接入流量框架，便可調用服務。

對此，Sentinel通過對主流框架，例如Dubbo、Spring Cloud, grpc等，進行默認適配，只要接入我們的適配器，默認的資源就都有了；如果不是用主流框架，也沒有關系，只需要很簡單，差不多3步，就可以接入，之后還會提供annotation，讓用戶更簡單的用起來。

? 專業
不同的場景下有不同的限流需求。在什么時候減流量，流量減多了影響用戶體驗、流量減少了影響系統穩定性，陡峭高峰如何限流、銷峰填谷如何限流，這里就涉及到限流的算法。不同于 hystrix 只提供一兩個維度的限流方式，Sentinel提供了一個靈活的框架，從不同的維度出發，開發者可以根據自身的場景去制定自己的限流策略。

? 實時監控
流量具有很強的實時性，之所以需要限流，是因為我們無法對流量的到來作出精確的預判，不然的話我們完全可以通過彈性的計算資源來處理，所以這時候限流框架的實時監控功能就非常重要了。通過Sentinel的實時監控功能，運維人員可以根據實際流量情況，采取不同的措施，限流、降級、塑形、系統保護，所以在我們第一版開源版本中，我們加入了Sentinel的控制臺，具備實時監控功能。

四、Sentinal 的最佳實踐

? Dubbo service

我們已經把 Sentinel 的適配器捐給了Dubbo，社區傳送門

如果開發者接入了Dubbo Sentinel，就能立即實現實時秒級監控的功能。這個監控提供單機鏈路維度和單機平鋪維度，還提供匯總維度的監控。非常方便。

然后我們再來看Sentinel還帶來了什么好處。當我們瀏覽一件商品時，背后可能應對著上百個服務，例如商品屬性、商品庫存、個人信息、評價信息、店鋪信息、商品優惠、訂單信息、交易信息、推薦信息等等，這類場景，我們可以由兩個維度來看Sentinel在Dubbo service 中的實踐，一個是從服務提供方service provider如何限流，例如在百個服務中要保證交易服務可以正常處理，那就可以通過容量或者并發量來限流。一個是從服務調用方service caller如何限流，則可以通過熔斷降級來限流。

? RocketMQ客戶端 & RocketMQ服務端

圖中紅色曲線是表示實際的消息流量，紅色區域是超出我們處理能力的消息流量，這時候借助Sentinel對流量實施削峰填谷，把紅色流量放到系統不太繁忙的時候再來處理，這樣既不會丟失流量的請求，也不會對用戶的購物體驗產生影響。這類處理在電商的訂單處理等環節很常見。在RocketMQ的服務端，消息的分發者則可以通過Sentinel勻速的對外發送請求。

這個最佳實踐，我們也捐給了Apache RocketMQ，目前正在合并，大家很快就可以看到。

? Nacos

Sentinel和Nacos類似，是以Dubbo大生態中的核心組件的身份來對外開源的，目的是幫助開發者獲得更完整的分布式服務解決方案。例如當我們限流的流量發生變化的時候，我們需要迅速推規則的時候，Sentinel可以和Nacos相互整合，起到快速操作、快速配送的效果。

Sentinel的理念是無縫對接Dubbo大生態，和Dubbo、Nacos等阿里中間件開源產品緊密結合，支持一鍵使用，并且全面擁抱開源生態，例如會對grpc ,Rest Service主流框架進行積極適配并開放出來，同時提供一系列API給到開發者，用于定制自己的需求。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。