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

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

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

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

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

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 發佈