架構小談之美團外賣

美團外賣，你們都很熟悉，與咱們的生活已經緊密相連了。今天有機會讀到了關於美團外賣架構的文章。都說戰勝方便麪企業的不是另外一家方便麪企業，而是先在的互聯網外賣公司，下面，根據本身讀了美團外賣框架介紹，談一談本身的美團外賣框架的一些認識。

美團外賣自2013年建立以來，業務一直高速發展。目前美團外賣日完成訂單量已突破1800萬，成爲美團點評最重要的業務之一。美團外賣的用戶端入口，從單一的外賣獨立App，拓展爲外賣、美團、點評等多個App入口。美團外賣所承載的業務，也從單一的餐飲業務，發展到餐飲、超市、生鮮、果蔬、藥品、鮮花、蛋糕、跑腿等十多個大品類業務。業務的快速發展對客戶端架構不斷提出新的挑戰。

很早以前，外賣做爲孵化中的項目只有美團外賣App（下文簡稱外賣App）一個入口，後來外賣做爲一個子頻道接入到美團App（下文簡稱外賣頻道），兩端業務並行迭代開發。早期爲了快速上線，開發同窗直接將外賣App的代碼拷貝出一份到外賣頻道，作了簡單的適配就很快接入到美團App了。

早期外賣App和外賣頻道由兩個團隊分別維護，而在隨後一段時間裏，兩端代碼體系差別愈來愈來大。最後演變成了從網絡、圖片等基礎庫到UI控件、類的命名等都不盡相同的兩套代碼。儘管後來兩個團隊合併到一塊兒，但歷史的差別已經造成，爲了優先知足業務需求，很長一段時間內，咱們只能在兩套代碼的基礎上不斷堆積更多的功能。維護兩套代碼的成本可想而知，而業務的迅猛發展又使得這一問題愈加不可忍受。

 

好的架構源於不停地衍變，而非設計。對於外賣Android客戶端的平臺化架構構建也是經歷了一樣的過程。咱們從考慮如何解決代碼複用的問題，逐漸的衍變成如何去解決代碼複用和平臺化的兩個問題。而實際上外賣平臺化正是解決兩端代碼複用的一劑良藥。咱們經過創建外賣平臺，將現有的外賣業務降級爲一個頻道，將外賣業務以aar的形式分別接入到外賣平臺和美團平臺，這樣在解決外賣平臺化的同時，代碼複用的問題也將獲得完美的解決。

平臺化架構

通過了整整一年的艱苦奮鬥，造成了如圖所示的美團外賣Android客戶端平臺化架構：
從底層到高層依次爲平臺層、業務層和宿主層。

1. 平臺層的內容包括，承載上層的數據通訊和頁面跳轉；提供外賣核心服務，例如商品管理、訂單管理、購物車管理等；提供配置管理服務；提供統一的基礎設施能力，例如網絡、圖片、監控、報警、定位、分享、熱修、埋點、Crash上報等；提供其餘管理能力，例如生命週期管理、組件化等。
2. 業務層的內容包括，外賣業務和垂直業務。
3. 宿主層的內容包括，Waimai App殼和美團外賣頻道Waimai-channel殼，這一層用於Application的初始化、dex加載和其餘各類必要的組件或基礎庫的初始化。

在構建平臺化架構的過程當中，咱們遇到這樣一個問題，如何長久的維持咱們平臺化架構的層級邊界。試想，若是全部的代碼都在一個工程裏面開發，經過包名、約定去規範層級邊界，任何一個緊急的需求均可能破壞層級邊界。維持層級邊界的最好辦法是什麼？咱們的經驗是工程隔離。平臺化的每一層都去作工程隔離，業務層的每一個業務都創建本身的工程庫，實現工程隔離。同時，配套編譯腳本，檢查業務庫之間是否存在相互依賴關係。工程隔離的好處是顯而易見的：

1. 每一個工程均可以獨立編譯、獨立打包；
2. 每一個工程內部的修改，不會影響其餘工程；
3. 業務庫工程能夠快速拆分出來，集成到其餘App中。

但工程隔離帶來的另外一個問題是，同層間的業務庫須要通訊怎麼辦？這時候就須要提供業務庫通訊框架來解決這個問題。

業務庫通訊框架