本文根據美團高階工程師田泱在美團技術沙龍第31期《線下支付千萬級訂單服務——前後端架構實踐》的演講內容整理而成。

2017年，美團金融前端遇到了很多通用性問題，特別是在保障前端可用性的過程中，我們團隊也踩了不少“坑”。在梳理完這些問題以後，我們舉辦了，跟大家進行了分享和交流。

不管是在面試過程中與候選人討論，還是在團隊內和前端小夥伴進行討論，都能發現很多同學有一個共同點：對所做的工作缺乏判斷。如何評判工作交付的質量，如何評判產品與客戶之間的觸達率等等，這些問題其實比“埋頭敲程式碼”重要很多。

今天拋磚引玉，分享一下我們團隊的思考，希望能幫助更多的同學對前端可用性的保障工作，有一個更全面的認識，後續還會分享很多美團前端相關的內容，大家可以關注我們美團技術團隊（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。很多同學都是在事後覆盤的時，說這次沒有做好，程式碼寫錯了，沒有太注意，這是別人的問題等等，草草就結束了。但是對下次事故來說，並沒有預防的動作和可落地的執行方案。這就要求執行力，也看解決問題的決心。

總結

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

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

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

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

我們發現很多前端同學都把時間花在業務開發和功能覆蓋上，對於自己的系統缺少完整性的認知。所以建議大家可以先做一個通用的解決方案，覆蓋從前端到後臺，從研發、測試、上線的全流程。

目前，美團金融前端團隊已經開始嘗試構建一個符合公司前端標準研發體系的解決方案，還有一個線上協作研發平臺，將集團的服務進行整合，同時把很多平常不注意的事情集中進行解決，減少重複性的工作，幫助大家把精力更多地投入在核心業務層面。

作者簡介

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

【本文轉載自美團技術團隊微信公眾號，原文連結：https://mp.weixin.qq.com/s/_KSzZhHKSACq1Skij8QbIw】

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

相關文章