五年磨一劍：滴滴順風車服務端之穩定性規範

桔妹導讀：本文給出其中穩定性相關的規範，這些規範都是順風車成立五年來，對大量真實線上故障覆盤、總結獲得的，但願對你們服務的穩定性提高有所幫助。

服務端做爲順風車技術部內最大的工程團隊，隨着人員的擴張和迭代，流程規範在其中扮演着原來越重要的角色。一方面規範化能夠提升咱們的交付質量、交付效率，另外一方面，咱們也但願在一次次的實戰中不斷的總結，探索出適用於咱們團隊的最佳實踐。

基於此，咱們制定並推廣了一套適用於服務端開發的可執行、最小限制的工程規範，包括研發流程、穩定性、性能成本等多個方面。

本文給出其中穩定性相關的規範，這些規範都是順風車成立五年來，對大量真實線上故障覆盤、總結獲得的，但願對你們服務的穩定性提高有所幫助。

1. 名詞解釋

下文的描述中，會用到不少的技術名詞，爲更容易的理解，在這裏對這些名詞作下簡要說明：

• 服務分級： 根據業務須要，通常的咱們須要針對最小系統劃分爲一級服務，一旦出問題須要第一優先級跟進。咱們將影響業務核心指標（好比發單量、成單量等）的服務定義爲一級服務，其餘爲二級服務。

• 預覽集羣： 和線上生產環境的部署徹底一致的一套環境，只是無線上流量，能夠內部訪問，集羣內流量閉環。

• 小流量集羣： 和線上生產環境的部署徹底一致的一套環境，經過流量控制，只有個別城市的流量會落到此集羣，集羣內流量閉環。

• 灰度發佈： 將發佈過程分爲預覽集羣、灰度城市集羣、10%流量、50%流量、100%流量的發佈機制，確保安全上線過程。

• 全鏈路壓測： 在不影響線上服務的前提下，對生產環境進行壓力測試的解決方案。用以摸清生產環境的容量、瓶頸點等。

• 機房多活： 經過多機房部署，當一個機房出現故障時，能夠快速將流量切到其餘機房，以減小損失。涉及流量路由、流量閉環、數據同步、數據一致性、災難應對等諸多環節的整套解決方案。

2. 穩定性規範

穩定性設計

• 【強制】調用方必須設置超時時間，且調用鏈路超時從上往下遞減，建議超時時間設置以下：

• 【強制】核心流程新增依賴默認爲弱依賴，如需新加強依賴，須要通過評審決議；
• 【強制】下游服務如提供服務發現，全部服務必須經過服務發現訪問該服務，方便服務發現控制下游節點和超時時間；
• 【強制】全部內部服務必須接入服務發現，外部服務儘可能推進接入服務發現；
• 【建議】建議框架支持依賴服務手動一鍵熔斷；
• 【建議】服務設計優先考慮無狀態設計；
• 【建議】寫接口建議考慮防重入；
• 【建議】系統設計原則簡單可靠，優先使用成熟技術；
• 【建議】核心服務強制，其餘建議，接口建議設置合理的限流配置。

部署和運維

1. 【強制】嚴禁在臨時腳本中未經過接口或封裝方法，直接操做線上數據，若有須要，必須通過QA測試；
2. 【強制】服務上線必須經過上線平臺，並接入質量平臺（功能包括自動化case、核心曲線圖及其餘上線checklist），強制停留觀察’
3. 【強制】一級服務須要包含預覽集羣、小流量集羣（除部分特殊服務）而且雙機房部署；
4. 【建議】非一級線上服務建議包含預覽集羣；
5. 【建議】新服務上線建議進行容量規劃，建議經過接口壓測或全流量壓測驗證模塊容量。

監控告警

1. 【強制】線上服務機器必須有基礎監控報警，包含CPU、IO、內存、磁盤、coredump、端口；
2. 【強制】線上服務必須有基礎的服務監控，包括接口qps、fatal數量、耗時；
3. 【建議】核心業務指標(發單量、搶單量、支付量等)必須有監控和報警；
4. 【建議】須要有服務總體大盤，可以涵蓋該方向核心模塊監控，方便快速定位服務問題。

變動管理

1. 【強制】任何一級服務變動，均須要走灰度發佈機制；
2. 【強制】任何一級服務變動，包括服務變動、配置變動，均須要有相應的回滾預案，保證變動異常時能夠快速回退；
3. 【建議】儘可能避免代碼搭車上線；
4. 【建議】服務回滾時建議同時回滾相應的代碼和配置，保證主線代碼的正確性；
5. 【建議】配置變動，特別是複雜的配置變動時，建議增長相應的配置校驗機制。

預案管理

1. 【強制】必須有多活切流預案，且須要保障有效性，必須按期組織演練，建議1月1次；
2. 【強制】全鏈路壓測通道須要保證有效性，按期組織壓測；
3. 【強制】一鍵限流預案須要保障有效性，按期review和演練；
4. 【強制】強依賴降級預案須要保障有效性，按期演練。

故障處理原則

1. 【強制】線上出現故障時，必須第一優先級進行處理；
2. 【強制】線上出現故障時，若是有變動，第一時間回滾；
3. 【強制】線上出現故障，必須組織覆盤；
4. 【強制】須要有覆盤規範，覆盤按照規範執行。

3. 穩定性反模式

本章節主要是基於大量的線上故障case，以具體實例驅動，加上研發全流程中各個環節容易犯的一些穩定性問題，提取一些反模式出來，供你們參考，儘可能避免後續的工做中犯一樣的問題，提升線上服務的穩定性。

3.1.容災和容錯設計

**反模式3.1.1 **
過分的節點熔斷策略

【實例】
爲了提升請求成功率，在下游故障時對下游節點採起熔斷措施，好比1分鐘內連續出現5次訪問出錯，則將該節點熔斷，再也不調用（過一段時間後再恢復），某天網絡抖動，下游服務4個實例中的3個均進入熔斷模式，致使訪問下游的全部流量均落到剩餘的這個實例上，壓力過大，將該實例壓垮。下游服務雪崩，整個系統不可用。

【解決方案】
熔斷模式下，還須要有熔斷保護措施，避免過分熔斷帶來的穩定性問題。

反模式3.1.2
固定的重試序列

【實例】
每次重試序列都爲「下一臺」。

【後果】
一個是雪崩：假設某一類 query 的重試序列爲A B,當 A 出現故障時,B 要承受兩倍的壓力,若是 B 扛不住,那麼 B 的下一個也會被壓垮；一個是上線損失流量：假設重試次數是2，上線時若是 A 和 B 同時重啓,那麼重試序列爲 A B的 query 必然無結果。

【解決方案】
評估新的重試算法，好比隨機重試。不過相對於固定的重試序列，隨機重試序列也可能給系統帶來風險，例如可能會下降下游模塊的cache命中率，下降系統性能。

反模式3.1.3
不合理的超時設置

【實例】
上游服務超時時間設置不合理，下游出現問題時，直接把上游服務拖垮。

【解決方案】
應該根據鏈路的99分位耗時來設置超時時間，同時按期對鏈路的通訊相關配置進行review。

反模式3.1.4
未考慮同一請求中屢次調用下游的影響

【實例】
服務調用下游時超時時間設置沒有問題，但同一請求中會串行屢次調用某個下游服務，下游服務故障時，也會把上游服務直接拖垮。

【解決方案】
除了考慮對下游服務的單次超時，還須要考慮對下游服務的整體超時。

反模式3.1.5
不合理的重試邏輯

【實例】
整條鏈路多個地方有重試，下游服務故障時，重試被放大，致使服務雪崩。

【解決方案】
評估重試機制，梳理請求處理的整個鏈路，保證重試收斂在一個地方。

反模式3.1.6
沒有考慮到業務毛刺的影響

【實例】
某業務形態有個特色，在半點和整點時刻有請求尖刺，某次受節假日影響，訪問下游的流量瞬間暴增，致使下游服務雪崩。

【解決方案】
對業務尖刺進行平衡處理，減小對下游服務的峯值流量衝擊。

反模式3.1.7
沒有對異常輸入進行容錯處理

【實例】
業務沒有對異常輸入進行容錯處理，仍然按照正常邏輯處理，致使數據混亂。

【解決方案】
業務特別是業務入口，必須對不合理的異常輸入進行容錯處理，保證整個系統的健壯性。

反模式3.1.8
接口不支持冪等性設計

【實例】
接口不支持冪等性，網絡故障時引起大量的重試，致使核心數據大量出錯。

【解決方案】
接口設計的時候就須要考慮冪等性的需求。

反模式3.1.9
沒有對非核心流程弱依賴化

【實例】
沒有對流程進行弱依賴化，致使系統總體上比較脆弱，每一個依賴單元故障都會致使整個業務癱瘓。

【解決方案】
按期對系統的流程進行梳理，最小系統化，非必須流程儘可能弱依賴化。

反模式3.1.10
沒有考慮ID溢出的影響

【實例】
某ID使用int32，超出後ID溢出，導出服務異常。

【解決方案】
增長資源相關的ID字段時要考慮ID的範圍，是否有溢出風險
按期對資源相關的ID字段進行review，提早預防，最大限度防止故障的發生

3.2.部署和運維

反模式3.2.1
部署時未考慮網段因素

【實例】
服務部署時未考慮網段因素，服務的多個實例都部署到一個交換機下，致使交換機故障時，服務的多個實例不可用，服務所在集羣雪崩

【解決方案】
服務部署時儘可能多考慮地理因素，同一服務的多個實例儘量部署到不一樣的機房、交換機和網段下

反模式3.2.2
服務混部時未作好資源隔離

【實例】
多個服務混部，其中一個CPU佔用太高，致使其餘服務異常

【解決方案】
多個服務混部的狀況下，必定要作好資源隔離，避免因一個服務佔用資源太高，致使同一臺機器上的其餘服務不可用

反模式3.2.3
沒有作到對核心業務和隔離和保護

【實例】
某非核心流程因爲bug向mq寫入大量消息，致使整個mq集羣不可用，整個業務故障

【解決方案】
核心鏈路和非核心鏈路的mq隔離，分開部署，非核心流程的變化不會影響主流程，保證核心流程和業務的穩定性

3.3.容量管理

反模式3.3.1
容量規劃時未考慮故障因素

【實例】
線上某服務qps不大，只部署了2個實例，一個實例高峯期出問題時，流量都落到另一個實例上面，把服務壓垮

【解決方案】
容量估計時須要考慮容災因素，預留必定的buffer
若是以爲部署實例多，會浪費機器，能夠考慮使用彈性雲，比較靈活

反模式3.3.2
上線新功能未合理進行容量規劃

【實例】
某服務，下游依賴衆多，在進行容量規劃時，重點都集中在某一依賴服務，未對全局全部依賴方進行全面評估，當其中某一依賴服務出現問題，致使總體服務不可用

【解決方案】
上線新功能時，須要對全部下游依賴服務進行容量規劃，防止出現瓶頸點

3.4.變動管理

反模式3.4.1
代碼搭車上線

【實例】
因爲缺少有效的代碼修改管理機制，某產品線因爲代碼搭車上線，出現過屢次線上故障
而且因爲變動時涉及的修改比較多，致使問題定位和追查時很是困難

【解決方案】
創建嚴格的代碼管理機制，嚴禁代碼搭車上線，保證任什麼時候刻主幹沒有未上線驗證的代碼

反模式3.4.2
服務回滾時遺漏回滾代碼

【實例】
上線出現問題，服務回滾後沒有第一時間把代碼回滾掉。次日其餘同窗上線時將未回滾的問題代碼再次帶上線，上線時致使連續兩天出現系統故障

【解決方案】
服務回滾的時候同時第一時間回滾代碼

反模式3.4.3
太高的併發部署設置

【實例】
部署配置的併發個數過高，致使同一時刻只有少數機器可用，引起集羣雪崩

【解決方案】
服務部署配置的併發個數，要保證剩餘機器可以承載業務所有流量

反模式3.4.4
服務啓動或回滾時間過長

【實例】
服務上線異常，回滾時單個服務回滾時間太長，致使未能短期內快速止損

【解決方案】
按期檢查服務的啓動和回滾時間，保證出現故障時能夠第一時間完成回滾操做

反模式3.4.5
配置文件缺乏有效的校驗機制

【實例】
配置文件由模型產出，數據配送系統實時配送到線上服務，模型產生的配置文件有問題，引起線上故障

【解決方案】
針對配置文件，尤爲是模型產出的配置文件，創建嚴格的檢查和校驗機制

反模式3.4.6
配置變動沒有灰度

【實例】
配置相關修改，穩定性意識上重視度不夠，沒有進行足夠的觀察和灰度，致使故障

【解決方案】
全部變動，包括服務變動、配置變動、數據變動以及環境變動，都須要進行嚴格的觀察和灰度，保證變動的質量

反模式3.4.7
變動沒有通過嚴格的測試

【實例】
變動較小，感受沒有必要進行測試，結果出現低級錯誤，致使故障

【解決方案】
任何變動都要測試、double check，修改一行代碼，也可能致使線上的穩定性故障

反模式3.4.8
變動時沒有嚴格按照變動規範執行

【實例】
上線時，小流量和A機房均嚴格按照規範檢查，服務和各類曲線沒有問題，上線B機房時沒有進行檢查。結果B機房出現故障。
經排查是由於B機房配置缺失

【解決方案】
任何變動都要嚴格按照變動規範嚴格檢查，上線的每一個階段都要檢查服務的各類曲線和指標

反模式3.4.9
離線直接經過sql更新db數據

【實例】
直接經過sql進行離線更新數據庫，沒有作好限流保護，致使db壓力大，線上服務訪問時出現大量超時

【解決方案】
除非特殊狀況，嚴禁直接經過sql操做db數據，修改需經過接口修改，方便經過曲線觀察，也可下降直接改庫的風險；

批量修改db數據須要通報dba，通過review，確認沒有問題時才能夠進行操做；

批量增改、增長數據務必作好限流措施。

3.5.監控報警

** 反模式3.5.1
缺乏基礎監控**

【實例】
缺乏基礎監控，致使出現故障，未能第一時間感知。

【解決方案】
梳理基礎監控checklist，按期對服務的基礎監控進行review和演練。

反模式3.5.2
缺乏業務監控

【實例】
缺乏業務監控，致使出現故障，未能第一時間感知。

【解決方案】
對核心流程和核心業務指標，都須要添加業務監控。

反模式3.5.3
告警閾值設置有問題

【實例】
因爲業務bug致使線上大量告警，先臨時將告警閾值從20調整到200，問題修復上線後忘了改回來，就一直維持這個閾值設置，致使後續業務出問題的時候，未能第一時間報出來。

【解決方案】
儘可能使用短暫屏蔽報警，而不是調高閾值。

反模式3.5.4
監控告警當前已失效

【實例】
業務迭代過快，致使監控告警信息和業務已經再也不匹配。

【解決方案】
按期對告警進行演練，保證其有效性。

重大業務迭代，須要將監控告警列入checklist。

3.6.預案管理

反模式3.6.1
上游流量異常時沒有相應的防雪崩預案

【實例】
服務上游流量突增，致使服務瞬間被壓垮，系統雪崩

【解決方案】
服務必須提早作好防雪崩預案，否則很容易致使整個系統級別的故障

反模式3.6.2
服務沒有防刷和防攻擊預案

【實例】
線上問題定位時，發現某個線上服務存在大量刷接口的現象，給線上系統的穩定性帶來很大隱患，同時形成很大的資源和成本浪費。

【解決方案】
線上服務，特別是和端交互比較多的服務，設計時就須要考慮好防刷和防攻擊策略，提早作好預案

反模式3.6.3
下游故障時沒有相應的處理預案

【實例】
下游服務故障，上游服務沒有相應的處理預案，致使被下游拖垮，由於這種狀況致使的大型故障很是多

【解決方案】
下游故障，尤爲是下游弱依賴服務故障，須要有相應的處理預案

反模式3.6.4
故障時預案已失效

【實例】
因爲業務迭代比較快，當前對某下游已經從弱依賴變成強依賴，下游故障時，執行降級預案但業務故障並無恢復

【解決方案】
按期對預案進行演練，保證預案有效性

3.7.穩定性原則和意識

** 反模式3.7.1
對穩定性缺少敬畏之心**

【實例】
覺得服務出故障是正常的，對穩定性不覺得然

【解決方案】
技術同窗須要對代碼、線上穩定性保持敬畏之心，不能有任何僥倖心理
一行代碼的bug，就可能致使整個業務癱瘓掉

反模式3.7.2
故障時沒有第一時間止損

【實例】
服務出現故障時，相關同窗第一時間在定位故障緣由，沒有第一時間進行止損

【解決方案】
出現故障必須第一優先級處理，第一時間止損

反模式3.7.3
使用未充分驗證過的技術和方案

【實例】
某服務使用了mq的廣播特性，該特性在公司尚未在線上被使用過，上線後觸發mq廣播消費代碼中的一個bug，致使mq集羣不可用的故障

【解決方案】
儘可能避免使用未充分驗證過的技術和方案
若是由於某些緣由必須使用，必定要有相應的兜底措施，同時控制好接入的節奏
在非關鍵服務上驗證充分後，才能應用到核心鏈路上

反模式3.7.4
使用新技術時未控制好接入節奏

【實例】
某服務使用了mq的廣播特性，在非核心服務驗證時間不夠的狀況下，將此特性引入核心服務，核心服務的流量比較大，觸發mq廣播消費代碼中的一個bug，致使mq集羣不可用的故障

【解決方案】
引入新技術時必定要控制好接入的節奏
在非關鍵服務上驗證充分後，才能應用到核心鏈路上

反模式3.7.5
穩定性改進方案未及時落實

【實例】
某服務出現故障，覆盤時制定了相應的改進措施，可是未及時有效落實；後該問題再次爆發，又一次服務故障。

【解決方案】
創建改進措施落實的有效跟蹤機制，保證改進措施的有效落實。

---

團隊簡介

順風車服務端團隊是由一羣團結互助、樂觀正直、追求極致的小夥伴匯聚而成，致力於構建一流的安全、交易、營銷服務端技術體系，助力滴滴順風車實現「分享出行讓生活更美好」的使命 。

若是你想了解滴滴順風車優質技術分享，歡迎關注「滴滴順風車技術」公衆號，閱讀原文與更多技術乾貨。

---

歡迎關注滴滴技術公衆號！

本文由博客羣發一文多發等運營工具平臺 OpenWrite 發佈