Hello已經發展成為壹個綜合性的移動出行平臺，包括兩輪出行(Hellobike、Hello助力車、Hello電動車、小哈換電)和四輪出行(Hello搭便車、全網叫車、Hello打車)，並探索了酒店、店鋪等多個本地生活生態。
隨著公司業務的不斷發展，流量也越來越大。我們發現生產中的壹些重大事故往往是被突發的流量沖刷過去的，因此對流量的控制和保護，保證系統的高可用性就顯得尤為重要。
在本文中，我們將分享Hello在消息流量和微服務調用的治理上踩過的經驗。
《RocketMQ實戰與進階》專欄作者之壹梁勇(老梁)，參與了《RocketMQ技術內幕》稿件的審稿工作。ArchSummit全球建築師會議和QCon案例研究學會講師。
目前主要是在後端中間件方向。在微信官方賬號中，冠農老梁已經發表了100多篇關於源代碼戰鬥的文章，涵蓋了RocketMQ系列、Kafka系列、GRPC系列、Nacosl系列、Sentinel系列、Java NIO系列。目前在Hellobike工作，擔任高級技術專家。
開始之前先說治理。以下是老梁的個人理解:
公司之前用過RabbitMQ，以下是使用RabbitMQ時的痛點，很多都是RabbitMQ集群限流造成的。
有這樣壹個錯誤，多個企業使用壹個數據庫。在壹個晚高峰時段，流量劇增，數據庫被掛起。
思考:新聞和服務都需要完善的治理措施。
哪些是我們的關鍵指標，哪些是我們的次要指標，這是新聞監管的首要問題。
設計目標
它旨在屏蔽底層中間件(RocketMQ/Kafka)的復雜性，通過唯壹標識動態路由消息。同時構建集資源管理、檢索、監控、告警、檢查、容災、可視化運維於壹體的消息管理平臺，保障消息中間件的平穩健康運行。
是把復雜的問題簡單化的能力。
極簡統壹API
提供統壹的SDK封裝了兩種消息中間件(Kafka/RocketMQ)。
主題消費群體的自動創建不適合生產環境，會導致失控，不利於全生命周期管理和集群穩定。申請過程需要控制，但要盡量簡單。比如申請所有環境壹次性生效，生成相關報警規則等。
監控客戶端的使用是否規範，並找到適當的措施進行控制。
場景1集群的瞬時流量和流量控制
假設現在集群中有65，438+00000個Tps，瞬間變成20，000個甚至更多，這種流量的過度陡峭增長極有可能導致集群流量控制。對於這種場景，需要監控客戶端的發送速度，在達到速度和陡升的閾值後，讓發送更加平緩。
場景2:重大新聞和集群抖動
當客戶端發送大消息時，比如發送幾百KB甚至幾兆的消息，可能會造成IO時間長，集群抖動。對於這種場景管理，需要監控發送消息的大小。我們采用通過事後檢查識別大消息的服務，推廣使用同學壓縮或重構。消息控制在10KB以內。
場景3低客戶端版本
隨著功能的叠代，SDK的版本也會升級，變化除了功能可能會引入風險。使用低配版本的時候，壹個是不能支持功能，壹個是可能存在安全隱患。為了了解SDK的使用情況，可以上報SDK版本，通過巡視檢查來推廣同學的使用。
場景4消費流提取和回收
消費流量移除和恢復通常有以下使用場景。第壹種是應用發布時需要先移除流量，第二種是問題定位時需要先移除流量再檢查。為了支持這種情況，有必要在客戶端監控刪除/恢復事件，並暫停和恢復消費。
場景5傳輸/消耗耗時檢測
發送/消費壹條消息需要多長時間？通過對耗時情況的監控，巡視，找出性能低下的應用，有針對性的推進改造，達到提升性能的目的。
場景6提高了調查和定位的效率。
在對問題進行故障排除時，通常需要檢索與消息生命周期相關的信息，例如發送了什麽消息、它們存在於何處以及何時被使用。這部分可以通過msgId連接消息中的生命周期。此外，通過在消息頭中嵌入rpcId/traceId相似的鏈接標識，消息被串在壹個請求中。
所需的監控信息
常見控制措施
監控主題消費群體的資源使用情況。
場景1:消費積壓對業務的影響
有些業務場景對消費積累比較敏感，有些業務對積壓不敏感，只要趕上來以後消費就行。比如解鎖自行車就是幾秒鐘的事情，信息匯總相關的批量處理場景對積壓不敏感。通過采集消費積壓指標，對符合閾值的應用進行實時報警通知負責應用的同學，讓他們實時掌握消費情況。
場景2消費/發送速度的影響
發送/消耗速度為零報警？在某些情況下，速度不可能降到零。如果降到零，說明業務不正常。通過收集速度指標，可以向滿足閾值的應用程序發出實時警報。
場景3:消費者節點斷開連接。
當消費者節點斷開時，需要通知負責應用的同學。這種節點信息需要收集，當它斷開時，可以實時觸發報警通知。
場景4不平衡的傳輸/消耗
不平衡的傳輸/消耗經常影響其性能。記得在壹次咨詢的時候，有同學把發送消息的key設置為壹個常量，默認按照key對分區進行哈希，所有的消息都進入壹個分區。這個業績無論如何也上不來了。此外，還需要檢測各個分區的消耗積壓，在出現過度不平衡時觸發實時報警通知。
所需的監控信息
常見控制措施
衡量集群健康狀況的核心指標是什麽？
場景1集群運行狀況檢測
集群健康測試回答了壹個問題:這個集群好嗎？這個問題是通過檢測集群節點數量、集群中每個節點的心跳、集群寫入的Tps水位和集群消耗的Tps水位來解決的。
場景2集群的穩定性
集群流量控制往往反映了集群性能的不足，集群抖動也會導致客戶端發送超時。通過收集集群中各個節點的心跳時間消耗和集群寫的Tps水位變化率，可以掌握集群是否穩定。
場景3集群的高可用性
高可用主要是針對某個可用區域在極端場景下的不可用，或者集群上某些話題和消費群體的異常，需要采取壹些針對性的措施。比如MQ可以通過跨可用區域同城主從交叉部署、主題和消費群動態遷移到容災集群、多活動等方式解決。
所需的監控信息
常見控制措施
如果這些關鍵指標中哪壹個最重要？我會選擇集群中每個節點的心跳檢測，也就是響應時間(RT)。我們來看看影響RT的可能原因。
我們總會遇到壹個坑，遇到了就去填。
**
RocketMQ從節點和主節點頻繁出現高CPU，這是明顯的毛刺。很多時候，從節點直接掛機。
只有系統日誌有錯誤提示
2020-03-16t 17:56:07.505715+08:00 vecs 0 xxxx內核:[]？_ _ alloc _ pages _ node mask+0x7e 1/0x 9602020-03-16t 17:56:07.505717:08:00 vecs 0 xxxx內核:java:頁面分配失敗。order:0，mode:0x 202020-03-16t 17:56:07.505719:08:00 vecs 0 xxxx內核:Pid: 12845，comm: java未被感染2 . 6 . 32-754.17.1.el6 . x86 _ 64 # 10_ _ alloc _ pages _ node mask+0x7e 1/0x 9602020-03-16t 17:56:07.505726+08:00 vecs 0 xxxx內核:[]？dev _ queue _ xmit+0xd 0/0x 3602020-03-16t 17:56:07.505729+08:00 vecs 0 xxxx內核:[]？IP _ finish _ output+0x 192/0x 3802020-03-16t 17:56:07.505732+08:00 vecs 0 xxxx內核:[]？
各種調試系統參數只能減緩但不能根除，毛刺依然超過50%。
將集群中的所有系統從centos 6升級到centos 7，內核版本也從2.6升級到3.10，CPU小故障消失。
RocketMQ社區版默認版本支持18個延遲等級，每個等級在設定的時間被消費者精準消耗。為此我們還專門測試了消費間隔是否準確，測試結果顯示非常準確。但是，這樣壹個準確的特征是有問題的。在商科同學的舉報專線上收到壹個集群的延遲消息，感覺很奇怪。
將“delayOffset.json”和“消費隊列/Schedule _ Topic _ XXXX”移動到其他目錄相當於刪除；逐個重新啟動代理節點。重啟後，經過驗證，延時消息功能正常發送和消費。
我們的核心服務是什麽，非核心服務是什麽？這是服務治理的首要問題。
服務可以應對突然激增的流量，尤其是保證核心服務的順暢運行。
根據用戶和業務影響兩個緯度，將應用分為四個等級。
S1:核心產品，其故障會導致外部用戶無法使用或造成較大資金損失，如主營業務的核心環節，如自行車、助力車開關鎖，搭車的發單、接單等核心環節，以及核心環節強烈依賴的應用。
S2:不直接影響交易，但是關系到前臺業務重要配置或者業務後臺處理功能的管理維護。
S3:服務失敗對用戶或者核心產品的邏輯影響不大，對主營業務沒有影響，或者少量新業務；內部用戶重要工具不直接影響業務，相關管理功能對前臺業務影響不大。
S4:對於內部用戶來說，系統並不直接影響業務，或者需要後期推下線。
S1業務是公司的核心業務，是重點保障對象，需要保證不被非核心業務流量意外沖擊。
**
**