美團掃碼付的前端可用性保障實踐

開篇

2017年，美團金融前端遇到了不少通用性問題，特別是在保障前端可用性的過程當中，咱們團隊也踩了很多「坑」，在梳理完這些問題之後，咱們還專門作了第31期線下沙龍給你們進行了分享。無論是在面試過程當中與候選人討論，仍是在團隊內的和咱們前端小夥伴討論，都能發現不少同窗有一個共同點，對所作的工做缺少判斷，包括如何評判工做交付的質量，如何評判產品與客戶之間的觸達率等等，這些問題其實比「埋頭敲代碼」重要不少。

今天拋磚引玉，分享一下咱們團隊的思考，但願能幫助更多的同窗對前端可用性的保障工做，有一個更全面的認識，後續還會分享不少美團前端相關的內容。咱們會作成一個系列，對前端感興趣的同窗，能夠關注咱們美團技術團隊（meituantech）的公衆號，也歡迎你們跟咱們一塊兒交流、討論。

業務介紹

近幾年，隨着移動支付的普及，衍生出來聚合支付產品逐漸成爲了你們進行移動支付第一選擇。而對美團金融平臺而言，支付這件事的意義和挑戰就徹底不同，咱們把它定義爲「搭載火箭的冰山式服務」。之因此稱之爲「火箭」，是由於咱們在過去一年中，迅速成爲公司又一個日訂單千萬級的業務，整個業務是火箭式的發展速度。爲何叫「冰山式的服務」？這是由於，經過咱們平臺的一個二維碼、一個頁面就能夠實現掃碼支付，雖然操做比較簡單，可是其背後卻涉及不少商家系統、供應鏈系統，並且還須要不少平臺系統的支撐，對技術和系統穩定性的要求很是之高。但對用戶來講，他們只是看到了「冰山一角」。

前期，咱們在作服務設計的時候，咱們覺得這個產品就是一個很簡單的服務，按照傳統前端的定義，咱們只是把前端的多個界面完成就能夠了，後端服務以及不少第三方的接口咱們不須要花太多精力去關注。可是真正接觸到項目後，咱們發現金融服務跟傳統的服務徹底不同，甚至還須要作政府方面的一些工做，好比金融最大的問題要合規，這就致使不少業務設計上，必須強制作不少功能節點，隨着業務發展過程當中節點愈來愈多，這必然致使服務的可用性愈來愈差，可能實際狀況比下面這張圖更復雜。

當咱們把產品串起來以後，發現有不少端，每一個端同時又有不少的邏輯線互相交叉，這就形成了整個產品和前端服務在快速發展過程當中缺少設計性，同時也缺少可靠性、穩定性的保證。

不少同窗天真的認爲，前端服務應該像奧尼爾同樣穩定、強壯。可是實際狀況，更可能像下了班後「葛優躺」的那種狀態。今天咱們講的目標就是：

如何提升本身對所負責業務服務的信心？

之因此提這個目標，是由於有次在休假的過程當中，老大問能不能保證你負責的服務不會出問題。相信不少同窗都會遇到這種狀況，在出去度假或者看電影時，忽然接到老大的電話，對於你們來講，這種事情出現直接會影響到生活質量。因此，保障服務的可用性，其實也是提升你們生活質量的重要因素。本文將會從四個方面進行分享：

第一，如何定義的前端可用性。

第二，影響前端可用性的關鍵因素是什麼。

第三，解決這些關鍵問題的處理方式，或者說端到端監控與降級處理的方案。

第四，總結一下標準的前端保障的工做流程，但願能對你們有所啓發，最好能應用到本身的工做之中。

掃碼付前端可用性定義

你們對於「系統可用性」這個概念都不陌生，其定義也比較簡單，比較好理解，業界通用的計算公式是：

%availability=（Total Elapsed Time－Sum of Inoperative Times）/ Total Elapsed Time

也就是 平均無端障時間/（平均無端障時間+平均故障修復時間） 的百分比。

可是，前端和後端對這個可用性的認知並不同。由於對於後端服務的可用性來講，執行環境較爲可控，基本上不會存在中間的狀態。而前端服務卻大爲不一樣，前端會面臨各式各樣不肯定的用戶使用場景。好比，咱們使用iPhone訪問沒有問題，測試的同窗使用小米6也沒有問題，可是老闆用的華爲P10就有問題了。

因此，前端服務的可用性沒法像後端同樣，能夠有準確的數字指標，或者精確的定義公式。固然，這也是前端可用性提高面臨的問題，由於咱們沒法將最終的工做歸結在一個衡量指標上。

這裏給你們留一個思考題：若是你負責的業務提升了萬分之一的可用性，對整個業務可以產生多大大價值？

在美團金融，咱們團隊粗略算過，若是業務的可用性提升萬分之一，對業務部門的價值提高，至少在五位數以上。能夠說，不積跬步，無以致千里。能夠說，在前端領域，任何一點微小的進步或者提高，都值得咱們付出百分之一百的努力。

影響可用性的關鍵因素

咱們把2017年前端發生的故障分爲四種類型：

1. 客戶端升級兼容性問題：在作前端開發時，不少組件依賴於容器。好比美團App升級，可是在升級時可能並不會通知全部的業務方，而升級不免會形成兼容性問題，這種狀況會形成業務不可用，甚至帶來其餘相關的問題。這個問題沒有辦法徹底避免。

2. 代碼優化、服務遷移後遺症：代碼優化和改造，這點也不可避免。由於技術在更新代碼的過程當中，很難兼顧到全部的細節問題，容易形成線上事故。

3. 外部依賴服務故障：這是比較典型的問題，對於前端來講，最多見的就是接口服務或者依賴的基礎服務組件出現故障，這些都會致使前端業務的不可用；

4. 研發流程執行不完全：其實代碼優化層面的問題，能夠經過流程或者標準化的動做進行規避。但實際過程當中，不少問題是由於投入的精力有限，或者着急上線等因素，致使研發執行的不完全或者不規範。

雖然看起來很複雜，可是歸根結底能夠歸納成兩大類：

第一類問題，就是咱們自身的問題，能夠比喻成「我撞在豬身上了」；第二類問題就是別人的問題，能夠理解成「豬撞我身上了」，咱們常常說這樣一句話，「不怕神同樣的對手，就怕豬同樣的隊友」，在前端開發問題上，這個道理同樣適用。

內部節點可用性

第一點就是如何把本身的事情作好。相信不少同窗都看過網上不少文章，也聽過線下不少大牛的分享，都很是有經驗了。這裏還有幾個須要強調的地方：

1. 流程規範：不少的前端事故的主要緣由就是流程不規範，因此建議整個研發流程要用SOP來規避一些問題。好比上線的准入標準，服務必須達到必定的標準才能上線，在沒有明確以前不許上線等等。

2. 方案合理：須要根據不一樣的業務場景，來完成合理的方案設計，以前總結過一篇文章《前端常見開發模式及相關技術介紹》，這篇文章裏講到了三種不一樣的業務場景，以及他們適合什麼樣的技術方案。若是你們不知道選擇什麼樣的技術方案，那麼咱們給的建議就是，儘可能選擇簡單。這樣的目的是，當真正發生問題的時候，可以快速解決問題，不少前端開發同窗屬於「熱鬧驅動式」選型，但在優化時卻無從下手，這點並不可取。

3. 代碼規範：通常而言，不多有前端代碼寫的不規範，可是能夠在流程和制度層面進行額外的要求。不少時候，前端的語法要求不是特別嚴格，可是服務可用性有額外的要求，代碼規範，能夠幫助規避簡單的問題。

除了上述三點以外，還有一點建議提高測試的效率，雖然整個行業都在作，可是也不是特別理想。之因此提倡單元化測試和自動化測試，主要是由於能夠幫助咱們減小工做流程中重複的工做，將更多時間投入到業務開發層面。目前，已經實現了Android容器上的自動化測試，同時咱們也在使用一些標準規避容器和外部依賴形成的故障。

外部鏈路的可用性

對技術同窗來講，在作任何一個服務的時候，咱們常常喊的口號都是「簡單可依賴」。可是在現實中，「簡單可依賴」幾乎是不存在的，沒有任何一我的敢說本身負責的服務可以達到簡單可依賴，這只是願景而不是現實。

咱們使用外部服務的時，怎麼保證它的可用性呢？對於前端開發者來講，外部服務主要分爲資源的可用性和接口的可用性，接下來咱們依次進行分析：

靜態資源的可用性

對於前端工程師來講，靜態資源的不可用，主要分如下三種狀況：

1. 資源加載問題：在一個臨時的弱網環境下，文件加載失敗，好比說電梯間或者一個封閉的過道。

2. 網絡劫持問題：代碼篡改的問題，靜態資源在通過一些網絡運營商時，被進行篡改或者注入廣告。

3. 代碼執行問題：多是兼容性問題，也多是代碼語法或者邏輯出現問題。

針對第一個問題，由於靜態資源主要分爲CSS文件和JS文件，CSS文件與咱們的核心業務無依賴關係，因此加載失敗的時候進行重試，保障頁面樣式可還原。

而JS文件涉及一些依賴的文件，因此咱們採用一個比較穩妥的方案：在判斷核心的JS文件加載失敗時，降級爲一個MVP的版本，來保障交易的正常進行。如右圖所示，在沒有作靜態資源降級以前，這個門店是正常的會員門店，會有促銷的活動和信息。在CDN出現問題時，它會出現白屏問題。而在通過降級處理以後，咱們能夠把整個頁面回退成普通的門店，就不包含營銷或者促銷信息了。

整個方案有一個核心點，就是在CDN不可用時進行降級或者重試的過程當中，還會遇到不可用的狀況，咱們最終要把資源回到源服務，至少保障在源服務上能夠提供一個靜態的頁面提供給用戶。這裏也存在一個風險點，若是資源掛掉的話，源服務能不能承受CDN回源產生的額外流量？這個你們須要打一個問號，也須要特別注意。若是採用這樣的方法，必定要評估好服務能不能承受這麼大的壓力。

第二個問題，你們都比較頭疼。由於運營商是以省爲單位運營的，因此在跨省的資源請求上會形成額外的流量，基於這個問題，每個省級運營商都會想辦法節省流量，對於流量大的資源有可能會進行劫持甚至篡改。

首先是要預防，一個簡單的方案：所有把域名所有升級爲HTTPS，讓劫持篡改失去了價值，這樣能夠下降一些風險。若是還支持HTTP訪問，依然還會存在被劫持的風險。

其次，在發現劫持問題後，要快速幫助用戶修復。美團運維有統一的120模式，這個模式會幫助咱們收集一些用戶的環境信息，包括網絡信息、手機版本號等等，從而快速定位這個問題，全力保障用戶體驗。

最後是監控，流量劫持都是以省級爲單位的，因此在資源監控上，咱們要求至少要作到省級，最好可以作到市級，若是發現某一個市、某一個省靜態資源發生問題，就第一時間啓動修復。

還有一個隱性問題，就是在CDN回源的時，資源請求是否是應該使用HTTPS？在這個問題上，由於考慮到性能，回源請求會使用HTTP。因此廣泛來說，CDN文件的請求會使用HTTPS，意味着咱們使用HTTPS來保證CDN不會被劫持，可是CDN回源會形成風險，至關於HTTPS預防這種方式，在理論上不能徹底解決這個問題。

最後，還有一個代碼執行層面的問題。咱們會把報錯信息，及時上報到平臺上進行分析和處理，目前美團使用統一監控方案CAT，如今已經開源了。

接口服務的可用性

不少前端開發同窗有一個很大的誤區，接口不可用並非前端的問題。不少同窗會先定位這個問題屬於本身仍是別人，若是是後端的問題，本身的心態就是「燒高香」。

但實際狀況是，系統可用性須要前端和後端共同努力，若是後端不可用，前端怎麼提高都是沒有效果的，因此咱們須要改變本身的認識。若是發現接口有問題，第一時間幫助後端解決或者幫助定位，減小故障影響的時間，這也能提升前端的服務效率。美團對技術團隊的要求是，提升監控和反饋的敏銳度。接下來，就涉及到端到端監控和降級的方案了。

端到端監控與降級

監控、報警的目的是爲了快速的發現問題。若是定位到問題，第一時間不能靠人力進行解決，那麼應該立刻進行故障自動處理或者降級。

可控的一些降級的方案在上文中已經提到。對於前端的監控，咱們使用了美團開源的CAT。CAT能夠定義每一個頁面覆蓋資源的狀況，能夠細分到省、系統、網絡、運營商等維度，從而幫更快的發現劫持和篡改的狀況，而後及時進行修復。

故障演練的必要性

在實際工做中，咱們不少時候都缺乏執行力。好比上文提到的故障處理的方法和方案，在實際工做中有沒有效果，或者能不能爲業務作出價值和貢獻，都須要要打個問號。固然，若是這些事情都沒有實踐，也至關於「紙上談兵」。因此，爲了最終要達到目的，提升系統的可用性，就須要提升系統的檢驗標準，接下來就是要作故障演練。

好比，咱們能夠人爲的讓後端接口掛掉，看前端服務的表現；讓靜態資源掛掉，檢查對服務有沒有影響。如今，美團的靜態資源託管服務上運行着近千個項目，若是掛掉的話，會形成沒法想象的後果。在這種狀況下，託管CDN以後並不意味着會帶來一些很好的效果，實際上它也會帶來不少沒法想象、沒法預知的問題。因此爲了系統的穩定性保障，最終落地點就是故障演練。

保障動做標準流程

最後總結幾點，幫助你們作系統可用性的Review，主要分爲事前、事中、過後：

1. 事前依賴流程與規範，包括代碼規範、分支規範、測試規範、上線規範等。若是沒有百分百的把握，不要上線。上線標準必定明確的，模棱兩可的上線，大機率會出現問題。

2. 事中依賴監控與降級，能夠設計一些監控和降級的方案。對於不可降級的要作好事前的預案，同時也依賴於演練的頻率。演練的次數多了，就能夠經過熟練的操做，下降服務受影響的時間，間接提升服務的可用性。

3. 過後依賴執行力，要作可落地的Case Study。不少同窗都是在過後覆盤的時，說此次沒有作好，代碼寫錯了，沒有太注意，這是別人的問題等等，草草就結束了。可是對下次事故來講，並無預防的動做和可落地的執行方案。這就要求執行力，也看解決問題的決心。

總結

最後總結，影響前端服務可用性，其實就是兩件事：

1. 流程規範的執行力
2. 工程化完整程度

不少前端的同窗並無關注監控和報警的狀況，大部分精力仍是放在業務開發和功能覆蓋上。可是，制定流程規範是工程師通用的能力，但願你們在本身所負責的業務系統中，能夠設定更多的流程制度，幫助保障前端服務的可用性和穩定性。

除此以外，咱們要多思考。好比認真思考一下，以前的工做存在什麼潛在的問題。思考的頻率如何，思考以後的結果和落地的執行力如何，這些都很是重要。

咱們發現不少前端同窗都把時間花在業務開發和功能覆蓋上，對於本身的系統缺乏完整性的認知。因此建議你們能夠先作一個通用的解決方案，覆蓋從前端到後臺，從研發、測試、上線的全流程。目前，美團金融前端團隊已經開始嘗試構建一個符合公司前端標準研發體系的解決方案，還有一個線上協做研發平臺，將集團的服務進行集成，同時把不少日常不注意的事情集中進行解決，減小重複性的工做，幫助你們把精力更多地投入在覈心業務層面。

若是你們對咱們所作的事情也有興趣，想要和咱們一塊兒共建大前端團隊的話，歡迎發送簡歷至 tianyang02@meituan.com 。

做者簡介

田泱，2015年校招入職美團，前後參與過美團平臺移動版多項垂直品類的前端研發工做，從0到1參與了智能支付應用層的前端建設工做，現負責美團金融服務平臺前端基礎服務研發團隊。