1. 背景

1.1 移動端跨平臺技術(shù)的介紹

移動端的跨平臺技術(shù)不是一個新話題，早在幾年前，WebView容器、React Native、Weex、Flutter、小程序等移動端跨平臺框架就風(fēng)起云涌。為什么跨平臺這么有吸引力呢？我們設(shè)想一下如果可以做到一次開發(fā)，多端復(fù)用，那么對于公司來說，就可以降低用人成本。對于開發(fā)來說，只需要學(xué)習(xí)一個框架，就可以在Android和iOS雙平臺上開發(fā)。節(jié)約下來的成本，可以投入到產(chǎn)品快速驗證、快速上線。這對所有人來說都有著極大的吸引力。本節(jié)先針對部分移動端跨平臺技術(shù)進(jìn)行一些簡要的介紹，以便讀者能夠更好地理解后面的內(nèi)容。

1.1.1 WebView容器

WebView容器的工作原理是基于Web技術(shù)來實現(xiàn)界面和功能，通過將原生的接口封裝、暴露給JavaScript調(diào)用，JavaScript編寫的頁面可以運(yùn)行在系統(tǒng)自帶的WebView中。這樣做的優(yōu)勢是，對于前端開發(fā)者比較友好，可以很快地實現(xiàn)頁面跨端，同時保留調(diào)用原生的能力，通過搭建橋接層和原生能力打通。但這種設(shè)計，跨端的能力受限于橋接層，當(dāng)調(diào)用之前沒有的原生能力時，就需要增加橋。另外，瀏覽器內(nèi)核的渲染獨(dú)立于系統(tǒng)組件，無法保證原生體驗，渲染的效果會差不少。

1.1.2 React Native

2015年，F(xiàn)acebook推出了React Native，一經(jīng)推出就備受關(guān)注。它的思路是最大化地復(fù)用前端的生態(tài)和Native的生態(tài)，和WebView容器的最大區(qū)別在于View的渲染體系。React Native拋棄了低效的瀏覽器內(nèi)核渲染，轉(zhuǎn)而使用自己的DSL生成中間格式，然后映射到對應(yīng)的平臺，渲染成平臺的組件。相對WebView容器，體驗會有一定的提升。不過，渲染時需要JavaScript和原生之間通信，在有些場景可能會導(dǎo)致卡頓。另外就是，渲染還是在Native層，要求開發(fā)人員對Native有一定的熟悉度。

1.1.3 Flutter

2018年Google推出Flutter，通過Dart語言構(gòu)建一套跨平臺的開發(fā)組件，所有組件基于Skia引擎自繪，在性能上可以和Native平臺的View相媲美。Flutter站在前人的肩膀上，參考了React的狀態(tài)管理、Web的自繪制UI、React Native的HotReload等特點，同時考慮了與Native通信的Channel機(jī)制、自渲染、完備的開發(fā)工具鏈。Flutter與上述Recat Native、WebView容器本質(zhì)上都是不同的，它沒有使用WebView、JavaScript解釋器或者系統(tǒng)平臺自帶的原生控件，而是有一套自己專屬的Widget，底層渲染使用自身的高性能C/C++ 引擎自繪。但大部分移動端發(fā)展到今天，都已經(jīng)形成了自己的架構(gòu)，在現(xiàn)有基礎(chǔ)上加上Flutter，會形成原有架構(gòu)和Flutter雙平臺共存的問題。目前，對新的App來說，是最被看好的跨端方案。

1.2 美團(tuán)外賣業(yè)務(wù)介紹

作為中國領(lǐng)先的生活服務(wù)電子商務(wù)平臺，美團(tuán)致力于用科技連接消費(fèi)者和商家，提供服務(wù)以滿足人們?nèi)粘！俺浴钡男枨?，并進(jìn)一步擴(kuò)展至多種生活和旅游服務(wù)。而作為公司最為重要的業(yè)務(wù)之一，美團(tuán)外賣從2013年創(chuàng)建以來，已經(jīng)從單一的品類擴(kuò)展到附近美食、水果、蔬菜、超市、鮮花、蛋糕等多品類，從早午晚餐，發(fā)展到下午茶、宵夜，中餐、西餐、家常菜、小吃、快餐、海鮮、火鍋、川菜、蛋糕、烤肉、水果、飲料、甜點等多種類餐飲。美團(tuán)外賣可以說是當(dāng)前電商領(lǐng)域，最為復(fù)雜的業(yè)務(wù)之一。

業(yè)務(wù)的復(fù)雜，給系統(tǒng)架構(gòu)也帶來了不小的挑戰(zhàn)。美團(tuán)外賣業(yè)務(wù)之所以說是當(dāng)前電商領(lǐng)域最為復(fù)雜的業(yè)務(wù)，主要源于以下幾點特征：

• 美團(tuán)外賣業(yè)務(wù)承載在三個App上，美團(tuán)外賣App、美團(tuán)App外賣頻道、點評App外賣頻道。
• 美團(tuán)外賣作為美團(tuán)公司重要的用戶入口，還承擔(dān)著流量平臺的作用，提供平臺能力支撐頻道業(yè)務(wù)的發(fā)展，如閃購、跑腿、金融等。
• 美團(tuán)外賣作為已經(jīng)成熟的業(yè)務(wù)，需提供可復(fù)用的平臺能力，支撐新業(yè)務(wù)的發(fā)展，例如菜大全App的發(fā)展。

• 美團(tuán)外賣作為一個超級業(yè)務(wù)方，業(yè)務(wù)內(nèi)又運(yùn)營多個方向業(yè)務(wù)，如流量業(yè)務(wù)、交易業(yè)務(wù)、商家業(yè)務(wù)、商品業(yè)務(wù)、營銷業(yè)務(wù)、廣告業(yè)務(wù)等。

綜上所述，可以發(fā)現(xiàn)美團(tuán)外賣不僅僅自身業(yè)務(wù)比較復(fù)雜，而且對外的角色也很復(fù)雜。在美團(tuán)內(nèi)部，外賣不僅僅是美團(tuán)平臺的一個頻道業(yè)務(wù)，而且自己本身也是一個平臺業(yè)務(wù)，同時美團(tuán)外賣還承擔(dān)著新業(yè)務(wù)發(fā)展的平臺角色。這意味著想要支持好美團(tuán)外賣業(yè)務(wù)的發(fā)展是一件非常有挑戰(zhàn)的事情。

1.3 美團(tuán)外賣移動端歷史架構(gòu)概述

好的架構(gòu)源于不停地衍變而非設(shè)計。美團(tuán)外賣的架構(gòu)，歷史上也是經(jīng)歷了很多次迭代。由于外賣業(yè)務(wù)形態(tài)不斷地發(fā)生變化，原有的設(shè)計也需要不斷地跟隨業(yè)務(wù)形態(tài)進(jìn)行演進(jìn)。在不斷探索和實踐過程中，我們經(jīng)歷了若干個大的架構(gòu)變遷。從考慮如何高效地復(fù)用代碼支持外賣App，逐漸地衍變成如何去解決多端代碼復(fù)用問題，再從多端的代碼復(fù)用到支持其他頻道業(yè)務(wù)的平臺架構(gòu)上。在平臺化架構(gòu)建設(shè)完成后，我們又開始嘗試?yán)脛討B(tài)化技術(shù)去支持業(yè)務(wù)快速上線的訴求。如今，我們面臨著多端復(fù)用、平臺能力、平臺支撐、單頁面多業(yè)務(wù)團(tuán)隊、業(yè)務(wù)動態(tài)訴求強(qiáng)等多個業(yè)務(wù)場景問題。下文我們針對美團(tuán)外賣移動端架構(gòu)的變遷史，做一些簡單的概述，以便讀者閱讀本文時能有更好的延續(xù)性。

1.3.1 組件化架構(gòu)

早期階段，美團(tuán)外賣作為公司的一個孵化業(yè)務(wù)，在2013年底完成了美團(tuán)外賣App的1.0版本。隨著外賣業(yè)務(wù)的驗證成功和跑通，訂單量也快速增長，在2014年底突破了日訂單量100萬。

隨后在2015年2月，外賣以Native的形式接入美團(tuán)App，成為美團(tuán)App的一個業(yè)務(wù)頻道。在接入過程中，我們從美團(tuán)外賣App拷貝了大量的代碼到美團(tuán)App的外賣頻道，兩個App上的外賣業(yè)務(wù)代碼也分別由兩個獨(dú)立的團(tuán)隊維護(hù)。早期外賣業(yè)務(wù)變化快，App迭代頻繁，寫代碼的方式也比較粗放，同時美團(tuán)App也處在一個平臺化轉(zhuǎn)變的時期，代碼的穩(wěn)定性和質(zhì)量都在變化和提升當(dāng)中。這些因素導(dǎo)致了外賣代碼內(nèi)各子系統(tǒng)之間耦合嚴(yán)重，邊界模糊，“你中有我，我中有你”的情況隨處可見。這對代碼質(zhì)量、功能擴(kuò)展以及開發(fā)效率都造成很大的影響。

此時，我們架構(gòu)重構(gòu)的目的，就是希望將各個子系統(tǒng)劃分為相對獨(dú)立的組件，建設(shè)組件可以直接復(fù)用，架構(gòu)如下圖所示：

1.3.2 平臺化架構(gòu)

如上文所述，大家可以知道美團(tuán)外賣和美團(tuán)外賣頻道是由不同的團(tuán)隊在維護(hù)發(fā)展。2015年，公司考慮到業(yè)務(wù)發(fā)展的一致性，將美團(tuán)外賣頻道團(tuán)隊正式歸于美團(tuán)外賣。從組織架構(gòu)上來說，美團(tuán)外賣和美團(tuán)外賣頻道，逐漸融合成一個團(tuán)隊，但是兩端的差異性，導(dǎo)致我們不得不仍然階段性地維持原有的兩班人馬，各自去維護(hù)獨(dú)立外賣App和美團(tuán)外賣頻道。如何解決這個問題？兩端代碼復(fù)用看起來是唯一的途徑。另外，隨著業(yè)務(wù)的快速發(fā)展，外賣App所承載的業(yè)務(wù)模塊越來越多，產(chǎn)品功能越來越復(fù)雜，團(tuán)隊規(guī)模也越來越大，如閃購、跑腿等業(yè)務(wù)想以獨(dú)立的Native包的形態(tài)接入外賣App，還有外賣的異地研發(fā)團(tuán)隊的建立，都帶來了挑戰(zhàn)。這使得我們在2017年開始了第二次架構(gòu)重構(gòu)——平臺化架構(gòu)，目標(biāo)是希望能夠支持多端復(fù)用和支持不同團(tuán)隊的業(yè)務(wù)發(fā)展。通過抽象出平臺能力層、業(yè)務(wù)解耦、建立殼容器，最終實現(xiàn)了平臺化架構(gòu)，架構(gòu)如下圖所示：

1.3.3 RN混合架構(gòu)

在平臺化架構(gòu)之后，美團(tuán)外賣功能持續(xù)增加，美團(tuán)外賣客戶端安裝包的體積也在持續(xù)增加。回顧2017年和2018年，每年幾乎都增長100%。如果沒有一個有效的手段，安裝包將變得越發(fā)臃腫。另外，由于原生應(yīng)用需要依托于應(yīng)用市場進(jìn)行更新，每次產(chǎn)品的更新，必須依賴用戶的主動更新，使得版本的迭代周期很長。業(yè)務(wù)上的這些痛點，不斷地督促我們?nèi)シ此嫉降子袥]有一種框架可以解決這些問題。

在2015年的時候，F(xiàn)acebook發(fā)布了非常具有顛覆性的React Native框架，簡稱RN。從名字上看，就可以清楚的明白，這是混合式開發(fā)模式，RN使用Native來渲染，JS來編碼，從而實現(xiàn)了跨平臺開發(fā)、快速編譯、快速發(fā)布、高效渲染和布局。RN作為一種跨平臺的移動應(yīng)用開發(fā)框架，它的特性非常符合我們的訴求。美團(tuán)也積極地探索RN技術(shù)。在RN的基礎(chǔ)上，美團(tuán)在腳手架、組件庫、預(yù)加載、分包構(gòu)建、發(fā)布運(yùn)維等方面進(jìn)行了全面的定制及優(yōu)化，大幅提升RN的開發(fā)及發(fā)布運(yùn)維效率，形成了MRN（Meituan React Native）技術(shù)體系。

從2018年開始，美團(tuán)外賣客戶端團(tuán)隊開始嘗試使用MRN框架來解決業(yè)務(wù)上的問題。使用RN的另一方面的好處是，能逐漸的抹平Android和iOS開發(fā)技術(shù)棧帶來的問題，使用一套代碼，兩個平臺上線，理論上人效可以提升一倍，支持的業(yè)務(wù)需求也可以提升一倍，架構(gòu)如下圖所示：

2. 美團(tuán)外賣容器化架構(gòu)全景圖

2.1 什么是容器化架構(gòu)

上文說到，外賣業(yè)務(wù)已經(jīng)發(fā)展到多App復(fù)用、單頁面多業(yè)務(wù)團(tuán)隊開發(fā)的業(yè)務(wù)階段。要滿足這樣的業(yè)務(wù)場景下，尋求一個可持續(xù)發(fā)展的業(yè)務(wù)架構(gòu)是件不容易的事情。經(jīng)過我們之前架構(gòu)演進(jìn)，我們獲得了寶貴的經(jīng)驗：在平臺化架構(gòu)的時候，我們將App和業(yè)務(wù)進(jìn)行解耦，將App做成殼容器，業(yè)務(wù)形成獨(dú)立的業(yè)務(wù)庫，集成到殼容器里面，從而屏蔽了多App的問題，提高了業(yè)務(wù)的復(fù)用度。在RN混合式架構(gòu)里面，我們引入了RN容器，通過這個容器，使得業(yè)務(wù)屏蔽了Android和iOS的平臺差異。借助這些成功的經(jīng)驗，我們進(jìn)一步思考，如果我們嘗試進(jìn)一步的細(xì)分外賣的業(yè)務(wù)場景，將不同場景下的基礎(chǔ)能力建設(shè)成殼容器，業(yè)務(wù)集成到容器內(nèi)，是否可以更好的支撐我們多App復(fù)用、單頁面多業(yè)務(wù)團(tuán)隊的當(dāng)前現(xiàn)狀呢？

容器化架構(gòu)的愿景是：

• 希望將前端呈現(xiàn)業(yè)務(wù)的環(huán)境抽象出來，將能力進(jìn)行標(biāo)準(zhǔn)化，形成統(tǒng)一的容器，通過容器去屏蔽平臺和端的差異。容器提供上層標(biāo)準(zhǔn)統(tǒng)一的能力接口，使得業(yè)務(wù)開發(fā)人員專注于容器內(nèi)的業(yè)務(wù)邏輯的實現(xiàn)，最大復(fù)用已有的能力，而不用關(guān)注現(xiàn)在的環(huán)境是Android還是iOS，現(xiàn)在的端是美團(tuán)App還是大眾點評App。

• 容器和遠(yuǎn)端達(dá)成呈現(xiàn)協(xié)議，使得端上的內(nèi)容具備隨時可變化的能力。容器化架構(gòu)的實現(xiàn)是存在一定前提的，如果業(yè)務(wù)的發(fā)展本身處在一個探索階段，還有較多可變的因素，是無法形成穩(wěn)定的能力層的，這時候建設(shè)容器化架構(gòu)反而使得架構(gòu)偏向復(fù)雜。但對于外賣業(yè)務(wù)場景來說，經(jīng)過多年的沉淀固定，外賣業(yè)務(wù)逐漸形成了一套穩(wěn)定的業(yè)務(wù)形態(tài)，已經(jīng)進(jìn)入到場景細(xì)分和快速迭代業(yè)務(wù)模塊的階段。在這樣的階段下，容器化架構(gòu)才有可實施的前提。

2.2 容器化架構(gòu)的優(yōu)勢

當(dāng)我們把承載外賣業(yè)務(wù)的環(huán)境進(jìn)行了抽象和標(biāo)準(zhǔn)化后，就可以獲得以下若干點好處。首先動態(tài)化屬性提升，我們可以把原有必須在客戶端上寫的業(yè)務(wù)放到了遠(yuǎn)端，業(yè)務(wù)的動態(tài)性得到很大的提升，具備隨時上線業(yè)務(wù)的可能。對于開發(fā)過程而言，編譯部署的速度也得到了極大提升。如果涉及到客戶端的代碼改動，那客戶端的編譯打包，即使是增量的編譯，也至少是秒級的編譯速度。而容器化后，我們只打包必要的業(yè)務(wù)，把業(yè)務(wù)動態(tài)下發(fā)到容器呈現(xiàn)，客戶端代碼本身不會有變化，這樣就可以從秒級的編譯減少到毫秒級的編譯。同樣，業(yè)務(wù)動態(tài)下發(fā)，對減少客戶端的包大小也有很大的幫助。

然后，容器位于應(yīng)用之內(nèi)，我們向應(yīng)用中引入相同的容器SDK，容器屏蔽了應(yīng)用之間的差異，對于Android和iOS平臺，在設(shè)計上，通過容器這一層去盡可能屏蔽平臺之間的差異，使業(yè)務(wù)開發(fā)人員只需要認(rèn)識容器，不需要花費(fèi)大量的精力去關(guān)注應(yīng)用和平臺之間的差異，從而使得開發(fā)效率得到了極大的提升。

其次，容器化后，容器對承載的內(nèi)容是有接口協(xié)議要求的，承載的內(nèi)容只有滿足容器定義的協(xié)議才能得到容器帶來的好處，這促使業(yè)務(wù)得到了更細(xì)粒度的細(xì)分，業(yè)務(wù)開發(fā)時候，對模塊化的意識得到了保障。另外，容器這一層提供的接口在Android和iOS上是標(biāo)準(zhǔn)化的，業(yè)務(wù)的開發(fā)也因為依賴的標(biāo)準(zhǔn)化，而趨向標(biāo)準(zhǔn)化，雙端的業(yè)務(wù)一致性得到了提升。這些潛在的架構(gòu)好處，對未來的業(yè)務(wù)維護(hù)和擴(kuò)展都打下了比較好的地基。

2.3 外賣容器化架構(gòu)全景圖

整個外賣容器化架構(gòu)可以按照從下到上，從左到右的視角進(jìn)行解讀：

最底層是系統(tǒng)服務(wù)，因為我們采用了H5和RN這樣跨端的技術(shù)棧，使得iOS系統(tǒng)和Android系統(tǒng)成為了最底層。

系統(tǒng)服務(wù)之上是集團(tuán)基于Native建設(shè)的基建，全公司通用，覆蓋了研發(fā)工程中方方面面的基礎(chǔ)服務(wù)。

在基建之上是我們定義的容器層。我們嘗試用單一技術(shù)棧解決所有問題。但經(jīng)過我們的探索，覺得不太可能實現(xiàn)。好的架構(gòu)要匹配業(yè)務(wù)形態(tài)，業(yè)務(wù)的訴求決定了我們不能選擇唯一的技術(shù)棧去解決所有問題，細(xì)分外賣的業(yè)務(wù)場景可得到以下3個方向的頁面分類：

• 高PV主流程頁面，例如首頁、金剛頁、商家頁等，這類頁面的PV遠(yuǎn)高于其他頁面。這類頁面的特點是，交互強(qiáng)、曝光度高、多團(tuán)隊參與建設(shè)和維護(hù)。針對這類頁面，為了給用戶提供極致的體驗，是無法采用H5或RN實現(xiàn)的，即使性能上能夠滿足，但是這些頁面是多團(tuán)隊共同參與建設(shè)，如果用H5或RN實現(xiàn)，那么單一團(tuán)隊改動，都會造成全頁面受到無法預(yù)料的影響，其他未改動的業(yè)務(wù)方肯定是無法接受的。所以這類頁面，我們采用的是局部動態(tài)化+頁面模塊化的方案，我們針對頁面進(jìn)行容器化改造，將頁面變成容器，容器承載模塊。每個模塊歸不同的業(yè)務(wù)方進(jìn)行維護(hù)，從模塊的維度進(jìn)行解耦，每個模塊都可以動態(tài)配置和下發(fā)。
• 低PV輔助頁面，例如幫助、足跡、收藏等，這類頁面的PV低，但勝在數(shù)量多，都用原生實現(xiàn)成本比較高，如果都用H5來實現(xiàn)，不少頁面和原生的關(guān)聯(lián)還是比較近，不是非常適合。針對這類頁面，我們采用集團(tuán)提供的MRN基建去承載，MRN作為跨端的技術(shù)棧，我們已經(jīng)在之前的RN混合架構(gòu)的時候，建設(shè)了較為豐富的組件，針對自定義的MRN容器做了比較豐富的建設(shè)。同時，MRN具備動態(tài)下發(fā)的能力，滿足業(yè)務(wù)的訴求。

• 向外投放的運(yùn)營活動頁面，例如圣誕節(jié)活動，時效性比較強(qiáng)。這類頁面由H5技術(shù)棧去完成，一方面可以滿足時效性，另一方面H5的動態(tài)下發(fā)能力也是最強(qiáng)的，這樣的特性能夠充分的滿足業(yè)務(wù)的訴求。我們使用集團(tuán)提供的Titans基建，通過建設(shè)業(yè)務(wù)自定義的Titans容器，支撐業(yè)務(wù)的發(fā)展。

再往上，就是垂直的業(yè)務(wù)，外賣目前有流量業(yè)務(wù)、交易業(yè)務(wù)、商家業(yè)務(wù)、商品業(yè)務(wù)、廣告業(yè)務(wù)、營銷業(yè)務(wù)、閃購業(yè)務(wù)等。業(yè)務(wù)都是垂直向下依賴，直接可見容器，可見基建，能夠很好地獲取到各種已經(jīng)建設(shè)的能力去完成業(yè)務(wù)的需求。

最上面是承載的App端，目前有四端，包括外賣、點評、美團(tuán)、閃購等等。

右側(cè)是測試發(fā)布和線上監(jiān)控，相對于常規(guī)的移動端App架構(gòu)而言，容器化架構(gòu)的測試發(fā)布和監(jiān)控是更為精細(xì)化的。不僅僅要關(guān)注端本身的可用性，還需要關(guān)注容器、容器承載的模塊、模塊展示的模板，模板里面的樣式這些的可用性。

2.4 容器化的挑戰(zhàn)

容器化架構(gòu)相對常規(guī)的移動端架構(gòu)而言，它從管理移動端的代碼轉(zhuǎn)變成管理移動端的容器建設(shè)代碼和業(yè)務(wù)遠(yuǎn)端開發(fā)代碼，多出了容器和業(yè)務(wù)遠(yuǎn)端下發(fā)。這不僅僅是對技術(shù)上的挑戰(zhàn)，對長期做客戶端開發(fā)同學(xué)，也需要一個思維轉(zhuǎn)變的跳轉(zhuǎn)。

一致性的挑戰(zhàn)：容器需要在多個宿主應(yīng)用之中運(yùn)行，宿主應(yīng)用的環(huán)境一致性直接影響了容器的一致性。我們的策略是兩手準(zhǔn)備，一方面利用外賣業(yè)務(wù)的優(yōu)勢推動宿主應(yīng)用的環(huán)境對齊；另一方面將容器建設(shè)成SDK，通過SDK將長期保持容器的一致性，也通過SDK內(nèi)部的設(shè)計屏蔽應(yīng)用之間的差異；對于Android和iOS平臺，我們通過分層的設(shè)計，盡可能屏蔽平臺的差異。綜上所述，一致性的挑戰(zhàn)在于（1）容器運(yùn)行的宿主應(yīng)用的環(huán)境一致性；（2）不同應(yīng)用不同版本容器的一致性；（3）Android和iOS平臺容器的對業(yè)務(wù)的一致性。

動態(tài)發(fā)布的挑戰(zhàn)：長期以來，客戶端同學(xué)的開發(fā)概念里面只有App版本的概念，而當(dāng)我們逐漸把業(yè)務(wù)代碼做成遠(yuǎn)端下發(fā)時，將會新增一個線上動態(tài)發(fā)版的概念。當(dāng)我們在發(fā)布業(yè)務(wù)的時候，相對以往的工作，多出需要去考慮這個業(yè)務(wù)的版本，可以運(yùn)行的容器對應(yīng)的App上下界版本。另外，發(fā)版的周期也會新增業(yè)務(wù)的發(fā)版周期，不僅僅是App的發(fā)版周期。這兩者在一起將會產(chǎn)生新的火花，業(yè)務(wù)的版本和App的版本如何適配的問題，業(yè)務(wù)動態(tài)發(fā)版的周期和App的發(fā)版周期如何適配的問題。外賣這邊的解決方式是建設(shè)主版本迭代+周迭代的模型。

監(jiān)控運(yùn)維的挑戰(zhàn)：以往的移動端架構(gòu)，我們更加關(guān)注的是端本身的可用性，然而當(dāng)我們演進(jìn)到容器化架構(gòu)的時候，僅僅關(guān)注端的可用性已經(jīng)遠(yuǎn)遠(yuǎn)不能確定業(yè)務(wù)是可用的了。我們需要從端的可用性延伸出下載鏈路、加載鏈路，使用鏈路上的可用性，針對每個重要的環(huán)境，都做好監(jiān)控運(yùn)維。

3. 外賣跨端容器建設(shè)

3.1 MRN容器

3.1.1 MRN容器簡介

React Native框架本身只是一個運(yùn)行時環(huán)境中的渲染引擎，可以將同一套JS代碼分別在Android和iOS系統(tǒng)上最終以Native的方式渲染頁面，從而為App提供了基礎(chǔ)的跨端能力。但從工程化的角度來看，如果想在App中大規(guī)模地應(yīng)用RN技術(shù)，除了RN框架本身外，還需要在開發(fā)、構(gòu)建、測試、部署、運(yùn)維等諸多方面的配合。

MRN（Meituan React Native）是美團(tuán)基于React Native框架改造并完善而成的一套動態(tài)化方案，在RN的基礎(chǔ)上提供了容器化能力、動態(tài)化能力、多端復(fù)用能力和工程化保障。MRN在開發(fā)效率、穩(wěn)定性、性能體驗、動態(tài)化和監(jiān)控運(yùn)維等多方面進(jìn)行了能力升級和擴(kuò)展，滿足了美團(tuán)RN開發(fā)工程化的需要。目前，MRN已接入美團(tuán)40多個App，核心框架及生態(tài)工具有超過100位內(nèi)部代碼貢獻(xiàn)者，總PV超過4億。

3.1.2 Roo組件庫

下面再介紹一下外賣建設(shè)的兩個UI相關(guān)的技術(shù)項目，Roo組件庫和組件樣式動態(tài)配置。

• Roo組件庫：外賣在RN及MRN框架提供的UI組件基礎(chǔ)之上，又?jǐn)U展了適用于外賣業(yè)務(wù)的標(biāo)準(zhǔn)化UI組件庫。UI組件庫一方面統(tǒng)一了我們的設(shè)計規(guī)范和開發(fā)規(guī)范，提高了UI一致性；另一方面，組件封裝也提升了RN頁面的開發(fā)效率和質(zhì)量。
• 組件樣式動態(tài)配置：有了標(biāo)準(zhǔn)的Roo組件，我們進(jìn)一步給標(biāo)準(zhǔn)組件的動態(tài)添加了樣式動態(tài)配置能力。在使用組件時，很多樣式是支持動態(tài)下發(fā)的，例如字體、圓角、背景色等，方便我們進(jìn)行UI的適配和改版。

外賣在2018年底開始試驗MRN容器在外賣業(yè)務(wù)上的應(yīng)用，并在2019年上半年進(jìn)行了大面積的頁面落地。目前，外賣已有近60個RN頁面上線，占外賣頁面比例超80%，其中包括Tab頁面“我的”、提單選擇紅包頁、訂單評價頁等高PV頁面。MRN容器的接入，給外賣App的容器化、動態(tài)化、人效提升、包大小瘦身等方面都做出了不小的貢獻(xiàn)。

3.2 Titans容器

3.2.1 Titans容器簡介

Titans容器是美團(tuán)系A(chǔ)pp統(tǒng)一的Web容器組件，基于蘋果提供的WebView組件，將WebView容器化，統(tǒng)一了WebView的UI展示和交互方式，規(guī)范了橋協(xié)議的使用范式，同時預(yù)置了諸多基礎(chǔ)能力和業(yè)務(wù)能力。Titans容器大大提高了Web頁面的開發(fā)效率和用戶體驗上的一致性。

• Web容器 ：Titans容器提供了統(tǒng)一的UI展示和自定義樣式，例如導(dǎo)航欄樣式、頁面Loading狀態(tài)、進(jìn)度條樣式等；還有統(tǒng)一的交互方式，例如頁面跳轉(zhuǎn)、Scheme協(xié)議的解析等。
• KNB統(tǒng)一橋服務(wù) ：Web容器雖然在動態(tài)化和Android、iOS雙端復(fù)用上很好地彌補(bǔ)了Native的不足，但在很多地方體驗上又難以達(dá)到Native的標(biāo)準(zhǔn)。因此，KNB橋應(yīng)運(yùn)而生，KNB定義了Native和JS通信的標(biāo)準(zhǔn)方式，方便開發(fā)時進(jìn)行橋協(xié)議擴(kuò)展，同時KNB也內(nèi)置眾多的Native基礎(chǔ)能力，極大地提高了Titans容器的用戶體驗和開發(fā)效率。
• Web業(yè)務(wù)增強(qiáng)能力 ：Titans容器中預(yù)置了豐富的基礎(chǔ)業(yè)務(wù)頁面，例如登錄頁面、分享彈窗等。
• 提供鏈路增強(qiáng) ：提供了長連接、離線化等方式來提高網(wǎng)絡(luò)請求的速度和成功率。

• WebView預(yù)加載：在App啟動之后，用戶點擊網(wǎng)頁入口之前，提前加載好HTML主文檔和基礎(chǔ)庫，這樣當(dāng)用戶點擊頁面入口時，App直接使用已準(zhǔn)備好的WebView，僅需加載少量的業(yè)務(wù)代碼。從而達(dá)到白屏?xí)r間短、加載頁面迅速的效果。

Titans容器在外賣業(yè)務(wù)中的使用場景非常豐富，其中最重要的使用場景是各種運(yùn)營頁和活動頁，例如點擊首頁頂部Banner的廣告落地頁、為你優(yōu)選、限時秒殺等活動運(yùn)營頁等；還有客服頁、幫助反饋頁、商家入駐頁、美團(tuán)公益頁等功能性頁面；作為一級入口頁面的美團(tuán)會員頁面，也是一個基于Enlight的Titans容器。

4. 外賣頁面容器建設(shè)

外賣容器化建設(shè)，首先需要要區(qū)分的是核心頁面和非核心頁面。外賣業(yè)務(wù)中對核心頁面的定義是頁面DAU>美團(tuán)DAU的5%或者是下單關(guān)鍵路徑。為什么要先按照是否為核心頁面進(jìn)行拆分呢？重點就在于改造的成本。核心頁面的業(yè)務(wù)復(fù)雜度決定了它不容易做全頁面的動態(tài)化，它比較適合做局部的動態(tài)化方案。核心頁面的復(fù)雜度在于業(yè)務(wù)本身復(fù)雜，最重要的是核心頁面往往會有多個垂直業(yè)務(wù)團(tuán)隊共同的開發(fā)維護(hù)，大家各自有重點關(guān)注的模塊，做全頁面的動態(tài)化，無法做到有效的物理隔離。

而對于非核心頁面，業(yè)務(wù)功能和交互相對簡單，組織關(guān)系也較為確定，更適合做標(biāo)準(zhǔn)的MRN和Titans容器化。所以我們的策略是核心頁面做到支撐頁面模塊級別的業(yè)務(wù)動態(tài)和復(fù)用，非核心頁面可以做到頁面級別的動態(tài)化和復(fù)用。頁面容器化的核心含義就是把一個頁面劃分為若干個模塊，每個模塊成為一個業(yè)務(wù)容器，每個容器的填充既可以用Native的方式實現(xiàn)，也可以用Mach實現(xiàn)（Mach是外賣自研的頁面局部動態(tài)化技術(shù)），可以支持iOS/Android/小程序三端跨平臺運(yùn)行。頁面本身則化身為容器的管理者，負(fù)責(zé)子容器的編排和布局，并支持其動態(tài)化。

4.1 頁面容器化設(shè)計思路

頁面容器化設(shè)計中主要分為三個階段，模塊有序化、模塊編排化、漸進(jìn)式業(yè)務(wù)落地。

• 模塊有序化：將耦合的外賣業(yè)務(wù)代碼按模塊維度進(jìn)行拆分，建立標(biāo)準(zhǔn)化的模塊間組合和交互方案，降低模塊內(nèi)改動對其他模塊的影響。這個階段我們同時完成了Native原生模塊和局部動態(tài)化模塊的標(biāo)準(zhǔn)化改造。
• 模塊編排化：頁面容器化的一個特點是頁面具備編排模塊的能力，在這個階段我們在客戶端增加了對業(yè)務(wù)模塊結(jié)構(gòu)編排能力的支持，同時我們跟后端的同學(xué)共建了配置平臺，通過配置化的方式打通了AB實驗平臺、統(tǒng)一數(shù)據(jù)服務(wù)等多個平臺。在標(biāo)準(zhǔn)化的數(shù)據(jù)協(xié)議的支撐下，頁面支持了AB實驗動態(tài)上線，大大降低了客戶端在AB實驗方面的開發(fā)成本，做到了客戶端零成本，后端低成本，高效地支撐了外賣首頁六周年的大改版。

• 漸進(jìn)式業(yè)務(wù)落地：頁面容器化后最明顯的收益是支持業(yè)務(wù)需求的動態(tài)上線，只有頁面容器中的業(yè)務(wù)模塊具備動態(tài)能力才能實現(xiàn)這個目標(biāo)，這會涉及Native模塊遷移為Mach模塊的過程。在這個方面，我們的思路是跟隨業(yè)務(wù)需求漸進(jìn)式落地。在模塊編排階段，我們設(shè)計了Native模塊向Mach模塊遷移的能力，同時設(shè)計了覆蓋模板維度和API接口維度的三重降級方案，來保障模塊動態(tài)化遷移的穩(wěn)定性。

4.2 業(yè)務(wù)構(gòu)建模塊標(biāo)準(zhǔn)化

從App頁面開發(fā)的角度看，一個完整的頁面可以按照不同的功能及不同業(yè)務(wù)屬性劃分出多個不同的模塊。

業(yè)務(wù)構(gòu)建泛指由多個業(yè)務(wù)模塊組合拼裝為一個業(yè)務(wù)頁面的過程，涉及頁面本身（UIViewController/Activity）以及各個業(yè)務(wù)模塊的構(gòu)造過程，前后端業(yè)務(wù)數(shù)據(jù)以及頁面和業(yè)務(wù)模塊之間的數(shù)據(jù)交互過程，業(yè)務(wù)模塊內(nèi)部的數(shù)據(jù)處理以及視圖刷新流程。

模塊標(biāo)準(zhǔn)化指的將業(yè)務(wù)構(gòu)建涉及到的多個過程通過規(guī)范化的方式確定下來，形成唯一的標(biāo)準(zhǔn)。模塊標(biāo)準(zhǔn)化一方面能夠在解決業(yè)務(wù)共性問題的基礎(chǔ)上提供業(yè)務(wù)難點專項解決方案，另一方面能夠在框架基礎(chǔ)上形成能力約束，減少重復(fù)建設(shè)、低質(zhì)量建設(shè)的問題。

業(yè)務(wù)構(gòu)建模塊標(biāo)準(zhǔn)化中我們抽象了四層，下面將分別進(jìn)行解讀。

• 最底層是框架能力層，是外賣業(yè)務(wù)團(tuán)隊自研的符合外賣業(yè)務(wù)特點的雙端模塊化框架?？蚣芙鉀Q了不同頁面場景下的共性問題，對典型的業(yè)務(wù)痛點也進(jìn)行了支持。它是一種頁面框架設(shè)計在iOS、Android雙端對齊的實現(xiàn)方案，這種雙端對齊的能力為頁面容器化設(shè)計的雙端一致性提供了保障。

• 統(tǒng)一接口層是對框架能力層的標(biāo)準(zhǔn)化抽象，它可以保證任一模塊調(diào)用的能力在各個業(yè)務(wù)場景下的實現(xiàn)都是一致的，有了這一層抽象任一模塊都可以直接在各個場景下復(fù)用。

• 在往上就是App全局的模塊復(fù)用層，標(biāo)準(zhǔn)化后的模塊可以通過唯一標(biāo)示向模塊復(fù)用池注冊模塊，這種中心化的注冊方式可以讓業(yè)務(wù)模塊在跨業(yè)務(wù)庫的場景下可以靈活地復(fù)用。

• 最上層就是外賣的核心業(yè)務(wù)場景層，每一個場景都對應(yīng)了一個標(biāo)準(zhǔn)化的頁面容器，頁面容器通過實現(xiàn)容器化接口來完成頁面容器的構(gòu)建。

通過業(yè)務(wù)構(gòu)建模塊標(biāo)準(zhǔn)化的建設(shè)，業(yè)務(wù)模塊已經(jīng)是標(biāo)準(zhǔn)化的了，可以在跨頁面間自由組合，這為頁面容器化打下了基礎(chǔ)。

在頁面容器化中最基礎(chǔ)的能力有以下幾點：頁面中業(yè)務(wù)模塊可編排能力，動態(tài)上線前端AB實驗的能力，增量上線動態(tài)模塊的能力。實現(xiàn)這些能力最重要的就是進(jìn)行前后端數(shù)據(jù)協(xié)議標(biāo)準(zhǔn)化建設(shè)?？蛻舳烁鶕?jù)數(shù)據(jù)協(xié)議中的模塊唯一標(biāo)識匹配并構(gòu)造業(yè)務(wù)模塊，在完成模塊數(shù)據(jù)的填充后會根據(jù)數(shù)據(jù)協(xié)議中的模塊布局信息完成模塊的布局。針對Mach動態(tài)模塊，我們創(chuàng)建了基于模板ID的模塊匹配和數(shù)據(jù)填充流程，可以支持Mach動態(tài)模板的增量上線。在數(shù)據(jù)協(xié)議中針對前端AB實驗我們預(yù)留了AB實驗和通參字段，在數(shù)據(jù)填充階段通過容器化接口傳入動態(tài)模塊中，用于支持AB實驗的動態(tài)上線。

在容器化上線的過程中屬于接口的大版本升級，為了保證容器的高可用性，客戶端從模塊級別和API級別實現(xiàn)了兩套降級容災(zāi)方案。

模塊級別的降級方案主要針對Mach動態(tài)模塊，與Native模塊不同，Mach動態(tài)模塊需要預(yù)先下載動態(tài)模板才能正常地完成模塊的載入和渲染。為了保證動態(tài)模塊的加載成功率，我們一方面在接口上線前利用Eva（美團(tuán)內(nèi)部系統(tǒng)）對Mach模板的下載進(jìn)行預(yù)熱。另一方面，我們設(shè)計了動態(tài)模塊的主動降級方案，針對動態(tài)模塊的動態(tài)上線使用Native模塊進(jìn)行兜底降級，對于跟版動態(tài)模塊使用App內(nèi)置模板的方案進(jìn)行兜底降級。

API級別的容災(zāi)方案主要為了保障客戶端在新接口不穩(wěn)定的情況下可以自行降級到舊接口。針對這個問題，我們對線上老接口設(shè)計了數(shù)據(jù)結(jié)構(gòu)映射方案，在客戶端通過配置化的方式可以把老接口的數(shù)據(jù)結(jié)構(gòu)映射為新接口的數(shù)據(jù)結(jié)構(gòu)。這樣在上層業(yè)務(wù)無感知的情況下，可以做到容災(zāi)方案的上下線。

4.3 小結(jié)

通過頁面容器化，使得頁面只需要關(guān)心頁面級的構(gòu)造方式，而無需關(guān)心某一模塊內(nèi)部如何實現(xiàn)動態(tài)化的。把頁面與頁面的模塊分離，也符合目前外賣客戶端的組織結(jié)構(gòu)，有利于業(yè)務(wù)組間的協(xié)作。同時，頁面容器化使得外賣核心頁面具備了符合外賣業(yè)務(wù)場景下的動態(tài)能力，漸進(jìn)式把Native靜態(tài)模塊過渡到具備動態(tài)能力的模塊，從模塊的維度使整個頁面具備了動態(tài)能力。這種漸進(jìn)式的遷移方案把容器遷移跟業(yè)務(wù)模塊的遷移分隔開，大大降低了頁面容器化改造的風(fēng)險。

5. 外賣容器化架構(gòu)的衡量指標(biāo)

5.1 容器化架構(gòu)衡量指標(biāo)的特點

質(zhì)量和性能指標(biāo)是衡量我們App開發(fā)質(zhì)量和用戶體驗的重要依據(jù)，是我們一直都非常關(guān)注的重點數(shù)據(jù)。在非容器化時代，我們大多數(shù)的指標(biāo)都和App的使用環(huán)節(jié)緊密相關(guān)，因為在非容器化時代，邏輯鏈路相對簡單，例如我們打開一個新頁面時，我們首先創(chuàng)建頁面實例，然后發(fā)起網(wǎng)絡(luò)請求，同時頁面會經(jīng)歷一系列生命周期方法，最后渲染。這時我們可能會關(guān)注網(wǎng)絡(luò)請求的成功率和請求時間，頁面的渲染時間，和過成功是否發(fā)生Crash，這個過程相對更短暫，指標(biāo)更少，所以監(jiān)控起來也更容易。

外賣的容器化大大提升了外賣業(yè)務(wù)的復(fù)用能力、動態(tài)能力、模塊化和開發(fā)效率，但同時也帶來了更長的邏輯鏈路，鏈路從時間維度上劃分是：下載鏈路、加載鏈路、使用鏈路。例如我們在使用MRN容器的時候，會涉及到bundle的啟動下載或預(yù)熱下載，bundle解壓縮，MRN容器引擎初始化，bundle加載，JS的加載、執(zhí)行，頁面渲染等步驟，其中的每個步驟都可能存在性能問題和質(zhì)量風(fēng)險。因此，我們需要升級我們的衡量指標(biāo)系統(tǒng)來應(yīng)對容器化帶來的新的挑戰(zhàn)。

5.2 鏈路指標(biāo)

• 下載鏈路：在下載鏈路中下載容器所需的各種資源，在MRN和Mach中主要是bundle的下載任務(wù)，只有bundle下載成功，才能進(jìn)行后面的各項操作。所以bundle下載的成功率是下載鏈路中最重要的指標(biāo)，同時bundle下載的時機(jī)也很重要。外賣業(yè)務(wù)中有各種bundel上百個，如果在啟動時拉取所有bundle，對冷啟動時間會造成極大的影響。我們采用了bundle預(yù)熱的方法，發(fā)布bundle是給bundle打上相應(yīng)的Tag，在適當(dāng)?shù)臅r機(jī)去下載，避免集中下載。
• 加載鏈路：在加載鏈路中重要工作是對下載鏈路中下載的資源的解壓和解析。例如在用PGA加載頁面時，會進(jìn)行模塊的解析、模塊匹配、模塊降級、數(shù)據(jù)模型生成等步驟。在MRN中會進(jìn)行bundle解壓、引擎初始化、bundle加載等步驟。加載鏈路往往是比較消耗計算資源的步驟，對頁面打開和加載時間影響較大，所以我們會比較關(guān)注加載鏈路的性能指標(biāo)。

• 使用鏈路：使用鏈路和非容器化的使用階段基本相同，會主要關(guān)注頁面的加載時間、Crash率、頁面頁面FPS、頁面卡頓等指標(biāo)。除此之外，還會關(guān)注和容器本身特性相關(guān)的一些指標(biāo)，例如在MRN容器中，我們還會關(guān)注JS錯誤率、JS渲染時間、白屏率等指標(biāo)。

5.3 關(guān)鍵指標(biāo)

因為容器化的使用形成了一個串行的鏈路，所以如果某個關(guān)鍵節(jié)點失敗，會導(dǎo)致容器功能不可使用，關(guān)鍵指標(biāo)的任務(wù)就是從上述眾多的指標(biāo)當(dāng)中篩選出這些關(guān)鍵節(jié)點。例如在下載鏈路中bundle下載的成功率和API的成功率，加載鏈路中bundle加載的成功率和模塊匹配的成功率，下載或加載失敗都無法再進(jìn)行鏈路中的后續(xù)步驟，針對上面的成功率指標(biāo)，我們會添加分鐘級別的實時監(jiān)控告警，做到及時發(fā)現(xiàn)，快速響應(yīng)和緊急修復(fù)。

在使用鏈路中模塊渲染的成功率、Native Crash率、JS錯誤率也屬于關(guān)鍵指標(biāo)，這些任務(wù)的失敗也會導(dǎo)致容器的不可用，針對這些指標(biāo)我們也會采用實時監(jiān)控措施，并且添加降級手段，例如回滾bundle版本，或者把MRN和Mach容器降級為Native容器。

6. 外賣容器化架構(gòu)的監(jiān)控運(yùn)維

上面講到了容器化架構(gòu)的各項衡量指標(biāo)，那么把這些指標(biāo)具體落到實處的工作就是線上的運(yùn)維監(jiān)控工作。工欲善其事，必先利其器，對于監(jiān)控運(yùn)維工作，一定要有合適的監(jiān)控工具輔助配合才能事半功倍，公司內(nèi)有很多優(yōu)秀的監(jiān)控統(tǒng)計工具可供使用，這里的難點就是如何根據(jù)監(jiān)控的需要判斷選擇合適的工具。還有就是合理的劃分監(jiān)控維度和數(shù)據(jù)指標(biāo)的優(yōu)先級，例如對于能夠影響到鏈路穩(wěn)定性的關(guān)鍵指標(biāo)，我們需要做到分鐘級的監(jiān)控，一旦出現(xiàn)問題就能及時收到告警，對于非關(guān)鍵指標(biāo)，則通過生成日報的方式，方便開發(fā)者的統(tǒng)計和分析。

工具的使用上主要分為大盤工具、具體異常工具、灰度降級工具、告警工具等（以下是美團(tuán)內(nèi)部使用的工具）。

• 大盤工具：主要使用CAT、天網(wǎng)、Crash平臺等工具。這些工具收集、統(tǒng)計大盤數(shù)據(jù)，然后生成可視化的圖標(biāo)和曲線。方便開發(fā)者了解大盤的整體情況和變化趨勢。
• 具體異常工具：使用Sniffer、Logan等工具。這些工具可以用來獲取發(fā)生異常時的上下文和設(shè)備信息，回?fù)朴脩粜袨槿罩?，方便定位排查具體問題。
• 灰度降級工具：使用ABTest平臺、Horn等工具。用于下發(fā)配置，以進(jìn)行灰度控制或開關(guān)控制。

• 告警工具：告警小助手。將告警通過IM軟件及時發(fā)送到個人或群組，做到及時發(fā)現(xiàn)及時處理。

業(yè)務(wù)覆蓋維度監(jiān)控可以分為全局監(jiān)控和局部（單業(yè)務(wù)）監(jiān)控。

• 全局監(jiān)控：監(jiān)控各項容器化質(zhì)量指標(biāo)、性能指標(biāo)，生成每日報表，方便跟蹤監(jiān)控容器化的整體質(zhì)量。

• 局部（單業(yè)務(wù)）監(jiān)控：實時監(jiān)控每個頁面、每個容器的線上數(shù)據(jù)，做到有問題及時發(fā)現(xiàn)，及時定位，及時處理。

時間維度監(jiān)控：可以按天、小時、分鐘的時間維度。天級別的監(jiān)控主要是一些非關(guān)鍵路徑指標(biāo)，例如一些性能指標(biāo)，頁面加載時間、頁面FPS、JS渲染時間等，我們可以按天維度的生成數(shù)據(jù)報表，已郵件的數(shù)據(jù)發(fā)送日報。當(dāng)App灰度上線時，我們會開始小時級別的監(jiān)控，每過半小時通過IM軟件向廣播一些關(guān)鍵指標(biāo)，方便開發(fā)者跟蹤線上數(shù)據(jù)的穩(wěn)定性。分鐘級別的監(jiān)控則是針對關(guān)鍵指標(biāo)，觀察分鐘維度上的變化，如果關(guān)鍵指標(biāo)超過閾值，或者波動過大，就會及時產(chǎn)生告警。

下面我們以一個開發(fā)者的視角去看一下外賣容器化架構(gòu)的監(jiān)控運(yùn)維系統(tǒng)。從獲取信息的方式上可以分為主動查詢和被動推送，開發(fā)者可以通過監(jiān)控工具監(jiān)控全局和局部數(shù)據(jù)的變化趨勢，也可以分析具體異常Case；也可以從IM工具，郵件等收到相關(guān)的推送數(shù)據(jù)，以便及時響應(yīng)。在控制運(yùn)維上，開發(fā)者可以通過Eva、Horn等美團(tuán)內(nèi)部的灰度系統(tǒng)進(jìn)行灰度發(fā)布，當(dāng)灰度期發(fā)現(xiàn)問題的時候，可以及時地通過停止灰度，版本回滾，關(guān)閉入口的方式進(jìn)行降級容災(zāi)處理。

7. 外賣容器化架構(gòu)的發(fā)布能力

7.1 容器化架構(gòu)發(fā)布體系

容器化使外賣業(yè)務(wù)具備了強(qiáng)大的動態(tài)化能力，但動態(tài)化能力又和需要相應(yīng)的發(fā)布能力來支持，發(fā)布能力是我們業(yè)務(wù)開發(fā)質(zhì)量和效率的重要保障，也是我們?nèi)萜骰ㄔO(shè)工作過程中的重點環(huán)節(jié)，這一節(jié)主要介紹一下外賣容器化的發(fā)布能力。

從發(fā)布能力類型的角度看主要可以分為三種類型：（1）容器內(nèi)容的發(fā)布，包括發(fā)布整個頁面或者發(fā)布頁面中的局部模塊；（2）配置下發(fā)，通過API或其他配置平臺，下發(fā)布局協(xié)議、AB測試、樣式配置、功能配置、模板配置、容器配置等，大大提高了業(yè)務(wù)的靈活度和線上驗證能力；（3）灰度、降級下發(fā)，通過UUID，用戶畫像等信息做到灰度發(fā)布，降級回滾等控制能力。

從發(fā)布資源的的角度看主要分為兩種：一種是普通的資源，例如發(fā)布一個Web頁面，或者通過發(fā)布新版API來控制頁面局部容器的展示與否和展示的位置，同時我們也可以進(jìn)行一些AB Test操作；另一種是bundle資源，主要是針對MRN容器和Mach容器，每個MRN容器和Mach容器的資源都會先被打包成一個bundle，然后通過發(fā)布系統(tǒng)下發(fā)到終端，然后終端解析bundle中的代碼和資源，最終渲染頁面。

從發(fā)布階段的角度看，可以分為測試階段、上線階段、灰度階段和全量階段，其中上線階段是最終的環(huán)節(jié)，我們增加了很多校驗和保護(hù)手段來盡量保證上線操作的正確性。

7.2 跟版本發(fā)布流程

雖然我們具隨時備動態(tài)發(fā)布能力，但正常的版本迭代還是會存在中，所以外賣這邊的節(jié)奏是周動態(tài)迭代+雙周版本迭代，這保證了我們的開發(fā)工作有個一清晰的周期。在動態(tài)發(fā)布階段中最關(guān)鍵的階段操作上線階段。以MRN為例，目前外賣業(yè)務(wù)中應(yīng)有70多個bundle，再算上測試環(huán)境的bundle就有接近150個bundle，只是管理這些bundle就是一個復(fù)雜的工作，況且在進(jìn)行上線操作時還是涉及發(fā)布的目標(biāo)App、App版本的上下界、MRN版本的上下界等，一不小心就會造成操作失誤，所以進(jìn)行上線操作時需要非常謹(jǐn)慎。

我們針對操作上線階段進(jìn)行了事務(wù)流水線，通過流水線建立保護(hù)措施，一個bundle的上線要經(jīng)歷一個流水線的若干操作。首先，操作人根據(jù)上線SOP手冊進(jìn)行若干檢查操作，同時編寫標(biāo)準(zhǔn)格式的發(fā)布說明，然后周知相關(guān)核心人員后在操作系統(tǒng)上發(fā)起上線申請，Leader和QA收到申請后會進(jìn)行檢查并審批，審批通過后還要避開App使用的高峰期或節(jié)假日上線，上線后通過灰度發(fā)布觀察各項數(shù)據(jù)指標(biāo)，指標(biāo)正常后全量發(fā)布。

7.3 bundle資源發(fā)布

bundle是我們最常發(fā)布的資源類型，這里再結(jié)合發(fā)布工具講解一下bundle的發(fā)布過程。MRN和Mach都是以bundle的形式下發(fā)到設(shè)備終端的，我們在發(fā)布bundle的時候主要會用到兩個工具，打包工具Talos和發(fā)布工具Eva（美團(tuán)內(nèi)部工具）。一個bundle的工程文件主要由三個部分組成：配置文件、源代碼和資源文件，其中配置文件用于指導(dǎo)Talos對工程文件進(jìn)行打包，多個bundle可以共享一份配置文件。當(dāng)我們準(zhǔn)備發(fā)布一個bundle時，先找到該bundle在Talos的發(fā)布模板，選擇發(fā)布環(huán)境（測試或線上），然后進(jìn)行一鍵打包，然后Talos會進(jìn)行一系列流水線操作，包括Clone代碼、配置環(huán)境、進(jìn)行Lint檢查、構(gòu)建和上傳等。Talos打包完畢后將bundle上傳到Eva系統(tǒng)，然后Eva負(fù)責(zé)bundle的分包、上線、下線、灰度等操作，最終下發(fā)到終端設(shè)備上。

未來，我們還將引入美團(tuán)住宿的MRN-DevOps來進(jìn)一步的屏蔽當(dāng)前多系統(tǒng)的問題，降低整個周期管理的成本，特別是發(fā)布前的人工檢查成本，逐漸實現(xiàn)RD在一個平臺上操作從研發(fā)到發(fā)布運(yùn)維的所有實現(xiàn)。盡可能地減少人工成本，提升自動化。

7.4 多種發(fā)布能力綜合使用

上面介紹的是以bundle資源形式的發(fā)布流程，過程較為清晰簡單。下面再結(jié)合外賣首頁，介紹一下局部容器化的發(fā)布方式。外賣首頁是典型的流式列表，在局部容器化的架構(gòu)下，首頁就是由一個個矩形容器以ListView方式布局的，容器分兩種，Native容器和Mach容器，Mach容器是一個通用容器，我們可以編寫不同的樣式模板，下發(fā)到終端后交由通用Mach容器來渲染，以此達(dá)到只使用通用容器展示不同UI樣式的目的，這里涉及了Mach的發(fā)布系統(tǒng)。

首頁各子容器相當(dāng)于一塊塊積木，它們的位置排布、展示與否、模板的選擇等最終交由API控制，API具備了控制首頁布局，樣式展示的能力，而不再是單純的數(shù)據(jù)源。同時，首頁也涉及了AB能力、灰度降級策略等其實配置項下發(fā)系統(tǒng)?？梢钥吹酵赓u首頁的容器化是由多種發(fā)布能力配合支撐的，是外賣發(fā)布能力體系的“集大成者”。

8. 總結(jié)

好的架構(gòu)是要隨著業(yè)務(wù)的發(fā)展，不斷演變?nèi)ミm應(yīng)業(yè)務(wù)的發(fā)展。美團(tuán)外賣從一個很小規(guī)模，每日單量只有幾千的業(yè)務(wù)，逐漸地走到今天，每日單量峰值超過4000萬，組織架構(gòu)也從一個十幾個人的團(tuán)隊，逐漸發(fā)展到現(xiàn)在多角色、多垂直業(yè)務(wù)方向，上千人共同協(xié)作的團(tuán)隊。移動端上的架構(gòu)，為了適應(yīng)業(yè)務(wù)的發(fā)展要求，也經(jīng)歷了組件化、平臺化、RN混合化，再到現(xiàn)在向容器化的變遷。

容器化架構(gòu)相對于傳統(tǒng)的移動端架構(gòu)而言，充分地利用了現(xiàn)在的跨端技術(shù)，將動態(tài)化的能力最大化的賦予業(yè)務(wù)。通過動態(tài)化，帶來業(yè)務(wù)迭代周期縮短、編譯的加速、開發(fā)效率的提升等好處。同時，也解決了我們面臨著的多端復(fù)用、平臺能力、平臺支撐、單頁面多業(yè)務(wù)團(tuán)隊、業(yè)務(wù)動態(tài)訴求強(qiáng)等業(yè)務(wù)問題。

當(dāng)然，容器化架構(gòu)帶來好處的同時，對線上的可用性、容器的可用性、支撐業(yè)務(wù)的線上發(fā)布上提出了更加嚴(yán)格的要求。我們通過監(jiān)控下載、加載、使用鏈路上的可用性，來保障線上動態(tài)業(yè)務(wù)的可用性。針對容器，我們利用成熟的測試基建，建設(shè)容器的自動化測試來保障容器的可用性。針對發(fā)布，我們建設(shè)迭代流程，配合發(fā)布流水線，將線上的發(fā)布變得更為可控。

截止到目前為止，外賣業(yè)務(wù)經(jīng)過了幾十個動態(tài)化業(yè)務(wù)上線窗口，累積共發(fā)版百次以上。未來半年，我們還將進(jìn)一步從業(yè)務(wù)需求入手，將業(yè)務(wù)需求細(xì)分歸類，讓產(chǎn)品側(cè)逐漸建立容器和動態(tài)化需求的概念，能夠從源頭上，逐漸的將業(yè)務(wù)進(jìn)行劃分，最終使得每個業(yè)務(wù)需求，都可以歸類抽象成可以動態(tài)下發(fā)的業(yè)務(wù)和容器能力建設(shè)，從而進(jìn)一步的完善容器化架構(gòu)的能力和支持更多的的業(yè)務(wù)場景。

9. 參考資料

• React Native在美團(tuán)外賣客戶端的實踐

• 美團(tuán)外賣iOS多端復(fù)用的推動、支撐與思考

• 美團(tuán)外賣前端容器化演進(jìn)實踐

• UC瀏覽器客戶端容器化架構(gòu)演進(jìn)

• 你知道支付寶容器化架構(gòu)是怎么搭建的嗎？

• 講一講移動端跨平臺技術(shù)的演進(jìn)之路

• 盤點主流移動端跨平臺UI技術(shù)：實現(xiàn)原理、技術(shù)優(yōu)劣、橫向?qū)Ρ鹊?/span>

10. 作者簡介

郭賽，同同，徐宏，均為美團(tuán)外賣iOS工程師。