美團(tuán)外賣IT系統(tǒng)架構(gòu)演進(jìn)

1、 美團(tuán)外賣IT系統(tǒng)架構(gòu)演進(jìn)作為日千萬訂單級(jí)別的業(yè)務(wù)，美團(tuán)外賣的后端服務(wù)是怎么支撐的？寫在前面 2018年4月，中國(guó)外賣市場(chǎng)迎來巨變，外賣從無人問津開始，到現(xiàn)在已經(jīng)培育成互聯(lián)網(wǎng)巨頭必爭(zhēng)之地。作為為數(shù)不多能夠達(dá)到日千萬訂單級(jí)別的業(yè)務(wù)，其后端服務(wù)是怎么支撐的？InfoQ采訪了ArchSummit出品人、美團(tuán)點(diǎn)評(píng)技術(shù)總監(jiān)方建平，請(qǐng)他回顧及展望美團(tuán)外賣的后端架構(gòu)史，本文根據(jù)采訪整理而成。美團(tuán)外賣后端架構(gòu)迭代各階段 美團(tuán)外賣發(fā)展到今天差不多有 4 年多的時(shí)間，按照外賣業(yè)務(wù)發(fā)展的幾個(gè)特征，可以相應(yīng)地把外賣技術(shù)分成三個(gè)主要階段：第一階段：業(yè)務(wù)初探期大約截止到 2015 年初，持續(xù)差不多一年左右的時(shí)間。這個(gè)階段

2、的主要特征就是美團(tuán)對(duì)于外賣的業(yè)務(wù)還處于市場(chǎng)摸索期，研發(fā)人員相對(duì)也比較少，差不多 10 來個(gè)同學(xué)，產(chǎn)品上需要快速迭代、試錯(cuò)。所以這個(gè)階段的系統(tǒng)架構(gòu)比較簡(jiǎn)單，就是典型的單系統(tǒng) Web 應(yīng)用服務(wù)，主要是需要滿足產(chǎn)品需求上的快速上線，驗(yàn)證業(yè)務(wù)模型的市場(chǎng)可行性。第二階段：業(yè)務(wù)爆發(fā)期外賣業(yè)務(wù)在 2015 年初開始了爆發(fā)式增長(zhǎng)?；诋?dāng)前外賣的業(yè)務(wù)特性，90% 以上的交易都是在午高峰和晚高峰這個(gè)期間完成的，對(duì)業(yè)務(wù)系統(tǒng)來說高峰期負(fù)載重，壓力大。這個(gè)階段，我們主要是從最早期的基于單系統(tǒng)的 Web 應(yīng)用架構(gòu)，向分布式服務(wù)架構(gòu)的遷移改造。期間主要優(yōu)化工作如下：一、做架構(gòu)的拆分，應(yīng)對(duì)高并發(fā)、保證高性能對(duì)系統(tǒng)的拆分，主要

3、體現(xiàn)在系統(tǒng)服務(wù)層、以及數(shù)據(jù)存儲(chǔ)層上。通過對(duì)線上業(yè)務(wù)流程的分解，將外賣系統(tǒng)分成數(shù)據(jù)瀏覽體系、用戶訂單交易體系、商戶接單配送體系、用戶信息 UGC 服務(wù)等，同時(shí)也針對(duì)大的業(yè)務(wù)服務(wù)體系內(nèi)的流量分布、以及功能差異性，再做進(jìn)一步的拆解。比如瀏覽體系中會(huì)有門店服務(wù)、商品服務(wù)、搜索推薦服務(wù)等等。針對(duì)并發(fā)的讀寫數(shù)據(jù)壓力，我們也針對(duì)性地搭建了相應(yīng)的分布式緩存服務(wù)、針對(duì)特定數(shù)據(jù)庫表，例如訂單表，也進(jìn)行了基于訂單 ID、門店 ID、用戶 ID 等多個(gè)維度的拆庫、拆表操作。二、構(gòu)建系統(tǒng)化運(yùn)維體系，保障服務(wù)高可用分布式系統(tǒng)拆分，提升了外賣服務(wù)的并發(fā)處理能力，同時(shí)也給線上運(yùn)維帶來了負(fù)擔(dān)。需要對(duì)線上近百個(gè)服務(wù)應(yīng)用、幾千臺(tái)機(jī)

4、器資源進(jìn)行運(yùn)維管理，才能保證整個(gè)業(yè)務(wù)鏈路服務(wù)的穩(wěn)定體驗(yàn)。這個(gè)期間，我們?cè)跇I(yè)務(wù)系統(tǒng)的可運(yùn)維方面，做了大量的工作。例如：通過完整業(yè)務(wù)鏈路的梳理，形成關(guān)聯(lián)各服務(wù)接口的 SLA，保障核心鏈路的穩(wěn)定 ;通過定期的全鏈路壓測(cè)，驗(yàn)證各子系統(tǒng)的處理極限，合理規(guī)劃系統(tǒng)容量；通過鏈路故障模擬演練，驗(yàn)證各服務(wù)系統(tǒng)在功能層面、系統(tǒng)層面的故障降級(jí)處理能力第三階段：業(yè)務(wù)擴(kuò)展期這個(gè)期間是伴隨著業(yè)務(wù)爆發(fā)期逐步開始的。外賣的業(yè)務(wù)中，除了傳統(tǒng)的餐飲品類外，還逐步提供了鮮花、生鮮、果蔬、商超、以及跑腿服務(wù)等業(yè)務(wù)的擴(kuò)展。7 月 6-9 日，我除了在 ArchSummit 深圳站上擔(dān)任大型分布式系統(tǒng)架構(gòu)出品人，也會(huì)現(xiàn)場(chǎng)分享美團(tuán)外賣這個(gè)

5、階段在服務(wù)端的架構(gòu)迭代，包括數(shù)據(jù)處理上的技巧經(jīng)驗(yàn)，這里簡(jiǎn)單總結(jié)下：業(yè)務(wù)擴(kuò)展期階段外賣業(yè)務(wù)和產(chǎn)品，我們期望以最小的代價(jià)，支持不同品類的差異性服務(wù)，能夠在當(dāng)前的系統(tǒng)中快速上線。對(duì)技術(shù)來說，就需要將系統(tǒng)由業(yè)務(wù)的功能化向業(yè)務(wù)的平臺(tái)化方向發(fā)展。我們通過對(duì)通用電商邏輯的抽取，形成公共服務(wù)平臺(tái)，將差異性的品類業(yè)務(wù)特性，通過系統(tǒng)插件或者流程配置的方式，集成到公共服務(wù)平臺(tái)上，以達(dá)到整個(gè)鏈路的整合復(fù)用。例如：將訂單交易流程通過類似工作流引擎的方式，針對(duì)不同的品類，配置不同的流程模板，使其能夠靈活的運(yùn)行在整個(gè)外賣的核心交易體系之中；商家促銷活動(dòng)平臺(tái)，支持從門店、商品、區(qū)域等等不同品類進(jìn)行各種活動(dòng)配置，滿足不同品類的

6、營(yíng)銷需求。美團(tuán)外賣后端新項(xiàng)目 當(dāng)前美團(tuán)外賣業(yè)務(wù)依然處于持續(xù)增長(zhǎng)期，年前我們的日訂單剛突破了 1800 多萬。伴隨著業(yè)務(wù)的發(fā)展，基于業(yè)務(wù)背后的技術(shù)系統(tǒng)也日趨復(fù)雜。無論是對(duì)于機(jī)器資源規(guī)模，還是系統(tǒng)服務(wù)之間的調(diào)度關(guān)聯(lián)，都對(duì)線上服務(wù)的運(yùn)維帶來很大的挑戰(zhàn)。為保證外賣線上服務(wù)規(guī)模的可擴(kuò)展和可運(yùn)維，近期我們正在開展兩大項(xiàng)目：一個(gè)是外賣的 Set 化部署項(xiàng)目、另一個(gè)是智能化業(yè)務(wù)運(yùn)維系統(tǒng)建設(shè)。外賣 Set 化部署項(xiàng)目這個(gè)項(xiàng)目的目標(biāo)是為了解決外賣當(dāng)前大數(shù)據(jù)、高并發(fā)場(chǎng)景下的機(jī)房集群資源規(guī)模限制問題。我們希望將用戶與商家的大規(guī)模請(qǐng)求流量，按照特定的規(guī)則，拆分到不同 Set 內(nèi)，同時(shí)在 Set 內(nèi)做到整個(gè)用戶交易流程的

7、閉環(huán)。這樣我們并可以通過可控容量大小的 Set 劃分，達(dá)到分散系統(tǒng)壓力，快速支持?jǐn)U容的能力。Set 化不是一項(xiàng)新技術(shù)，當(dāng)前業(yè)界也有部分公司已經(jīng)在線上實(shí)施了，我們計(jì)劃 2018 年下半年進(jìn)入部署狀態(tài)。這塊涉及到的基礎(chǔ)服務(wù)改造，應(yīng)用服務(wù)改造非常多，我想等我們上線后，可以總結(jié)下經(jīng)驗(yàn)，再來給大家詳細(xì)分享下。外賣智能化業(yè)務(wù)運(yùn)維建設(shè)項(xiàng)目在美團(tuán)外賣的穩(wěn)定性建設(shè)過程中，我們希望通過一套智能化運(yùn)維系統(tǒng)，幫助快速、準(zhǔn)確地識(shí)別各鏈路子系統(tǒng)服務(wù)異常，發(fā)現(xiàn)問題根因，并自動(dòng)執(zhí)行對(duì)應(yīng)的異常解決預(yù)案，從而避免或減少線上事故影響。當(dāng)前業(yè)界關(guān)于 AIOps 這塊的探索也有很多，我們也在同步的跟進(jìn)摸索中，目前主要還處于基礎(chǔ)性建設(shè)期

8、間，包括核心鏈路的故障演練系統(tǒng)、全鏈路壓測(cè)系統(tǒng)、告警分析診斷系統(tǒng)，服務(wù)自保護(hù)系統(tǒng)等等。高并發(fā)應(yīng)對(duì)策略 這里簡(jiǎn)單介紹下我們的高峰低谷策略、動(dòng)態(tài)調(diào)度設(shè)計(jì)、目前的瓶頸，以及我們的優(yōu)先級(jí)策略。高峰低谷策略 針對(duì)當(dāng)前外賣的周期性峰值波動(dòng)特性，我們的主要采取如下幾個(gè)策略：系統(tǒng)基礎(chǔ)運(yùn)行能力的適度冗余外賣系統(tǒng)在系統(tǒng)架構(gòu)的設(shè)計(jì)上，無論是在服務(wù)層面系統(tǒng)部署，還是數(shù)據(jù)層面的存儲(chǔ)資源都會(huì)做適當(dāng)?shù)娜哂?。比如我們大部分的核心系統(tǒng)服務(wù)，會(huì)保持線上高峰時(shí) 1.5 倍左右的冗余，以保證高峰期間的業(yè)務(wù)異常流量情況下的系統(tǒng)可用。系統(tǒng)資源的動(dòng)態(tài)調(diào)配美團(tuán)外賣的服務(wù)系統(tǒng)都是部署在美團(tuán)私有云上的，最近一年來，我們也在很多的服務(wù)上使用了美團(tuán)

9、內(nèi)部的彈性計(jì)算容器，以應(yīng)對(duì)外賣系統(tǒng)的突增壓力時(shí)，可以做到近實(shí)時(shí)的系統(tǒng)快速擴(kuò)容。同時(shí)在低峰期也可以釋放資源，提升機(jī)器資源利用率。系統(tǒng)在極限壓力下的自我保護(hù)除了從基本的資源部署上來保證以外，在外賣的系統(tǒng)設(shè)計(jì)中，也會(huì)采取大量的自保護(hù)策略，其中包括各系統(tǒng)服務(wù)的限流、降級(jí)、熔斷等自我保護(hù)策略，以保證系統(tǒng)在異常流量壓力下核心鏈路的可用性。動(dòng)態(tài)調(diào)度設(shè)計(jì) 外賣業(yè)務(wù)鏈路較長(zhǎng)，其中關(guān)聯(lián)角色有三方：用戶、商家、騎手，簡(jiǎn)單的業(yè)務(wù)流程是：用戶下單 -商家接單 / 發(fā)配送 -騎手接單配送。外賣服務(wù)是一個(gè)強(qiáng)履約服務(wù)，需要盡最大可能，保障用戶下單之后，以最快的時(shí)間內(nèi)送達(dá)商品，保障用戶的體驗(yàn)。外賣當(dāng)前主要基于餐飲的商品，屬于非

10、標(biāo)品服務(wù)，同時(shí)也是基于人員配送的即時(shí)物流服務(wù)，所以一定時(shí)間內(nèi)的服務(wù)規(guī)模是有限的。一旦商家商品供給能力不足、或者配送資源不足的時(shí)候，都需要通過系統(tǒng)來調(diào)節(jié)。例如，當(dāng)運(yùn)力充足但商家訂單過多，出餐瓶頸出現(xiàn)的時(shí)候，為保證用戶的體驗(yàn)，我們會(huì)從產(chǎn)品上提示用戶商家忙，繼續(xù)下單需要能夠讓用戶有延遲送達(dá)的預(yù)期；同時(shí)針對(duì)訂單較多，出餐較慢的商家，也會(huì)在門店列表排序上給予一定的關(guān)聯(lián)因子降級(jí)。對(duì)于運(yùn)力不足的情況下，也會(huì)通過適當(dāng)?shù)膶?shí)時(shí)策略調(diào)整，來保證現(xiàn)有運(yùn)力的供給平衡，比如在高峰期之外降低配送費(fèi)，高峰期間提升配送費(fèi)來調(diào)節(jié)需求的平衡分布。在極端天氣，爆單的情況下，可以通過動(dòng)態(tài)調(diào)整特定區(qū)域商家的配送范圍，來保證用戶體驗(yàn)?？傊?/p>

11、在外賣的整個(gè)交易鏈路中，用戶、商家、配送等系統(tǒng)之間的實(shí)時(shí)數(shù)據(jù)是互通的，各業(yè)務(wù)系統(tǒng)通過關(guān)注不同的實(shí)時(shí)數(shù)據(jù)變化，采用不同的策略應(yīng)對(duì)，從而調(diào)節(jié)整個(gè)業(yè)務(wù)的運(yùn)作模式，保證外賣鏈路三方的平衡。當(dāng)前瓶頸 隨著業(yè)務(wù)規(guī)模的進(jìn)一步擴(kuò)展，當(dāng)前外賣分布式架構(gòu)體系中，系統(tǒng)各層的水平擴(kuò)展性是我們可能會(huì)面臨的瓶頸。 具體來說，我們面臨的問題包括如下兩點(diǎn)：服務(wù)層單個(gè)集群大小受限服務(wù)層雖然是無狀態(tài)服務(wù)，理論上可以無限增加，但是單個(gè)集群規(guī)模越大，運(yùn)維成本就會(huì)越高，比如基礎(chǔ)服務(wù)治理對(duì)于服務(wù)狀態(tài)的維護(hù)、更新、同步等。數(shù)據(jù)存儲(chǔ)單個(gè)集群大小受限單個(gè)集群的從庫個(gè)數(shù)是受限的，從庫越多，主庫消耗越大，導(dǎo)致從庫個(gè)數(shù)是受限的。所以總的來說，系統(tǒng)集

12、群規(guī)模是存在上限的，導(dǎo)致實(shí)時(shí)線上服務(wù)的系統(tǒng)處理能力受限。近期我們啟動(dòng)了外賣服務(wù) Set 化升級(jí)，結(jié)合外賣的強(qiáng)地域特征，將流量按照地域拆分開，每部分流量由單獨(dú)集群提供服務(wù)，從將整個(gè)大的分布式集群拆分為多個(gè)小集群，從而可以通過從業(yè)務(wù)邏輯層的設(shè)置，來達(dá)到控制集群規(guī)模大小的目的。在當(dāng)前我們的非 Set 化架構(gòu)體系中，受限于上面提到的兩點(diǎn)，大約可以滿足兩倍于當(dāng)前業(yè)務(wù)的數(shù)據(jù)量，可以支撐近一年左右的業(yè)務(wù)增長(zhǎng)。隨著我們的 Set 化項(xiàng)目 2018 年完成部署，理論上通過增加新的 Set 集群，進(jìn)一步擴(kuò)展系統(tǒng)能力，可很好地支持未來 35 年的業(yè)務(wù)增長(zhǎng)。優(yōu)先級(jí)策略 作為一個(gè)線上即時(shí)交易服務(wù)系統(tǒng)，在線上資源不足，或

13、者故障發(fā)生時(shí)，我們首先會(huì)優(yōu)先保護(hù)和訂單交易相關(guān)的核心業(yè)務(wù)鏈路。這條鏈路從用戶能感知到的服務(wù)就是：商家列表的瀏覽、商家內(nèi)的商品展示、用戶提單支付、商品騎手配送。這就需要我們梳理最小化的核心服務(wù)鏈路，除此之外的其他鏈路分支所關(guān)聯(lián)的所有服務(wù)，都可以在故障時(shí)刻被降級(jí)。比如針對(duì)商家列表的排序、推薦、廣告服務(wù)、評(píng)論服務(wù)、搜索服務(wù)等等。而實(shí)現(xiàn)最小化交易鏈路保證的前提是：各系統(tǒng)具備能夠降級(jí)非核心服務(wù)接口依賴的能力。外賣服務(wù)經(jīng)過這幾年的不斷業(yè)務(wù)梳理與積累，逐步開發(fā)實(shí)現(xiàn)了各業(yè)務(wù)鏈路的限流開關(guān)、功能服務(wù)開關(guān)、依賴服務(wù)降級(jí)開關(guān)百余個(gè)。這些開關(guān)通過我們的事故緊急預(yù)案，被分類組織到我們的業(yè)務(wù)運(yùn)維系統(tǒng)中，一旦對(duì)應(yīng)的事故發(fā)生

14、，我們可以快速的通過系統(tǒng)，來完成批量的服務(wù)降級(jí)處理，從而避免事故的發(fā)生、或減少事故造成的損失。外賣高峰期的入口請(qǐng)求 QPS 達(dá)到 20W 左右，這其中包含了部分惡意攻擊或抓取流量。針對(duì)惡意爬蟲抓取這塊，我們會(huì)與公司內(nèi)部的反爬團(tuán)隊(duì)一起做這塊的防范工作。而針對(duì)突發(fā)的攻擊性流量，除了公司上層流量入口層的控制以外，外賣自身的服務(wù)也會(huì)根據(jù)用戶或地域維度做一定的限流策略，避免惡意攻擊造成對(duì)正常流量的影響。架構(gòu)優(yōu)化 擴(kuò)容還是性能優(yōu)化 為達(dá)到目標(biāo)系統(tǒng)的容量，一般有擴(kuò)容和性能優(yōu)化兩種手段，這兩種手段會(huì)根據(jù)服務(wù)當(dāng)前的具體情況配合使用。大的原則是：長(zhǎng)期保持系統(tǒng)的優(yōu)化、緊急狀況擴(kuò)容或按照長(zhǎng)期業(yè)務(wù)趨勢(shì)規(guī)劃擴(kuò)容。具體我們

15、在擴(kuò)容和性能優(yōu)化上做的事情如下：關(guān)于擴(kuò)容能力外賣的業(yè)務(wù)技術(shù)系統(tǒng)，構(gòu)建在美團(tuán)內(nèi)部分布式基礎(chǔ)中間件之上（例如分布式緩存、消息隊(duì)列、服務(wù)治理中間件等），這些通用的分布式組件，為上層應(yīng)用的水平擴(kuò)容，提供了基礎(chǔ)能力保證。對(duì)外賣業(yè)務(wù)系統(tǒng)，我們也進(jìn)行了對(duì)應(yīng)的系統(tǒng)拆分 (例如交易服務(wù)、營(yíng)銷服務(wù)、評(píng)論服務(wù)、商品門店服務(wù)等)，拆分中保證各服務(wù)均采用無狀態(tài)設(shè)計(jì)，可以快速支持水平擴(kuò)容。另外類似營(yíng)銷這樣存在突發(fā)流量的服務(wù)，也接入到美團(tuán)彈性計(jì)算容器中，可以支持根據(jù)流量變化，來進(jìn)行自動(dòng)化的擴(kuò)縮容。關(guān)于性能優(yōu)化針對(duì)外賣高并發(fā)場(chǎng)景，合并分散的調(diào)用接口，降低各服務(wù)系統(tǒng)間訪問頻次，防止一次調(diào)用鏈中對(duì)依賴服務(wù)的請(qǐng)求次數(shù)放大；提升數(shù)據(jù)

16、獲取性能，優(yōu)化存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)（分庫、分表、建索引），采用適當(dāng)?shù)拇鎯?chǔ)方式（DB、分布式緩存、文件索引、本地內(nèi)存等）；將部分請(qǐng)求處理異步化，非實(shí)時(shí)處理離線化等。對(duì)于如何避免過度依賴擴(kuò)容，大的方面還是從系統(tǒng)的性能優(yōu)化入手，當(dāng)機(jī)器資源達(dá)到服務(wù)瓶頸的時(shí)候，需要深入分析具體瓶頸點(diǎn)在哪里，是存儲(chǔ)、CPU、帶寬還是其他的原因。然后針對(duì)具體的點(diǎn)，再考慮是否必須擴(kuò)容。在外賣定期進(jìn)行的全鏈路壓測(cè)場(chǎng)景中，我們會(huì)根據(jù)壓測(cè)的數(shù)據(jù)，結(jié)合各服務(wù)的 SLA 要求，來評(píng)估各服務(wù)的處理能力，再結(jié)合未來業(yè)務(wù)的增長(zhǎng)趨勢(shì)，做較長(zhǎng)期的容量擴(kuò)容規(guī)劃。系統(tǒng)架構(gòu)拆分原則 架構(gòu)的拆分需要匹配業(yè)務(wù)規(guī)模的發(fā)展程度，并具備一定的超前性。過早的拆分會(huì)造成不

17、必要的資源浪費(fèi)，而過晚的拆分，則又會(huì)累積現(xiàn)有系統(tǒng)的風(fēng)險(xiǎn)，增加拆分業(yè)務(wù)的梳理難度。在外賣的技術(shù)發(fā)展過程中，由于外賣早期的業(yè)務(wù)爆發(fā)太快，相對(duì)技術(shù)資源儲(chǔ)備不足，拆分的時(shí)機(jī)是落后于業(yè)務(wù)發(fā)展的，所以早期也出現(xiàn)過很多的線上事故。后來我們通過快速的系統(tǒng)架構(gòu)拆分與調(diào)整，逐步完善起外賣的后端體系架構(gòu)，減少了線上事故的發(fā)生?？偨Y(jié)起來，我們針對(duì)系統(tǒng)架構(gòu)的拆分遵循以下三個(gè)原則：流量拆分原則外賣服務(wù)流量按類型，我們可以簡(jiǎn)單的分為 To C 流量和 To B 流量，也就是面向外賣用戶和面向商家、運(yùn)營(yíng)的流量。針對(duì)不同流量的服務(wù)系統(tǒng)會(huì)拆分，典型的比如：針對(duì)商家或 BD 運(yùn)營(yíng)的門店管理、商品管理、營(yíng)銷活動(dòng)配置管理等，就會(huì)和線上

18、的門店、商品、營(yíng)銷等服務(wù)分開。除了服務(wù)系統(tǒng)上，存儲(chǔ) DB 上也會(huì)拆分，中間我們會(huì)采用一些實(shí)時(shí)的數(shù)據(jù)同步機(jī)制，保證數(shù)據(jù)的一致性。另外一個(gè)維度的流量拆分是按照同步與異步的請(qǐng)求分類。 就是從用戶流量的發(fā)起方來看，在請(qǐng)求的處理鏈條中，那些可以異步處理的邏輯服務(wù)，會(huì)從實(shí)時(shí)鏈路處理系統(tǒng)中分拆。比如我們的用戶提單系統(tǒng)、與商家接單處理系統(tǒng)、發(fā)配送系統(tǒng)等之間都是異步拆分的。功能閉合原則在軟件設(shè)計(jì)領(lǐng)域有一個(gè)著名的康威（Conway）定律，其中提到組織架構(gòu)與軟件架構(gòu)相互影響的辯證關(guān)系。我們?cè)诎凑諛I(yè)務(wù)功能垂直拆分的過程中，也會(huì)有同樣的考慮，盡量在一個(gè)組織架構(gòu)中，將功能性業(yè)務(wù)系統(tǒng)閉合，減少跨團(tuán)隊(duì)之間的溝通成本，提升產(chǎn)品

19、開發(fā)迭代效率。比如我們的的搜索服務(wù)、推薦服務(wù)、訂單交易服務(wù)、UGC 服務(wù)、營(yíng)銷服務(wù)、門店商品服務(wù)等等。平臺(tái)服務(wù)原則對(duì)不同業(yè)務(wù)系統(tǒng)公用邏輯或服務(wù)的抽取，形成基礎(chǔ)性中間件平臺(tái)，服務(wù)于多個(gè)業(yè)務(wù)系統(tǒng)，從而降低維護(hù)與開發(fā)的成本。比如我們的數(shù)據(jù)算法工程平臺(tái)，我們發(fā)現(xiàn)在很多的業(yè)務(wù)系統(tǒng)中，都會(huì)有些算法策略迭代，它們都需要線上特征數(shù)據(jù)、策略 A/B 實(shí)驗(yàn)、效果分析、工程系統(tǒng)支撐等。所以我們將此抽取成一個(gè)公共的工程平臺(tái)，算法只需要提供策略邏輯代碼，上傳到平臺(tái)上，平臺(tái)提供針對(duì)業(yè)務(wù)系統(tǒng)對(duì)接的標(biāo)準(zhǔn)化服務(wù)接口、特征的統(tǒng)一管理服務(wù)、算法的版本管理、A/B 實(shí)驗(yàn)、以及效果分析等等。這樣的業(yè)務(wù)中間平臺(tái)，可以很好的提升了各業(yè)務(wù)系

20、統(tǒng)的開發(fā)效率。如何梳理核心鏈路思路 作為線上即時(shí) O2O 電商業(yè)務(wù)，外賣業(yè)務(wù)核心是為用戶提供訂單交易履約，因此我們的核心鏈路是根據(jù)訂單交易的業(yè)務(wù)場(chǎng)景來梳理的。主要包括門店瀏覽、商品選購、交易支付、訂單配送環(huán)節(jié)，這四大業(yè)務(wù)環(huán)節(jié)強(qiáng)依賴的服務(wù)接口組合起來的鏈路，就是核心鏈路。而不在此關(guān)鍵鏈路中的服務(wù)或非強(qiáng)依賴服務(wù)鏈路，我們將此歸集為非核心鏈路。對(duì)于如何合理地對(duì)業(yè)務(wù)鏈路進(jìn)行分級(jí)，需要看業(yè)務(wù)規(guī)模的發(fā)展階段，早期可以只劃分核心鏈路和非核心鏈路兩級(jí)即可，后期可以再針對(duì)非核心鏈路，進(jìn)一步向下劃分，用以確定更細(xì)粒度的降級(jí)容錯(cuò)控制。比如我們?cè)谕赓u入口 API 層，調(diào)度外賣紅包服務(wù)的鏈路中，會(huì)按照紅包的使用、紅包的瀏覽、紅包的獲取等進(jìn)行進(jìn)一步的分級(jí)，當(dāng)紅包的系統(tǒng)壓力過大時(shí)