開篇

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

今天拋磚引玉，分享一下我們團隊的思考，希望能幫助更多的同學對前端可用性的保障工作，有一個更全面的認識，后續還會分享很多美團前端相關的內容。我們會做成一個系列，對前端感興趣的同學，可以關注我們美團技術團隊（meituantech）的公眾號，也歡迎大家跟我們一起交流、討論。

業務介紹

近幾年，隨著移動支付的普及，衍生出來聚合支付產品逐漸成為了大家進行移動支付第一選擇。而對美團金融平臺而言，支付這件事的意義和挑戰就完全不一樣，我們把它定義為“搭載火箭的冰山式服務”。之所以稱之為“火箭”，是因為我們在過去一年中，迅速成為公司又一個日訂單千萬級的業務，整個業務是火箭式的發展速度。為什么叫“冰山式的服務”？這是因為，通過我們平臺的一個二維碼、一個頁面就可以實現掃碼支付，雖然操作比較簡單，但是其背后卻涉及很多商家系統、供應鏈系統，而且還需要很多平臺系統的支撐，對技術和系統穩定性的要求非常之高。但對用戶來說，他們只是看到了“冰山一角”。

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

當我們把產品串起來之后，發現有很多端，每個端同時又有很多的邏輯線互相交叉，這就造成了整個產品和前端服務在快速發展過程中缺乏設計性，同時也缺乏可靠性、穩定性的保證。

很多同學天真的認為，前端服務應該像奧尼爾一樣穩定、強壯。但是實際情況，更可能像下了班后“葛優躺”的那種狀態。今天我們講的目標就是：

如何提高自己對所負責業務服務的信心？

之所以提這個目標，是因為有次在休假的過程中，老大問能不能保證你負責的服務不會出問題。相信很多同學都會遇到這種情況，在出去度假或者看電影時，突然接到老大的電話，對于大家來說，這種事情出現直接會影響到生活質量。所以，保障服務的可用性，其實也是提高大家生活質量的重要因素。本文將會從四個方面進行分享：

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

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

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

第四，總結一下標準的前端保障的工作流程，希望能對大家有所啟發，最好能應用到自己的工作之中。

掃碼付前端可用性定義

大家對于“系統可用性”這個概念都不陌生，其定義也比較簡單，比較好理解，業界通用的計算公式是：

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

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

但是，前端和后端對這個可用性的認知并不一樣。因為對于后端服務的可用性來說，執行環境較為可控，基本上不會存在中間的狀態。而前端服務卻大為不同，前端會面臨各式各樣不確定的用戶使用場景。比如，我們使用iPhone訪問沒有問題，測試的同學使用小米6也沒有問題，但是老板用的華為P10就有問題了。

所以，前端服務的可用性無法像后端一樣，可以有準確的數字指標，或者精確的定義公式。當然，這也是前端可用性提升面臨的問題，因為我們無法將最終的工作歸結在一個衡量指標上。

這里給大家留一個思考題：如果你負責的業務提高了萬分之一的可用性，對整個業務能夠產生多大大價值？

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

影響可用性的關鍵因素

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

客戶端升級兼容性問題：在做前端開發時，很多組件依賴于容器。比如美團App升級，但是在升級時可能并不會通知所有的業務方，而升級難免會造成兼容性問題，這種情況會造成業務不可用，甚至帶來其他相關的問題。這個問題沒有辦法完全避免。

代碼優化、服務遷移后遺癥：代碼優化和改造，這點也不可避免。因為技術在更新代碼的過程中，很難兼顧到所有的細節問題，容易造成線上事故。

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

研發流程執行不徹底：其實代碼優化層面的問題，可以通過流程或者標準化的動作進行規避。但實際過程中，很多問題是因為投入的精力有限，或者著急上線等因素，導致研發執行的不徹底或者不規范。

雖然看起來很復雜，但是歸根結底可以概括成兩大類：

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

內部節點可用性

第一點就是如何把自己的事情做好。相信很多同學都看過網上很多文章，也聽過線下很多大牛的分享，都非常有經驗了。這里還有幾個需要強調的地方：

流程規范：很多的前端事故的主要原因就是流程不規范，所以建議整個研發流程要用SOP來規避一些問題。比如上線的準入標準，服務必須達到一定的標準才能上線，在沒有明確之前不準上線等等。

方案合理：需要根據不同的業務場景，來完成合理的方案設計，之前總結過一篇文章《前端常見開發模式及相關技術介紹》，這篇文章里講到了三種不同的業務場景，以及他們適合什么樣的技術方案。如果大家不知道選擇什么樣的技術方案，那么我們給的建議就是，盡量選擇簡單。這樣的目的是，當真正發生問題的時候，能夠快速解決問題，很多前端開發同學屬于“熱鬧驅動式”選型，但在優化時卻無從下手，這點并不可取。

代碼規范：一般而言，很少有前端代碼寫的不規范，但是可以在流程和制度層面進行額外的要求。很多時候，前端的語法要求不是特別嚴格，但是服務可用性有額外的要求，代碼規范，可以幫助規避簡單的問題。

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

外部鏈路的可用性

對技術同學來說，在做任何一個服務的時候，我們經常喊的口號都是“簡單可依賴”。但是在現實中，“簡單可依賴”幾乎是不存在的，沒有任何一個人敢說自己負責的服務能夠達到簡單可依賴，這只是愿景而不是現實。

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

靜態資源的可用性

對于前端工程師來說，靜態資源的不可用，主要分以下三種情況：

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

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

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

針對第一個問題，因為靜態資源主要分為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，主要分為事前、事中、事后：

事前依賴流程與規范，包括代碼規范、分支規范、測試規范、上線規范等。如果沒有百分百的把握，不要上線。上線標準一定明確的，模棱兩可的上線，大概率會出現問題。

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

事后依賴執行力，要做可落地的Case Study。很多同學都是在事后復盤的時，說這次沒有做好，代碼寫錯了，沒有太注意，這是別人的問題等等，草草就結束了。但是對下次事故來說，并沒有預防的動作和可落地的執行方案。這就要求執行力，也看解決問題的決心。

總結

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

流程規范的執行力

工程化完整程度

很多前端的同學并沒有關注監控和報警的情況，大部分精力還是放在業務開發和功能覆蓋上。但是，制定流程規范是工程師通用的能力，希望大家在自己所負責的業務系統中，可以設定更多的流程制度，幫助保障前端服務的可用性和穩定性。

除此之外，我們要多思考。比如認真思考一下，之前的工作存在什么潛在的問題。思考的頻率如何，思考之后的結果和落地的執行力如何，這些都非常重要。

我們發現很多前端同學都把時間花在業務開發和功能覆蓋上，對于自己的系統缺少完整性的認知。所以建議大家可以先做一個通用的解決方案，覆蓋從前端到后臺，從研發、測試、上線的全流程。目前，美團金融前端團隊已經開始嘗試構建一個符合公司前端標準研發體系的解決方案，還有一個線上協作研發平臺，將集團的服務進行集成，同時把很多平常不注意的事情集中進行解決，減少重復性的工作，幫助大家把精力更多地投入在核心業務層面。

如果大家對我們所做的事情也有興趣，想要和我們一起共建大前端團隊的話，歡迎發送簡歷至 tianyang02@meituan.com 。

作者簡介

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

總結

以上是生活随笔為你收集整理的美团扫码付的前端可用性保障实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。