探祕手淘高可用平臺（三）——熱修復和開發流程
本系列文章根據手機淘寶客戶端基礎架構高階開發工程師非臺在安卓綠色聯盟開發者大會上的分享，共分三篇，介紹手淘技術團隊效能和穩定性系統化提升方案EMAS-MOTU的設計原理以及實現思路。
本文重點介紹手淘高可用平臺的熱修復方案和如何全開發流程保障效能及穩定性。
熱修復方案
熱修復有三個場景，手淘EMAS-MOTU平臺可以根據場景選擇相應的方案進行熱修復。
第一個場景是由於程式碼本身不夠健壯，從而導致APP發生崩潰。針對這個問題，手淘開發了Dexpatch框架，可以實時快速對線上問題進行修復。
第二個場景是產品功能不符合專案預期。比如，需要舉辦一個活動，但這部分活動的功能沒有正式上線，針對這個問題，手淘開發了Atlas動態容器框架，可以支援業務快速上線新功能。
第三個場景是啟動時網路異常導致的崩潰。網路未初始化會導致Dexpatch和Atlas動態容器無法發揮作用，針對這個問題，手淘開發了安全模式，在啟動異常時可以及時修復。
開發流程
開發流程一般分成開發測試、整合、灰度和線上四個階段，手淘高可用平臺在每個階段是如何保障手淘平臺的效能和穩定性的呢？
在開發測試階段，手淘通過程式碼靜態掃描以及測試用例的覆蓋來提升高可用性。
在整合階段，手淘會對歷史問題進行迴歸。通過跟蹤，判斷歷史問題是否全部修復，設定卡口，直至解決所有歷史問題，達到持續整合的目的。
在智慧灰度階段，手淘開發了智慧灰度機器人，它會根據上一次灰度的體量和效能穩定性資料來制定灰度策略。如果穩定性和效能資料報表符合預期，智慧灰度機器人會逐漸放大灰度的使用者量，直到正式釋出為止。在灰度過程中，它還會監控應用各個模組是否存在異常並及時報警，以便快速定位穩定性效能不能達標的具體原因。如果灰度過程中一切正常，則可以通過這種方式直接發版。
在線上跟蹤階段，手淘資料平臺會實時展示版本正式上線後的資料，可以根據資料決定後續的操作。如有異常，資料平臺也會對開發同學進行警告，以便快速跟進，並決策是否要對它進行熱修復。
手淘高可用平臺系列文章已全部分享完成，開發者覺得有哪些值得借鑑和改進的地方呢？歡迎留言說出您的看法~