對于移動技術而言，2017 年是繼往開來之年。一方面是移動技術領域進入深水區(qū)，另一方面移動技術邊界和內涵被不斷重塑。

[[213797]]

阿里巴巴希望進一步推動移動應用研發(fā)事實標準落地，從而賦能整個行業(yè)開發(fā)者。在 2017 年杭州云棲大會上，螞蟻金服高級技術專家竹光為大家分享了螞蟻金服移動端在高可用技術方面的具體實踐，以下內容根據(jù)演講視頻以及 PPT 整理而成。

本次分享的內容主要分為以下四個方面：

• 億級 APP 在可用性方面的挑戰(zhàn)
• APP 線上運維的發(fā)展和演進
• 移動端高可用的定義、目標、核心打法
• 支付寶在移動端高可用技術實踐

億級 APP 在可用性方面的挑戰(zhàn)

可用性的概念

簡單而言，可用性就是當用戶想要使用 APP 做一個事情，這件事情做成了就是可用，沒有做成就不可用。

為什么沒有做成？可能的原因有很多，比如有可能使用 APP 的時候閃退了，或者使用支付寶付款的時候，由于后臺某個環(huán)節(jié)出現(xiàn)錯誤，導致了這筆支付失敗了等，這些都可能造成 APP 的不可用。

如果各種各樣不可用的情況都沒有出現(xiàn)，那么對于客戶而言就是可用的。雖然每個開發(fā)人員都希望自己開發(fā)的 APP 是 100% 可用的，但是實際上這一點是不可能的。所以開發(fā)人員真正需要做的事情就是讓 APP 發(fā)生不可用的情況越來越少。

億級 APP 的可用性挑戰(zhàn)

目前，APP 開發(fā)技術已經(jīng)比較成熟了，所以很多開發(fā)人員會認為自己的 APP 可用性應該問題不是很大，因為 APP 都經(jīng)歷了相關的測試流程、灰度驗證等保障措施。

但是現(xiàn)在情況已經(jīng)發(fā)生變化了，與以前相比，APP 的用戶量大了很多，很多的 APP 都達到了億級用戶，所以一點點可用性問題都可能會影響大量的用戶。

比如 APP 的閃退率上漲了千分之一，雖然這一比例并不是很大，但是對于一億用戶而言，乘上千分之一就是 10 萬人。

大家可以想象一下，如果某一天大家在使用支付寶在超市付款的時候，其中的 10 萬人出現(xiàn)閃退的情況，這個影響是絕對不可以接受的。

現(xiàn)在開發(fā)移動端 APP 講究動態(tài)化，業(yè)務要求實時動態(tài)地實現(xiàn)線上變更，可以說今天的支付寶和昨天的支付寶相比就已經(jīng)產生很大區(qū)別了。

每一次線上的變更其實都會增加線上可用性的風險，而且一天中可能會發(fā)生很多次變更，在這種情況下風險也會變得很大。尤其對于作為保障 APP 可用性的一線人員而言，壓力也會特別大。

正是因為面臨這么多的問題和挑戰(zhàn)，才需要通過移動端的高可用技術體系解決這個問題，保證線上客戶端高可用性。

APP 線上運維的發(fā)展和演進

如上圖，是這幾年來支付寶客戶端在可用性運維上的發(fā)展歷史，大致分為了三個階段。隨著支付寶的成長，可用性運維也一直在演進，***演進到了移動端高可用的狀態(tài)。

***個階段就是簡單的閃退監(jiān)控。絕大多數(shù)的 APP 也做過這個事情，就是本地收集一些閃退信息并進行上報，在 APP 后臺對于閃退率進行監(jiān)控，解決閃退比較多的問題，并在 APP 的下一個版本中進行相應的修改，***使閃退率維持在某一個指標以下。

但是現(xiàn)在來看，這個階段距離實現(xiàn)高可用的要求相差很遠，因為用戶所遇到不可用問題中閃退只占據(jù)其中一部分，所以對可用性而言，解決了閃退問題只是改進了一點點而已，還存在著大部分的問題沒有解決。

第二個階段，在阿里巴巴內部叫做穩(wěn)定性監(jiān)控體系，相比于***個階段而言，穩(wěn)定性監(jiān)控體系可以說前進了非常大的一步。

首先，可以監(jiān)控的問題大大豐富了，通過對多種問題的監(jiān)控可以了解線上用戶穩(wěn)定性方面的可用情況，而不僅僅是一個用戶。

第二個方面，穩(wěn)定性監(jiān)控體系具有相當程度的診斷能力和修復能力。當發(fā)現(xiàn)問題的時候，可以通過診斷日志等相應的方法分析故障原因并嘗試進行修復。

穩(wěn)定性監(jiān)控體系在最初的時候效果比較不錯，并且阿里巴巴內部也使用了很長的時間，但是后來問題也逐漸暴露出來。

舉兩個例子，曾經(jīng)一個版本的 APP 在 X86 一款機器上運行時出現(xiàn)的問題非常多，但是那個機型的用戶量很小，所以問題一直都沒有被發(fā)現(xiàn)，直到很晚的時候才通過其他方式發(fā)現(xiàn)了這個問題，也就是說因為只監(jiān)控具體問題導致已經(jīng)不能發(fā)現(xiàn)局部人群的問題了。

第二個例子，在做像雙 11 這樣的大促值班的技術保障的時候，因為監(jiān)控的問題比較多，運維人員需要通過不停地翻監(jiān)控來發(fā)現(xiàn)問題，翻來翻去***還是不敢確定 APP 的可用性到底有沒有問題，有時候確實會遺漏一些問題。

第三個方案就是在發(fā)現(xiàn)了問題之后，能否快速修復還需要碰運氣，有可能很快就能夠修復，也有可能修復起來不太容易，需要等到下一次發(fā)版，這就使得有些問題所影響用戶數(shù)會非常多。

以上就是在 2.0 階段所遇到的問題，這說明穩(wěn)定性監(jiān)控體系也已經(jīng)不夠用了，需要繼續(xù)進行改進，這也是支付寶決定繼續(xù)做 3.0 階段的移動端高可用的動機和動力。

移動端高可用的定義、目標、核心打法

高可用在移動端的重新定義

高可用原本屬于服務端的概念，阿里巴巴的服務端都在講高可用。服務端的高可用重點講的是停機時間短、服務不可用時間短。

移動端的高可用從服務端借鑒過來之后進行了重新定義，因為客戶端不存在停機時間概念。

所以，移動端高可用的定義是指通過專門的設計，結合整套技術體系，保證用戶所遇到的技術不可用總次數(shù)很低。

移動端高可用的目標

簡單來說，移動端高可用的目標就是實現(xiàn)可用率達到 99.99%，這里的可用率是支付寶自己定義的概念，指的就是用戶在使用 APP 的時候，可用次數(shù)在使用次數(shù)當中的占比，可用率達到 99.99%。

也就意味著用戶使用 1 萬次支付寶中的 9999 次都必須是可用的，最多只有一次不可用。為了實現(xiàn)這一目標，還會將任務拆解成為不同的子目標分別攻克。

移動端高可用的核心打法

目標的實現(xiàn)還是比較困難的，因為讓可用率達到 99.99% 是一個很高的指標。而為了能夠努力實現(xiàn)這個目標，支付寶也自創(chuàng)了一套核心打法。

主要分為以下四個部分：

• 客戶端可用性監(jiān)控。用戶遇到不可用的時候，要把造成不可用的問題收集并上報上來，并且要提供足夠的診斷信息用于分析解決。
• 高靈敏監(jiān)控報警平臺。需要實現(xiàn)當線上的問題剛剛出現(xiàn)苗頭的時候就立即能夠發(fā)現(xiàn)。
• 快速修復能力。當發(fā)現(xiàn)問題之后不僅要保證能夠修復，還要保證修復的速度足夠快。對一些級別高的故障，支付寶要求在一個小時之內完成快速修復。
• 故障演練。

支付寶在移動端高可用技術實踐

如上圖所示，是支付寶實現(xiàn)的移動端高可用技術架構圖，大家可以看到支付寶移動端高可用的技術架構設計也是圍繞上述的四個核心打法展開的。

客戶端可用性監(jiān)控

問題采集

客戶端可用性監(jiān)控的***步就是問題采集，當 APP 發(fā)生不可用時必須能夠感知和采集到問題，這是基礎的基礎，如果沒有這個基礎后續(xù)什么都不能實現(xiàn)。

怎樣確保當用戶出現(xiàn)了不可用情況時能夠采集到問題？這是比較困難的，因為我們不能保證一定可以采集到所有類型的不可用問題，但是還是會通過多種方法盡量地實現(xiàn)全面覆蓋。

支付寶把不可用問題分為穩(wěn)定性不可用和業(yè)務不可用兩個方面。對于穩(wěn)定性不可用而言，通過 2.0 階段的逐漸摸索以及各種反饋渠道、問題搜集渠道的補充，現(xiàn)在已經(jīng)可以把各種各樣穩(wěn)定性的不可用問題搜集得比較全了。

比如傳統(tǒng)的閃退、卡死等以及不容易被監(jiān)控的黑屏、白屏以及非閃退類型的異常退出等。

目前已經(jīng)采集到了大部分的問題，當然可能還會存在遺漏，對于這些遺漏的問題，還需要通過不停地搜集并補充到這個體系中。

對于業(yè)務不可用而言，在開發(fā)時會對于業(yè)務不可用問題進行埋點，只需要將業(yè)務不可用埋點納入到系統(tǒng)里面來，就能夠基本覆蓋最重要的業(yè)務不可用問題。

統(tǒng)一管控

當問題采集上來之后，需要通過統(tǒng)一管控形成客戶端可用率指標。通過這個指標可以全面地評估線上某一個人群中的可用情況，而不需要像以前那樣逐一檢查各個指標并在***給一個不太準確的評估結果。通過統(tǒng)一管控可以設計出整體的監(jiān)控和報警機制以及各種算法模型，并且其擴展性更好。

埋點上報

埋點上報這一功能是非常核心的，因為后續(xù)還要利用不可用埋點做高靈敏，所以埋點的實時性、準確性、到達率的要求特別高。

并且對于不可用埋點而言，當客戶端已經(jīng)發(fā)生了不可用時才需要進行上報，而在這個時候客戶端情況很可能非常惡劣，甚至此時客戶端可能已經(jīng)無法啟動了，即便是這樣也要保證埋點能夠上報。

為了實現(xiàn)這一點，我們利用了一些小技巧，比如對于 Android 系統(tǒng)而言，支付寶通過獨立的輕量級進程來單獨上報埋點，即便主進程已經(jīng)掛掉了，但是埋點也能夠實時上報上來。

對于 iOS 系統(tǒng)而言，采取在線上 hold 住進程使其報完埋點再退出去的方式，并且后續(xù)還有補償機制，即使出現(xiàn)遺漏埋點的情況也能夠使其最終能夠上報上來。

通過問題采集、統(tǒng)一管控和埋點上報，基本上可以保障當用戶遇到不可用問題時可以收集問題并上報服務端，做好了***步的基礎。

高靈敏度系統(tǒng)模型

在問題收集到的情況下需要用高靈敏系統(tǒng)模型做監(jiān)控和報警。監(jiān)控和報警在 2.0 時代就已經(jīng)存在了，比如當大盤上監(jiān)控的閃退率出現(xiàn)異常情況時就會進行報警。

但是高靈敏系統(tǒng)模型要做的是在線上問題剛剛出現(xiàn)苗頭的時候就可以發(fā)現(xiàn)，而不是等到大盤出現(xiàn)波動才發(fā)現(xiàn)。

所以這個模型的關鍵在于分析決策的過程中，它會基于用戶的人群特征、問題特征把線上采集到的不可用問題進行聚合再進行分析，通過預制的一些算法模型和規(guī)則來判斷是否產生了異常，如果最終判斷的確有異常產生了則會輸出一個異常事件。

舉個例子，比如線上的某個業(yè)務發(fā)布了一個新的 H5 離線包版本，其中某一個頁面的卡死率很高。那么使用這個頁面的用戶就會形成一個特征人群，這個特征人群的頁面卡死率就有異常的波動，這個時候就會輸出異常事件。

但是此時大盤并沒有太大波動，因為特征人群的人數(shù)并不多，但是后臺可以捕獲到異常事件。

當異常事件輸出之后，可以通過附帶信息準確地匹配到相應的負責人以及開發(fā)、測試人員，告警系統(tǒng)會告知負責人進行處理，并且會根據(jù)問題的嚴重程度采取不同的告警方式，可能會采取郵件、釘釘或者電話等方式進行告警。

在問題非常嚴重的情況下，如果幾分鐘之內沒有響應就有人打電話給負責人了。通過這樣的告警機制就可以保證無論什么時間，只要線上出現(xiàn)異常問題就可以迅速地感知到。

高可用容災平臺

通過上述的內容，我們已經(jīng)可以實現(xiàn)對于可用性問題的感知了。接下來分享如何通過高可用容災平臺修復異常問題。

這里通過整體的故障容災過程進行分享，如下圖所示，當一個故障進來了，會向相應的負責人發(fā)出告警，這時負責人需要檢查這個故障是怎樣產生的，到底是由于線上變更導致的，還是由于客戶端本身的 Bug 導致的。

如果是因為線上變更導致的則比較好辦，因為現(xiàn)在的系統(tǒng)比較靈敏，只要故障剛一發(fā)生，在短時間內負責人員就可以收到告警。

之后就可以到發(fā)布記錄中檢查這段時間內發(fā)生了哪幾次變更，可以很快地基本了解是哪一次變更導致的故障，并采取相應的處理策略。

如果可以回滾就進行回滾操作，不能回滾就需要進行緊急發(fā)布，如果不能緊急發(fā)布就要依賴客戶端進行修復。

比較麻煩的是和變更沒有關系的情況，此時就需要通過異常攜帶的診斷信息或者通過獲取一些日志來檢查問題為什么產生，問題的產生有時候是因為兼容性問題。

比如某個廠商灰度發(fā)布了一批和支付寶兼容性不太好的系統(tǒng)，導致出現(xiàn)了各種各樣的問題，這種情況下就要通過動態(tài)修復解決。

也可能一些客戶本地出現(xiàn)了嚴重錯誤，比如說產生了一些臟數(shù)據(jù)，或者安裝時因為市場的臨時性 Bug 導致了大量安裝失敗，最終導致支付寶打不開。

對于這種情況而言，可以通過本地容災做一些恢復工作，進而實現(xiàn)客戶端的自動恢復。

總之，通過上述的過程，可以使故障得到解決。從下圖中可以看出，支付寶在高可用容災中致力于兩點：

• 希望每個故障都有一個對應的方法能夠實現(xiàn)修復。
• 希望流程盡量清晰并且順滑，希望不要在流程上浪費太多時間，并且將故障盡快地解決掉。

高可用的動態(tài)修復體系

移動端高可用和服務端高可用的重大區(qū)別就是移動端的發(fā)布比較困難，所以需要依靠動態(tài)修復技術。

動態(tài)修復并不是新的概念，像 hotpatch 等技術都已經(jīng)非常成熟了，目前也有很多可選的動態(tài)修復方案。

但是，雖然在高可用的動態(tài)修復體系中，hotpatch 屬于比較重要的點，但是并不是最主要的點，因為它也存在一定的局限性，也有不適合的時候。目前，支付寶基于多種修復手段搭建了高可用的動態(tài)修復體系。

支付寶的高可用動態(tài)修復體系主要由以下三部分構成：

修復手段

修復手段有很多種，并且有輕有重。輕的手段在線上進行一些配置就可以解決線上不可用的問題，重的手段可以把整個模塊完全重新部署下去。具體應該選擇哪一種修復手段應該根據(jù)故障的情況來看，選擇效率***、風險***的修復方式。

下發(fā)通道

這一點與埋點上報的要求有一點類似，也需要高實時性和高可靠性。當用戶已經(jīng)不可用了，常規(guī)方法拉不到線上的修復方案的時候，能夠解決的辦法再多也是沒有用的，所以需要保障無論面對多么惡劣的情況下都能夠把修復方案拉下來。

下發(fā)通道的實現(xiàn)方式有很多種，最終實現(xiàn)只要能夠聯(lián)網(wǎng)一定可以將修復方案拉下來，如果暫時不能聯(lián)網(wǎng)，那么一定要在聯(lián)網(wǎng)之后將修復方案拉下來。

發(fā)布平臺

設計動態(tài)修復的發(fā)布平臺的時候非常關注的一點就是把修復方案推送給真正需要它的用戶，也就是把修復方案推給已經(jīng)出現(xiàn)或者可能出現(xiàn)這個問題的用戶。

這樣做的原因是每一次的動態(tài)修復其實也是一次線上變更，本身也是存在風險的，如果對于所有用戶都進行推送則需要比較長的時間進行灰度來保證安全，但是如果能夠只對目標的小眾人群、特征人群推送方案，這樣灰度時間會很短，修復時間也會很短。

支付寶在客戶端請求修復方案的時候，會根據(jù)客戶端的人群特征、是否發(fā)生過這個問題以及有沒有發(fā)生這個問題的可能來判斷是否把這個修復方案推送給他們，這樣可以很快地完成推送過程。這在圖中稱之為“智能修復”，其實稱之為“定向修復”更為準確一些。

高可用實戰(zhàn)經(jīng)驗

在這里和大家分享支付寶在高可用實戰(zhàn)中的兩個案例，其中一個處理的比較成功，另外一個則不是很成功。

案例 1：一個業(yè)務運營推送了一個錯誤的菜單配置，而客戶端沒有做好保護。在運營推送配置的 10 分鐘之內，相關的負責人都收到了報警，并且很快地查到是這個配置導致的。

之后運營將馬上對于配置進行了回滾，這個過程所影響用戶數(shù)比較少，所以是一個比較成功的案例。

這也是支付寶最期望的運維過程，實現(xiàn)了及時發(fā)現(xiàn)、很快修復并且影響用戶數(shù)很少。

案例 2：在一次大促的時候，一個業(yè)務開啟了限流，客戶端彈出一個限流的頁面，這個頁面有 Bug，會導致黑屏，進而導致用戶無法進行操作。

但是由于當時的可用性監(jiān)控不完善，所以這個問題沒有被監(jiān)控到，***是因為用戶的反饋才知道出現(xiàn)了問題，到問題出現(xiàn)的第三天，反饋量已經(jīng)積累到一個明顯的程度了，才發(fā)現(xiàn)這個問題。

之后，我們迅速地對于這個問題進行了分析和解決，***定位到限流的問題，一個小時之內確定了問題所在，并暫時把限流先關掉，后來把這個 Bug 修復掉了之后再將限流打開，這樣客戶端才恢復正常。

雖然最終把問題完善地解決了，但是這一過程存在非常明顯的缺陷。首先是發(fā)現(xiàn)的太晚了，這是因為可用性問題沒有覆蓋到。

另外，因為沒有足夠的信息使得決策的過程比較慢，花了 1 個小時進行分析才能夠止血，直到現(xiàn)在我們也不知道這三天到底影響了多少用戶，但是這一事件肯定對支付寶的可用性造成了不小的傷害。

而現(xiàn)在，支付寶實現(xiàn)了移動端的高可用，以后像這樣的事情不會再發(fā)生了，當出現(xiàn)故障時，支付寶可以在***天很短的時間內就可以搞定問題。

故障演練

有這樣一句話“避免故障***的方式就是不斷演練故障”，所以我們要通過可控的成本在線上真實地模擬一些故障，進行故障演練，檢驗高可用體系是否可靠，同時也讓相應的同學對系統(tǒng)、工具和流程更加熟悉，當真正發(fā)生問題的時候可以快速地處理。

為了更好的檢驗這套東西，支付寶采用了攻防對抗演練的方式，成立了一個虛擬小組，他們會想辦法模擬線上可能出現(xiàn)的故障情況，而另外一組人則利用移動端高可用技術接招，把對方研發(fā)的問題快速地處理掉。

這樣做好準備以后，當真正出現(xiàn)故障需要進行處理的時候，我們也已經(jīng)能夠熟練地應對了。

在前進中探索

***再談一下對客戶端可用性運維未來的思考：

智能化

前面提到了高靈敏的模型，大家可以看到在決策的過程中往往需要依賴預設的算法模型、規(guī)則以及數(shù)值等，這些都源于常年積攢下來的經(jīng)驗。

但是這也存在一些缺點：一是有可能出現(xiàn)誤報；二是為了防止誤報太多，這個模型不敢做的太緊，所以模型的靈敏度屬于比較靈敏，而不是極度靈敏。

我們期待通過智能化的方式，通過人工智能、機器學習的方法實現(xiàn)決策過程的智能化，可以做得更加靈敏，將問題發(fā)現(xiàn)的時間再提升一節(jié)，而且這目前已經(jīng)不僅僅是一個想法了，在支付寶的很多場景中已經(jīng)開始使用智能報警了，我們也在調研和嘗試接入這個東西。

自動化

這部分主要指的是容災過程的自動化。我們想把前面展示的容災過程做的很順滑，但是其中很多步驟都需要人來做，這樣時間成本、決策成本會很高。

所以我們希望把盡量多的步驟轉成自動化方式，至少是半自動化的方式，這樣才能讓容災過程更加順滑，使得修復時間產生本質的飛越。

產品化

我們希望當客戶端可用性更加成熟之后賦能給其他類似的 APP，通過這個過程積攢更多的經(jīng)驗，發(fā)現(xiàn)更多的問題。并且在未來合適的時間，或者 3.0 版本的客戶端可用性不能滿足需求的時候再去建設 4.0 可用性運維體系。