有門店的餐飲商家來說，只要味道能說的過去，能夠滿足時間、空間需求，那么訂餐就會很平常，對中型或酒店等單位更是趨于平常，同時還有訂桌、菜品預約、咨詢等需求，那么對餐飲商家來說，基于餐品展示訂餐小程序能夠實現什么效果呢？

通過雨科網小程序平臺制作餐品預約小程序，可以將所有菜品多規格展示到線上，用戶可以填寫信息預約或咨詢，商家后臺響應整理訂單操作，文章/視頻/音頻/圖文等形式滿足多種信息承載。

制作餐飲小程序覆蓋微信、百度、頭條、抖音、快手、支付寶平臺，讓商家在線上平臺可以高效獲客及經營，案例、環境、服務、價格等信息統統透明可查，便于商家分享也利于用戶搜索、直接觸達。

基于訂餐訂座小程序服務/餐品分類式呈現，用戶可快速找到所需服務，現成的餐飲小程序模板，替換修改內容快速完成制作，訪客信息查看及表單、留言、投票、優惠券、新人有禮等功能持續提升服務效率、促進客戶預約及線上發展。

現在就通過雨科網平臺制作餐飲訂餐訂座預約小程序吧。

原文：https://www.zcdly.com/cydcdzxcx.html

公眾號：雨科網

的架構要不斷演變，進而去適應業務的發展。美團在移動端上的架構，也經歷了組件化、平臺化、RN混合化，到現在開始向容器化變遷。容器化架構充分地利用了現在的跨端技術，將動態化的能力最大化地賦予了業務。

作為美團最為重要的業務之一，美團外賣移動端的架構演進是怎樣的呢？本文將為你揭開背后的思考、技術細節以及實踐。

中秋國慶雙節喜臨，美團技術團隊祝大家節日快樂~~

1. 背景

1.1 移動端跨平臺技術的介紹

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

1.1.1 WebView容器

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

1.1.2 React Native

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

1.1.3 Flutter

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

1.2 美團外賣業務介紹

作為中國領先的生活服務電子商務平臺，美團致力于用科技連接消費者和商家，提供服務以滿足人們日常“吃”的需求，并進一步擴展至多種生活和旅游服務。而作為公司最為重要的業務之一，美團外賣從2013年創建以來，已經從單一的品類擴展到附近美食、水果、蔬菜、超市、鮮花、蛋糕等多品類，從早午晚餐，發展到下午茶、宵夜，中餐、西餐、家常菜、小吃、快餐、海鮮、火鍋、川菜、蛋糕、烤肉、水果、飲料、甜點等多種類餐飲。美團外賣可以說是當前電商領域，最為復雜的業務之一。

業務的復雜，給系統架構也帶來了不小的挑戰。美團外賣業務之所以說是當前電商領域最為復雜的業務，主要源于以下幾點特征：

• 美團外賣業務承載在三個App上，美團外賣App、美團App外賣頻道、點評App外賣頻道。
• 美團外賣作為美團公司重要的用戶入口，還承擔著流量平臺的作用，提供平臺能力支撐頻道業務的發展，如閃購、跑腿、金融等。
• 美團外賣作為已經成熟的業務，需提供可復用的平臺能力，支撐新業務的發展，例如菜大全App的發展。
• 美團外賣作為一個超級業務方，業務內又運營多個方向業務，如流量業務、交易業務、商家業務、商品業務、營銷業務、廣告業務等。

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

1.3 美團外賣移動端歷史架構概述

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

1.3.1 組件化架構

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

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

此時，我們架構重構的目的，就是希望將各個子系統劃分為相對獨立的組件，建設組件可以直接復用，架構如下圖所示：

1.3.2 平臺化架構

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

1.3.3 RN混合架構

在平臺化架構之后，美團外賣功能持續增加，美團外賣客戶端安裝包的體積也在持續增加。回顧2017年和2018年，每年幾乎都增長100%。如果沒有一個有效的手段，安裝包將變得越發臃腫。另外，由于原生應用需要依托于應用市場進行更新，每次產品的更新，必須依賴用戶的主動更新，使得版本的迭代周期很長。業務上的這些痛點，不斷地督促我們去反思到底有沒有一種框架可以解決這些問題。

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

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

2. 美團外賣容器化架構全景圖

2.1 什么是容器化架構

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

容器化架構的愿景是：

• 希望將前端呈現業務的環境抽象出來，將能力進行標準化，形成統一的容器，通過容器去屏蔽平臺和端的差異。容器提供上層標準統一的能力接口，使得業務開發人員專注于容器內的業務邏輯的實現，最大復用已有的能力，而不用關注現在的環境是Android還是iOS，現在的端是美團App還是大眾點評App。
• 容器和遠端達成呈現協議，使得端上的內容具備隨時可變化的能力。容器化架構的實現是存在一定前提的，如果業務的發展本身處在一個探索階段，還有較多可變的因素，是無法形成穩定的能力層的，這時候建設容器化架構反而使得架構偏向復雜。但對于外賣業務場景來說，經過多年的沉淀固定，外賣業務逐漸形成了一套穩定的業務形態，已經進入到場景細分和快速迭代業務模塊的階段。在這樣的階段下，容器化架構才有可實施的前提。

2.2 容器化架構的優勢

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

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

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

2.3 外賣容器化架構全景圖

整個外賣容器化架構可以按照從下到上，從左到右的視角進行解讀：

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

系統服務之上是集團基于Native建設的基建，全公司通用，覆蓋了研發工程中方方面面的基礎服務。

在基建之上是我們定義的容器層。我們嘗試用單一技術棧解決所有問題。但經過我們的探索，覺得不太可能實現。好的架構要匹配業務形態，業務的訴求決定了我們不能選擇唯一的技術棧去解決所有問題，細分外賣的業務場景可得到以下3個方向的頁面分類：

• 高PV主流程頁面，例如首頁、金剛頁、商家頁等，這類頁面的PV遠高于其他頁面。這類頁面的特點是，交互強、曝光度高、多團隊參與建設和維護。針對這類頁面，為了給用戶提供極致的體驗，是無法采用H5或RN實現的，即使性能上能夠滿足，但是這些頁面是多團隊共同參與建設，如果用H5或RN實現，那么單一團隊改動，都會造成全頁面受到無法預料的影響，其他未改動的業務方肯定是無法接受的。所以這類頁面，我們采用的是局部動態化+頁面模塊化的方案，我們針對頁面進行容器化改造，將頁面變成容器，容器承載模塊。每個模塊歸不同的業務方進行維護，從模塊的維度進行解耦，每個模塊都可以動態配置和下發。
• 低PV輔助頁面，例如幫助、足跡、收藏等，這類頁面的PV低，但勝在數量多，都用原生實現成本比較高，如果都用H5來實現，不少頁面和原生的關聯還是比較近，不是非常適合。針對這類頁面，我們采用集團提供的MRN基建去承載，MRN作為跨端的技術棧，我們已經在之前的RN混合架構的時候，建設了較為豐富的組件，針對自定義的MRN容器做了比較豐富的建設。同時，MRN具備動態下發的能力，滿足業務的訴求。
• 向外投放的運營活動頁面，例如圣誕節活動，時效性比較強。這類頁面由H5技術棧去完成，一方面可以滿足時效性，另一方面H5的動態下發能力也是最強的，這樣的特性能夠充分的滿足業務的訴求。我們使用集團提供的Titans基建，通過建設業務自定義的Titans容器，支撐業務的發展。

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

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

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

2.4 容器化的挑戰

容器化架構相對常規的移動端架構而言，它從管理移動端的代碼轉變成管理移動端的容器建設代碼和業務遠端開發代碼，多出了容器和業務遠端下發。這不僅僅是對技術上的挑戰，對長期做客戶端開發同學，也需要一個思維轉變的跳轉。

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

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

監控運維的挑戰：以往的移動端架構，我們更加關注的是端本身的可用性，然而當我們演進到容器化架構的時候，僅僅關注端的可用性已經遠遠不能確定業務是可用的了。我們需要從端的可用性延伸出下載鏈路、加載鏈路，使用鏈路上的可用性，針對每個重要的環境，都做好監控運維。

3. 外賣跨端容器建設

3.1 MRN容器

3.1.1 MRN容器簡介

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

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

3.1.2 Roo組件庫

下面再介紹一下外賣建設的兩個UI相關的技術項目，Roo組件庫和組件樣式動態配置。

• Roo組件庫：外賣在RN及MRN框架提供的UI組件基礎之上，又擴展了適用于外賣業務的標準化UI組件庫。UI組件庫一方面統一了我們的設計規范和開發規范，提高了UI一致性；另一方面，組件封裝也提升了RN頁面的開發效率和質量。
• 組件樣式動態配置：有了標準的Roo組件，我們進一步給標準組件的動態添加了樣式動態配置能力。在使用組件時，很多樣式是支持動態下發的，例如字體、圓角、背景色等，方便我們進行UI的適配和改版。

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

3.2 Titans容器

3.2.1 Titans容器簡介

Titans容器是美團系App統一的Web容器組件，基于蘋果提供的WebView組件，將WebView容器化，統一了WebView的UI展示和交互方式，規范了橋協議的使用范式，同時預置了諸多基礎能力和業務能力。Titans容器大大提高了Web頁面的開發效率和用戶體驗上的一致性。

• Web容器：Titans容器提供了統一的UI展示和自定義樣式，例如導航欄樣式、頁面Loading狀態、進度條樣式等；還有統一的交互方式，例如頁面跳轉、Scheme協議的解析等。
• KNB統一橋服務：Web容器雖然在動態化和Android、iOS雙端復用上很好地彌補了Native的不足，但在很多地方體驗上又難以達到Native的標準。因此，KNB橋應運而生，KNB定義了Native和JS通信的標準方式，方便開發時進行橋協議擴展，同時KNB也內置眾多的Native基礎能力，極大地提高了Titans容器的用戶體驗和開發效率。
• Web業務增強能力：Titans容器中預置了豐富的基礎業務頁面，例如登錄頁面、分享彈窗等。
• 提供鏈路增強：提供了長連接、離線化等方式來提高網絡請求的速度和成功率。
• WebView預加載：在App啟動之后，用戶點擊網頁入口之前，提前加載好HTML主文檔和基礎庫，這樣當用戶點擊頁面入口時，App直接使用已準備好的WebView，僅需加載少量的業務代碼。從而達到白屏時間短、加載頁面迅速的效果。

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

4. 外賣頁面容器建設

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

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

4.1 頁面容器化設計思路

頁面容器化設計中主要分為三個階段，模塊有序化、模塊編排化、漸進式業務落地。

• 模塊有序化：將耦合的外賣業務代碼按模塊維度進行拆分，建立標準化的模塊間組合和交互方案，降低模塊內改動對其他模塊的影響。這個階段我們同時完成了Native原生模塊和局部動態化模塊的標準化改造。
• 模塊編排化：頁面容器化的一個特點是頁面具備編排模塊的能力，在這個階段我們在客戶端增加了對業務模塊結構編排能力的支持，同時我們跟后端的同學共建了配置平臺，通過配置化的方式打通了AB實驗平臺、統一數據服務等多個平臺。在標準化的數據協議的支撐下，頁面支持了AB實驗動態上線，大大降低了客戶端在AB實驗方面的開發成本，做到了客戶端零成本，后端低成本，高效地支撐了外賣首頁六周年的大改版。
• 漸進式業務落地：頁面容器化后最明顯的收益是支持業務需求的動態上線，只有頁面容器中的業務模塊具備動態能力才能實現這個目標，這會涉及Native模塊遷移為Mach模塊的過程。在這個方面，我們的思路是跟隨業務需求漸進式落地。在模塊編排階段，我們設計了Native模塊向Mach模塊遷移的能力，同時設計了覆蓋模板維度和API接口維度的三重降級方案，來保障模塊動態化遷移的穩定性。

4.2 業務構建模塊標準化

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

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

模塊標準化指的將業務構建涉及到的多個過程通過規范化的方式確定下來，形成唯一的標準。模塊標準化一方面能夠在解決業務共性問題的基礎上提供業務難點專項解決方案，另一方面能夠在框架基礎上形成能力約束，減少重復建設、低質量建設的問題。

業務構建模塊標準化中我們抽象了四層，下面將分別進行解讀。

• 最底層是框架能力層，是外賣業務團隊自研的符合外賣業務特點的雙端模塊化框架。框架解決了不同頁面場景下的共性問題，對典型的業務痛點也進行了支持。它是一種頁面框架設計在iOS、Android雙端對齊的實現方案，這種雙端對齊的能力為頁面容器化設計的雙端一致性提供了保障。
• 統一接口層是對框架能力層的標準化抽象，它可以保證任一模塊調用的能力在各個業務場景下的實現都是一致的，有了這一層抽象任一模塊都可以直接在各個場景下復用。
• 在往上就是App全局的模塊復用層，標準化后的模塊可以通過唯一標示向模塊復用池注冊模塊，這種中心化的注冊方式可以讓業務模塊在跨業務庫的場景下可以靈活地復用。
• 最上層就是外賣的核心業務場景層，每一個場景都對應了一個標準化的頁面容器，頁面容器通過實現容器化接口來完成頁面容器的構建。

通過業務構建模塊標準化的建設，業務模塊已經是標準化的了，可以在跨頁面間自由組合，這為頁面容器化打下了基礎。

在頁面容器化中最基礎的能力有以下幾點：頁面中業務模塊可編排能力，動態上線前端AB實驗的能力，增量上線動態模塊的能力。實現這些能力最重要的就是進行前后端數據協議標準化建設。客戶端根據數據協議中的模塊唯一標識匹配并構造業務模塊，在完成模塊數據的填充后會根據數據協議中的模塊布局信息完成模塊的布局。針對Mach動態模塊，我們創建了基于模板ID的模塊匹配和數據填充流程，可以支持Mach動態模板的增量上線。在數據協議中針對前端AB實驗我們預留了AB實驗和通參字段，在數據填充階段通過容器化接口傳入動態模塊中，用于支持AB實驗的動態上線。

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

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

API級別的容災方案主要為了保障客戶端在新接口不穩定的情況下可以自行降級到舊接口。針對這個問題，我們對線上老接口設計了數據結構映射方案，在客戶端通過配置化的方式可以把老接口的數據結構映射為新接口的數據結構。這樣在上層業務無感知的情況下，可以做到容災方案的上下線。

4.3 小結

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

5. 外賣容器化架構的衡量指標

5.1 容器化架構衡量指標的特點

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

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

5.2 鏈路指標

• 下載鏈路：在下載鏈路中下載容器所需的各種資源，在MRN和Mach中主要是bundle的下載任務，只有bundle下載成功，才能進行后面的各項操作。所以bundle下載的成功率是下載鏈路中最重要的指標，同時bundle下載的時機也很重要。外賣業務中有各種bundel上百個，如果在啟動時拉取所有bundle，對冷啟動時間會造成極大的影響。我們采用了bundle預熱的方法，發布bundle是給bundle打上相應的Tag，在適當的時機去下載，避免集中下載。
• 加載鏈路：在加載鏈路中重要工作是對下載鏈路中下載的資源的解壓和解析。例如在用PGA加載頁面時，會進行模塊的解析、模塊匹配、模塊降級、數據模型生成等步驟。在MRN中會進行bundle解壓、引擎初始化、bundle加載等步驟。加載鏈路往往是比較消耗計算資源的步驟，對頁面打開和加載時間影響較大，所以我們會比較關注加載鏈路的性能指標。
• 使用鏈路：使用鏈路和非容器化的使用階段基本相同，會主要關注頁面的加載時間、Crash率、頁面頁面FPS、頁面卡頓等指標。除此之外，還會關注和容器本身特性相關的一些指標，例如在MRN容器中，我們還會關注JS錯誤率、JS渲染時間、白屏率等指標。

5.3 關鍵指標

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

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

6. 外賣容器化架構的監控運維

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

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

• 大盤工具：主要使用CAT、天網、Crash平臺等工具。這些工具收集、統計大盤數據，然后生成可視化的圖標和曲線。方便開發者了解大盤的整體情況和變化趨勢。
• 具體異常工具：使用Sniffer、Logan等工具。這些工具可以用來獲取發生異常時的上下文和設備信息，回撈用戶行為日志，方便定位排查具體問題。
• 灰度降級工具：使用ABTest平臺、Horn等工具。用于下發配置，以進行灰度控制或開關控制。
• 告警工具：告警小助手。將告警通過IM軟件及時發送到個人或群組，做到及時發現及時處理。

業務覆蓋維度監控可以分為全局監控和局部（單業務）監控。

• 全局監控：監控各項容器化質量指標、性能指標，生成每日報表，方便跟蹤監控容器化的整體質量。
• 局部（單業務）監控：實時監控每個頁面、每個容器的線上數據，做到有問題及時發現，及時定位，及時處理。

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

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

7. 外賣容器化架構的發布能力

7.1 容器化架構發布體系

容器化使外賣業務具備了強大的動態化能力，但動態化能力又和需要相應的發布能力來支持，發布能力是我們業務開發質量和效率的重要保障，也是我們容器化建設工作過程中的重點環節，這一節主要介紹一下外賣容器化的發布能力。

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

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

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

7.2 跟版本發布流程

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

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

7.3 bundle資源發布

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

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

7.4 多種發布能力綜合使用

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

首頁各子容器相當于一塊塊積木，它們的位置排布、展示與否、模板的選擇等最終交由API控制，API具備了控制首頁布局，樣式展示的能力，而不再是單純的數據源。同時，首頁也涉及了AB能力、灰度降級策略等其實配置項下發系統。可以看到外賣首頁的容器化是由多種發布能力配合支撐的，是外賣發布能力體系的“集大成者”。

8. 總結

好的架構是要隨著業務的發展，不斷演變去適應業務的發展。美團外賣從一個很小規模，每日單量只有幾千的業務，逐漸地走到今天，每日單量峰值超過4000萬，組織架構也從一個十幾個人的團隊，逐漸發展到現在多角色、多垂直業務方向，上千人共同協作的團隊。移動端上的架構，為了適應業務的發展要求，也經歷了組件化、平臺化、RN混合化，再到現在向容器化的變遷。

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

當然，容器化架構帶來好處的同時，對線上的可用性、容器的可用性、支撐業務的線上發布上提出了更加嚴格的要求。我們通過監控下載、加載、使用鏈路上的可用性，來保障線上動態業務的可用性。針對容器，我們利用成熟的測試基建，建設容器的自動化測試來保障容器的可用性。針對發布，我們建設迭代流程，配合發布流水線，將線上的發布變得更為可控。

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

9. 參考資料

• React Native在美團外賣客戶端的實踐
• 美團外賣iOS多端復用的推動、支撐與思考
• 美團外賣前端容器化演進實踐
• UC瀏覽器客戶端容器化架構演進
• 你知道支付寶容器化架構是怎么搭建的嗎？
• 講一講移動端跨平臺技術的演進之路
• 盤點主流移動端跨平臺UI技術：實現原理、技術優劣、橫向對比等

10. 作者簡介

郭賽，同同，徐宏，均為美團外賣iOS工程師。

---------- END ----------

招聘信息

美團外賣長期招聘Android、iOS、FE高級/資深工程師和技術專家，感興趣的同學可投遞簡歷至：tech@meituan.com（郵件標題請注明：美團外賣）。

數字化時代，外賣服務已經成為校園生活的重要組成部分。隨著智能手機的普及和互聯網技術的發展，校園外賣小程序系統的出現更是改變了傳統外賣模式的格局。本文將為你詳細解析如何從零到一構建一個高效的校園外賣小程序系統。

一、需求分析與規劃

首先，要明確校園外賣小程序系統的用戶需求，包括學生、餐廳和配送員等角色。學生需要方便的下單、支付和查看訂單進程等功能；餐廳需要接單、處理訂單、烹飪、配送等功能；配送員需要接收訂單、配送、確認收貨等功能。

二、技術選型與準備

基于需求，我們需要選擇合適的技術棧來開發校園外賣小程序系統。推薦使用微信小程序開發框架，結合JavaScript、CSS和HTML等前端技術進行開發。在后端，可以使用Node.js、Python等語言和框架，實現數據處理、接口服務等。同時，為了保證系統的穩定性和擴展性，還需進行技術準備，如服務器部署、數據庫設計等。

三、界面設計

為了滿足用戶需求，界面設計應簡潔明了、易于操作。在設計過程中，需要考慮各個角色的用戶體驗，如學生、餐廳和配送員等。此外，還需考慮小程序的響應速度和兼容性，確保在不同設備和網絡環境下的良好體驗。

四、數據庫設計

數據庫是校園外賣小程序系統的核心，需要合理設計數據庫結構以實現數據的存儲、讀取和更新等操作。針對不同的業務需求，需要建立相應的數據表，并定義合適的數據類型和字段長度等。同時，為了保證數據的完整性，需要進行事務處理和數據備份。

五、功能實現與測試

根據需求分析和技術準備，可以開始實現校園外賣小程序系統的各個功能模塊。在實現過程中，要注重代碼的可讀性和可維護性，同時要保證系統的性能和安全性。測試是確保系統質量的重要環節，包括單元測試、集成測試和系統測試等。在測試過程中，要發現和修復潛在的問題和缺陷，確保系統的穩定性和可用性。

六、上線與運營

經過測試后，可以正式發布校園外賣小程序系統。為了吸引用戶和提高使用率，需要進行有效的推廣和運營。可以通過線上和線下宣傳、推出優惠活動等方式來吸引用戶。同時，要持續關注用戶反饋和需求變化，及時進行系統更新和維護。

總結：

本文從需求分析、技術選型、界面設計、數據庫設計、功能實現與測試等方面詳細解析了如何從零到一構建一個高效的校園外賣小程序系統。通過合理的規劃和設計，可以開發出一款滿足用戶需求、性能優良、安全可靠的外賣小程序，為校園生活帶來便利和便捷。