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