文章來源：http://geek.csdn.net/news/detail/101994

美團(tuán)外賣從2013年9月成交第一單以來，已走過了三個(gè)年頭。期間，業(yè)務(wù)飛速發(fā)展，美團(tuán)外賣由日均幾單發(fā)展為日均500萬單（9月11日已突破600萬）的大型O2O互聯(lián)網(wǎng)外賣服務(wù)平臺。平臺支持的品類也由最初外賣單品拓展為全品類。

隨著訂單量的增長、業(yè)務(wù)復(fù)雜度的提升，外賣訂單系統(tǒng)也在不斷演變進(jìn)化，從早期一個(gè)訂單業(yè)務(wù)模塊到現(xiàn)在分布式可擴(kuò)展的高性能、高可用、高穩(wěn)定訂單系統(tǒng)。整個(gè)發(fā)展過程中，訂單系統(tǒng)經(jīng)歷了幾個(gè)明顯的階段，下面本篇文章將為大家介紹一下訂單系統(tǒng)的演進(jìn)過程，重點(diǎn)關(guān)注各階段的業(yè)務(wù)特征、挑戰(zhàn)及應(yīng)對之道。

為方便大家更好地了解整個(gè)演進(jìn)過程，我們首先看一下外賣業(yè)務(wù)。

外賣訂單業(yè)務(wù)

外賣訂單業(yè)務(wù)是一個(gè)需要即時(shí)送的業(yè)務(wù)，對實(shí)時(shí)性要求很高。從用戶訂餐到最終送達(dá)用戶，一般在1小時(shí)內(nèi)。如果最終送達(dá)用戶時(shí)間變長，會(huì)帶來槽糕的用戶體驗(yàn)。在1小時(shí)內(nèi)，訂單會(huì)快速經(jīng)過多個(gè)階段，直到最終送達(dá)用戶。各個(gè)階段需要緊密配合，確保訂單順利完成。

下圖是一個(gè)用戶視角的訂單流程圖：

從普通用戶的角度來看，一個(gè)外賣訂單從下單后，會(huì)經(jīng)歷支付、商家接單、配送、用戶收貨、售后及訂單完成多個(gè)階段。以技術(shù)的視角來分解的話，每個(gè)階段依賴于多個(gè)子服務(wù)來共同完成，比如下單會(huì)依賴于購物車、訂單預(yù)覽、確認(rèn)訂單服務(wù)，這些子服務(wù)又會(huì)依賴于底層基礎(chǔ)系統(tǒng)來完成其功能。

外賣業(yè)務(wù)另一個(gè)重要特征是一天內(nèi)訂單量會(huì)規(guī)律變化，訂單會(huì)集中在中午、晚上兩個(gè)“飯點(diǎn)”附近，而其它時(shí)間的訂單量較少。這樣，飯點(diǎn)附近系統(tǒng)壓力會(huì)相對較大。

下圖是一天內(nèi)的外賣訂單量分布圖：

總結(jié)而言，外賣業(yè)務(wù)具有如下特征：

• 流程較長且實(shí)時(shí)性要求高；
• 訂單量高且集中。

下面將按時(shí)間脈絡(luò)為大家講解訂單系統(tǒng)經(jīng)歷的各個(gè)階段、各階段業(yè)務(wù)特征、挑戰(zhàn)以及應(yīng)對之道。

訂單系統(tǒng)雛型

外賣業(yè)務(wù)發(fā)展早期，第一目標(biāo)是要能夠快速驗(yàn)證業(yè)務(wù)的可行性。技術(shù)上，我們需要保證架構(gòu)足夠靈活、快速迭代從而滿足業(yè)務(wù)快速試錯(cuò)的需求。

在這個(gè)階段，我們將訂單相關(guān)功能組織成模塊，與其它模塊（門店模塊等）一起形成公用jar包，然后各個(gè)系統(tǒng)通過引入jar包來使用訂單功能。

早期系統(tǒng)的整體架構(gòu)圖如下所示：

早期，外賣整體架構(gòu)簡單、靈活，公共業(yè)務(wù)邏輯通過jar包實(shí)現(xiàn)后集成到各端應(yīng)用，應(yīng)用開發(fā)部署相對簡單。比較適合業(yè)務(wù)早期邏輯簡單、業(yè)務(wù)量較小、需要快速迭代的情況。但是，隨著業(yè)務(wù)邏輯的復(fù)雜、業(yè)務(wù)量的增長，單應(yīng)用架構(gòu)的弊端逐步暴露出來。系統(tǒng)復(fù)雜后，大家共用一個(gè)大項(xiàng)目進(jìn)行開發(fā)部署，協(xié)調(diào)的成本變高；業(yè)務(wù)之間相互影響的問題也逐漸增多。

早期業(yè)務(wù)處于不斷試錯(cuò)、快速變化、快速迭代階段，通過上述架構(gòu)，我們能緊跟業(yè)務(wù)，快速滿足業(yè)務(wù)需求。隨著業(yè)務(wù)的發(fā)展以及業(yè)務(wù)的逐步成熟，我們對系統(tǒng)進(jìn)行逐步升級，從而更好地支持業(yè)務(wù)。

獨(dú)立的訂單系統(tǒng)

2014年4月，外賣訂單量達(dá)到了10萬單/日，而且訂單量還在持續(xù)增長。這時(shí)候，業(yè)務(wù)大框架基本成型，業(yè)務(wù)在大框架基礎(chǔ)上快速迭代。大家共用一個(gè)大項(xiàng)目進(jìn)行開發(fā)部署，相互影響，協(xié)調(diào)成本變高；多個(gè)業(yè)務(wù)部署于同一VM，相互影響的情況也在增多。

為解決開發(fā)、部署、運(yùn)行時(shí)相互影響的問題。我們將訂單系統(tǒng)進(jìn)行獨(dú)立拆分，從而獨(dú)立開發(fā)、部署、運(yùn)行，避免受其它業(yè)務(wù)影響。

系統(tǒng)拆分主要有如下幾個(gè)原則：

• 相關(guān)業(yè)務(wù)拆分獨(dú)立系統(tǒng)；
• 優(yōu)先級一致的業(yè)務(wù)拆分獨(dú)立系統(tǒng)；
• 拆分系統(tǒng)包括業(yè)務(wù)服務(wù)和數(shù)據(jù)。

基于以上原則，我們將訂單系統(tǒng)進(jìn)行獨(dú)立拆分，所有訂單服務(wù)通過RPC接口提供給外部使用。訂單系統(tǒng)內(nèi)部，我們將功能按優(yōu)先級拆分為不同子系統(tǒng)，避免相互影響。訂單系統(tǒng)通過MQ（隊(duì)列）消息，通知外部訂單狀態(tài)變更。

獨(dú)立拆分后的訂單系統(tǒng)架構(gòu)如下所示：

其中，最底層是數(shù)據(jù)存儲層，訂單相關(guān)數(shù)據(jù)獨(dú)立存儲。訂單服務(wù)層，我們按照優(yōu)先級將訂單服務(wù)劃分為三個(gè)系統(tǒng)，分別為交易系統(tǒng)、查詢系統(tǒng)、異步處理系統(tǒng)。

獨(dú)立拆分后，可以避免業(yè)務(wù)間的相互影響。快速支持業(yè)務(wù)迭代需求的同時(shí)，保障系統(tǒng)穩(wěn)定性。

高性能、高可用、高穩(wěn)定的訂單系統(tǒng)

訂單系統(tǒng)經(jīng)過上述獨(dú)立拆分后，有效地避免了業(yè)務(wù)間的相互干擾，保障迭代速度的同時(shí)，保證了系統(tǒng)穩(wěn)定性。這時(shí)，我們的訂單量突破百萬，而且還在持續(xù)增長。之前的一些小問題，在訂單量增加后，被放大，進(jìn)而影響用戶體驗(yàn)。比如，用戶支付成功后，極端情況下（比如網(wǎng)絡(luò)、數(shù)據(jù)庫問題）會(huì)導(dǎo)致支付成功消息處理失敗，用戶支付成功后依然顯示未支付。訂單量變大后，問題訂單相應(yīng)增多。我們需要提高系統(tǒng)的可靠性，保證訂單功能穩(wěn)定可用。

另外，隨著訂單量的增長、訂單業(yè)務(wù)的復(fù)雜，對訂單系統(tǒng)的性能、穩(wěn)定性、可用性等提出了更高的要求。

為了提供更加穩(wěn)定、可靠的訂單服務(wù)，我們對拆分后的訂單系統(tǒng)進(jìn)行進(jìn)一步升級。下面將分別介紹升級涉及的主要內(nèi)容。

性能優(yōu)化

系統(tǒng)獨(dú)立拆分后，可以方便地對訂單系統(tǒng)進(jìn)行優(yōu)化升級。我們對獨(dú)立拆分后的訂單系統(tǒng)進(jìn)行了很多的性能優(yōu)化工作，提升服務(wù)整體性能，優(yōu)化工作主要涉及如下幾個(gè)方面。

異步化

服務(wù)所需要處理的工作越少，其性能自然越高。可以通過將部分操作異步化來減少需要同步進(jìn)行的操作，進(jìn)而提升服務(wù)的性能。異步化有兩種方案。

• 線程或線程池：將異步操作放在單獨(dú)線程中處理，避免阻塞服務(wù)線程；
• 消息異步：異步操作通過接收消息完成。

異步化帶來一個(gè)隱患，如何保障異步操作的執(zhí)行。這個(gè)場景主要發(fā)生在應(yīng)用重啟時(shí)，對于通過線程或線程池進(jìn)行的異步化，JVM重啟時(shí)，后臺執(zhí)行的異步操作可能尚未完成。這時(shí)，需要通過JVM優(yōu)雅關(guān)閉來保證異步操作進(jìn)行完成后，JVM再關(guān)閉。通過消息來進(jìn)行的，消息本身已提供持久化，不受應(yīng)用重啟影響。

具體到訂單系統(tǒng)，我們通過將部分不必同步進(jìn)行的操作異步化，來提升對外服務(wù)接口的性能。不需要立即生效的操作即可以異步進(jìn)行，比如發(fā)放紅包、PUSH推送、統(tǒng)計(jì)等。

以訂單配送PUSH推送為例，將PUSH推送異步化后的處理流程變更如下所示：

PUSH異步化后，線程#1在更新訂單狀態(tài)、發(fā)送消息后立即返回，而不用同步等待PUSH推送完成。而PUSH推送異步在線程#2中完成。

并行化

操作并行化也是提升性能的一大利器，并行化將原本串行的工作并行執(zhí)行，降低整體處理時(shí)間。我們對所有訂單服務(wù)進(jìn)行分析，將其中非相互依賴的操作并行化，從而提升整體的響應(yīng)時(shí)間。

以用戶下單為例，第一步是從各個(gè)依賴服務(wù)獲取信息，包括門店、菜品、用戶信息等。獲取這些信息并不需要相互依賴，故可以將其并行化，并行后的處理流程變更如下所示：

通過將獲取信息并行化，可有效縮短下單時(shí)間，提升下單接口性能。

緩存

通過將統(tǒng)計(jì)信息進(jìn)行提前計(jì)算后緩存，避免獲取數(shù)據(jù)時(shí)進(jìn)行實(shí)時(shí)計(jì)算，從而提升獲取統(tǒng)計(jì)數(shù)據(jù)的服務(wù)性能。比如對于首單、用戶已減免配送費(fèi)等，通過提前計(jì)算后緩存，可以簡化實(shí)時(shí)獲取數(shù)據(jù)邏輯，節(jié)約時(shí)間。

以用戶已減免配送費(fèi)為例，如果需要實(shí)時(shí)計(jì)算，則需要取到用戶所有訂單后，再進(jìn)行計(jì)算，這樣實(shí)時(shí)計(jì)算成本較高。我們通過提前計(jì)算，緩存用戶已減免配送費(fèi)。需要取用戶已減免配送費(fèi)時(shí)，從緩存中取即可，不必實(shí)時(shí)計(jì)算。具體來說，包括如下幾點(diǎn)：

• 通過緩存保存用戶已減免配送費(fèi)；
• 用戶下單時(shí)，如果訂單有減免配送費(fèi)，增加緩存中用戶減免配送費(fèi)金額（異步進(jìn)行）；
• 訂單取消時(shí)，如果訂單有減免配送費(fèi)，減少緩存中用戶減免配送費(fèi)金額（異步進(jìn)行）。

一致性優(yōu)化

訂單系統(tǒng)涉及交易，需要保證數(shù)據(jù)的一致性。否則，一旦出現(xiàn)問題，可能會(huì)導(dǎo)致訂單不能及時(shí)配送、交易金額不對等。

交易一個(gè)很重要的特征是其操作具有事務(wù)性，訂單系統(tǒng)是一個(gè)復(fù)雜的分布式系統(tǒng)，比如支付涉及訂單系統(tǒng)、支付平臺、支付寶/網(wǎng)銀等第三方。僅通過傳統(tǒng)的數(shù)據(jù)庫事務(wù)來保障不太可行。對于訂單交易系統(tǒng)的事務(wù)性，并不要求嚴(yán)格滿足傳統(tǒng)數(shù)據(jù)庫事務(wù)的ACID性質(zhì)，只需要最終結(jié)果一致即可。針對訂單系統(tǒng)的特征，我們通過如下種方式來保障最終結(jié)果的一致性。

重試/冪等

通過延時(shí)重試，保證操作最終會(huì)最執(zhí)行。比如退款操作，如退款時(shí)遇到網(wǎng)絡(luò)或支付平臺故障等問題，會(huì)延時(shí)進(jìn)行重試，保證退款最終會(huì)被完成。重試又會(huì)帶來另一個(gè)問題，即部分操作重復(fù)進(jìn)行，需要對操作進(jìn)行冪等處理，保證重試的正確性。

以退款操作為例，加入重試/冪等后的處理流程如下所示：

退款操作首先會(huì)檢查是否已經(jīng)退款，如果已經(jīng)退款，直接返回。否則，向支付平臺發(fā)起退款，從而保證操作冪等，避免重復(fù)操作帶來問題。如果發(fā)起退款失敗（比如網(wǎng)絡(luò)或支付平臺故障），會(huì)將任務(wù)放入延時(shí)隊(duì)列，稍后重試。否則，直接返回。

通過重試+冪等，可以保證退款操作最終一定會(huì)完成。

2PC

2PC是指分布式事務(wù)的兩階段提交，通過2PC來保證多個(gè)系統(tǒng)的數(shù)據(jù)一致性。比如下單過程中，涉及庫存、優(yōu)惠資格等多個(gè)資源，下單時(shí)會(huì)首先預(yù)占資源（對應(yīng)2PC的第一階段），下單失敗后會(huì)釋放資源（對應(yīng)2PC的回滾階段），成功后會(huì)使用資源（對應(yīng)2PC的提交階段）。對于2PC，網(wǎng)上有大量的說明，這里不再繼續(xù)展開。

高可用

分布式系統(tǒng)的可用性由其各個(gè)組件的可用性共同決定，要提升分布式系統(tǒng)的可用性，需要綜合提升組成分布式系統(tǒng)的各個(gè)組件的可用性。

針對訂單系統(tǒng)而言，其主要組成組件包括三類：存儲層、中間件層、服務(wù)層。下面將分層說明訂單系統(tǒng)的可用性。

存儲層

存儲層的組件如MySQL、ES等本身已經(jīng)實(shí)現(xiàn)了高可用，比如MySQL通過主從集群、ES通過分片復(fù)制來實(shí)現(xiàn)高可用。存儲層的高可用依賴各個(gè)存儲組件即可。

中間件層

分布式系統(tǒng)會(huì)大量用到各類中間件，比如服務(wù)調(diào)用框架等，這類中間件一般使用開源產(chǎn)品或由公司基礎(chǔ)平臺提供，本身已具備高可用。

服務(wù)層

在分布式系統(tǒng)中，服務(wù)間通過相互調(diào)用來完成業(yè)務(wù)功能，一旦某個(gè)服務(wù)出現(xiàn)問題，會(huì)級聯(lián)影響調(diào)用方服務(wù)，進(jìn)而導(dǎo)致系統(tǒng)崩潰。分布式系統(tǒng)中的依賴容災(zāi)是影響服務(wù)高可用的一個(gè)重要方面。

依賴容災(zāi)主要有如下幾個(gè)思路：

• 依賴超時(shí)設(shè)置；
• 依賴災(zāi)備；
• 依賴降級；
• 限制依賴使用資源。

訂單系統(tǒng)會(huì)依賴多個(gè)其它服務(wù)，也存在這個(gè)問題。當(dāng)前訂單系統(tǒng)通過同時(shí)采用上述四種方法，來避免底層服務(wù)出現(xiàn)問題時(shí)，影響整體服務(wù)。具體實(shí)現(xiàn)上，我們采用Hystrix框架來完成依賴容災(zāi)功能。Hystrix框架采用上述四種方法，有效實(shí)現(xiàn)依賴容災(zāi)。訂單系統(tǒng)依賴容災(zāi)示意圖如下所示：

通過為每個(gè)依賴服務(wù)設(shè)置獨(dú)立的線程池、合理的超時(shí)時(shí)間及出錯(cuò)時(shí)回退方法，有效避免服務(wù)出現(xiàn)問題時(shí)，級聯(lián)影響，導(dǎo)致整體服務(wù)不可用，從而實(shí)現(xiàn)服務(wù)高可用。

另外，訂單系統(tǒng)服務(wù)層都是無狀態(tài)服務(wù)，通過集群+多機(jī)房部署，可以避免單點(diǎn)問題及機(jī)房故障，實(shí)現(xiàn)高可用。

小結(jié)

上面都是通過架構(gòu)、技術(shù)實(shí)現(xiàn)層面來保障訂單系統(tǒng)的性能、穩(wěn)定性、可用性。實(shí)際中，有很多的事故是人為原因?qū)е碌?#xff0c;除了好的架構(gòu)、技術(shù)實(shí)現(xiàn)外，通過規(guī)范、制度來規(guī)避人為事故也是保障性能、穩(wěn)定性、可用性的重要方面。訂單系統(tǒng)通過完善需求review、方案評審、代碼review、測試上線、后續(xù)跟進(jìn)流程來避免人為因素影響訂單系統(tǒng)穩(wěn)定性。

通過以上措施，我們將訂單系統(tǒng)建設(shè)成了一個(gè)高性能、高穩(wěn)定、高可用的分布式系統(tǒng)。其中，交易系統(tǒng)tp99為150ms、查詢系統(tǒng)tp99時(shí)間為40ms。整體系統(tǒng)可用性為6個(gè)9。

可擴(kuò)展的訂單系統(tǒng)

訂單系統(tǒng)經(jīng)過上面介紹的整體升級后，已經(jīng)是一個(gè)高性能、高穩(wěn)定、高可用的分布式系統(tǒng)。但是系統(tǒng)的的可擴(kuò)展性還存在一定問題，部分服務(wù)只能通過垂直擴(kuò)展（增加服務(wù)器配置）而不能通過水平擴(kuò)展（加機(jī)器）來進(jìn)行擴(kuò)容。但是，服務(wù)器配置有上限，導(dǎo)致服務(wù)整體容量受到限制。

到2015年5月的時(shí)候，這個(gè)問題就比較突出了。當(dāng)時(shí)，數(shù)據(jù)庫服務(wù)器寫接近單機(jī)上限。業(yè)務(wù)預(yù)期還會(huì)繼續(xù)快速增長。為保障業(yè)務(wù)的快速增長，我們對訂單系統(tǒng)開始進(jìn)行第二次升級。目標(biāo)是保證系統(tǒng)有足夠的擴(kuò)展性，從而支撐業(yè)務(wù)的快速發(fā)展。

分布式系統(tǒng)的擴(kuò)展性依賴于分布式系統(tǒng)中各個(gè)組件的可擴(kuò)展性，針對訂單系統(tǒng)而言，其主要組成組件包括三類：存儲層、中間件層、服務(wù)層。下面將分層說明如何提高各層的可擴(kuò)展性。

存儲層

訂單系統(tǒng)存儲層主要依賴于MySQL持久化、tair/redis cluster緩存。tair/redis cluster緩存本身即提供了很好的擴(kuò)展性。MySQL可以通過增加從庫來解決讀擴(kuò)展問題。但是，對于寫MySQL存在單機(jī)容量的限制。另外，數(shù)據(jù)庫的整體容量受限于單機(jī)硬盤的限制。

存儲層的可擴(kuò)展性改造主要是對MySQL擴(kuò)展性改造。

分庫分表

寫容量限制是受限于MySQL數(shù)據(jù)庫單機(jī)處理能力限制。如果能將數(shù)據(jù)拆為多份，不同數(shù)據(jù)放在不同機(jī)器上，就可以方便對容量進(jìn)行擴(kuò)展。

對數(shù)據(jù)進(jìn)行拆分一般分為兩步，第一步是分庫，即將不同表放不同庫不同機(jī)器上。經(jīng)過第一步分庫后，容量得到一定提升。但是，分庫并不能解決單表容量超過單機(jī)限制的問題，隨著業(yè)務(wù)的發(fā)展，訂單系統(tǒng)中的訂單表即遇到了這個(gè)問題。

針對訂單表超過單庫容量的問題，需要進(jìn)行分表操作，即將訂單表數(shù)據(jù)進(jìn)行拆分。單表數(shù)據(jù)拆分后，解決了寫的問題，但是如果查詢數(shù)據(jù)不在同一個(gè)分片，會(huì)帶來查詢效率的問題（需要聚合多張表）。由于外賣在線業(yè)務(wù)對實(shí)時(shí)性、性能要求較高。我們針對每個(gè)主要的查詢維度均保存一份數(shù)據(jù)（每份數(shù)據(jù)按查詢維度進(jìn)行分片），方便查詢。

具體來說，外賣主要涉及三個(gè)查詢維度：訂單ID、用戶ID、門店ID。對訂單表分表時(shí)，對于一個(gè)訂單，我們存三份，分別按照訂單ID、用戶ID、門店ID以一定規(guī)則存儲在每個(gè)維度不同分片中。這樣，可以分散寫壓力，同時(shí)，按照訂單ID、用戶ID、門店ID三個(gè)維度查詢時(shí)，數(shù)據(jù)均在一個(gè)分片，保證較高的查詢效率。

訂單表分表后，訂單表的存儲架構(gòu)如下所示：

可以看到，分表后，每個(gè)維度共有100張表，分別放在4個(gè)庫上面。對于同一個(gè)訂單，冗余存儲了三份。未來，隨著業(yè)務(wù)發(fā)展，還可以繼續(xù)通過將表分到不同機(jī)器上來持續(xù)獲得容量的提升。

分庫分表后，訂單數(shù)據(jù)存儲到多個(gè)庫多個(gè)表中，為應(yīng)用層查詢帶來一定麻煩，解決分庫分表后的查詢主要有三種方案：

• MySQL服務(wù)器端支持：目前不支持
• 中間件
• 應(yīng)用層

由于MySQL服務(wù)器端不能支持，我們只剩下中間件和應(yīng)用層兩個(gè)方案。中間件方案對應(yīng)用透明，但是開發(fā)難度相對較大，當(dāng)時(shí)這塊沒有資源去支持。于是，我們采用應(yīng)用層方案來快速支持。結(jié)合應(yīng)用開發(fā)框架（SPRING+MYBATIS），我們實(shí)現(xiàn)了一個(gè)輕量級的分庫分表訪問插件，避免將分庫分表邏輯嵌入到業(yè)務(wù)代碼。分庫分表插件的實(shí)現(xiàn)包括如下幾個(gè)要點(diǎn)。

• 配置文件管理分庫分表配置信息；
• JAVA注解說明SQL語句分庫分表信息；
• JAVA AOP解析注解+查詢配置文件，獲取數(shù)據(jù)源及表名；
• MYBATIS動(dòng)態(tài)替換表名；
• SPRING動(dòng)態(tài)替換數(shù)據(jù)源。

通過分庫分表，解決了寫容量擴(kuò)展問題。但是分表后，會(huì)給查詢帶來一定的限制，只能支持主要維度的查詢，其它維度的查詢效率存在問題。

ES搜索

訂單表分表之后，對于ID、用戶ID、門店ID外的查詢（比如按照手機(jī)號前綴查詢）存在效率問題。這部分通常是復(fù)雜查詢，可以通過全文搜索來支持。在訂單系統(tǒng)中，我們通過ES來解決分表后非分表維度的復(fù)雜查詢效率問題。具體來說，使用ES，主要涉及如下幾點(diǎn)：

• 通過databus將訂單數(shù)據(jù)同步到ES。
• 同步數(shù)據(jù)時(shí)，通過批量寫入來降低ES寫入壓力。
• 通過ES的分片機(jī)制來支持?jǐn)U展性。

小結(jié)

通過對存儲層的可擴(kuò)展性改造，使得訂單系統(tǒng)存儲層具有較好的可擴(kuò)展性。對于中間層的可擴(kuò)展性與上面提到的中間層可用性一樣，中間層本身已提供解決方案，直接復(fù)用即可。對于服務(wù)層，訂單系統(tǒng)服務(wù)層提供的都是無狀態(tài)服務(wù)，對于無狀態(tài)服務(wù)，通過增加機(jī)器，即可獲得更高的容量，完成擴(kuò)容。

通過對訂單系統(tǒng)各層可擴(kuò)展性改造，使得訂單系統(tǒng)具備了較好的可擴(kuò)展性，能夠支持業(yè)務(wù)的持續(xù)發(fā)展，當(dāng)前，訂單系統(tǒng)已具體千萬單/日的容量。

上面幾部分都是在介紹如何通過架構(gòu)、技術(shù)實(shí)現(xiàn)等手段來搭建一個(gè)可靠、完善的訂單系統(tǒng)。但是，要保障系統(tǒng)的持續(xù)健康運(yùn)行，光搭建系統(tǒng)還不夠，運(yùn)維也是很重要的一環(huán)。

智能運(yùn)維的訂單系統(tǒng)

早期，對系統(tǒng)及業(yè)務(wù)的運(yùn)維主要是采用人肉的方式，即外部反饋問題，RD通過排查日志等來定位問題。隨著系統(tǒng)的復(fù)雜、業(yè)務(wù)的增長，問題排查難度不斷加大，同時(shí)反饋問題的數(shù)量也在逐步增多。通過人肉方式效率偏低，并不能很好的滿足業(yè)務(wù)的需求。

為提升運(yùn)維效率、降低人力成本，我們對系統(tǒng)及業(yè)務(wù)運(yùn)維進(jìn)行自動(dòng)化、智能化改進(jìn)，改進(jìn)包括事前、事中、事后措施。

事前措施

事前措施的目的是為提前發(fā)現(xiàn)隱患，提前解決，避免問題惡化。

在事前措施這塊，我們主要采取如下幾個(gè)手段：

定期線上壓測：通過線上壓測，準(zhǔn)確評估系統(tǒng)容量，提前發(fā)現(xiàn)系統(tǒng)隱患；

周期性系統(tǒng)健康體檢：通過周期檢測CPU利用率、內(nèi)存利用率、接口QPS、接口TP95、異常數(shù)，取消訂單數(shù)等指標(biāo)是否異常，可以提前發(fā)現(xiàn)提前發(fā)現(xiàn)潛在問題、提前解決；

全鏈路關(guān)鍵日志：通過記錄全鏈路關(guān)鍵日志，根據(jù)日志，自動(dòng)分析反饋訂單問題原因，給出處理結(jié)果，有效提高反饋處理效率。

事中措施

事中措施的目的是為及時(shí)發(fā)現(xiàn)問題、快速解決問題。

事中這塊，我們采取的手段包括：

訂單監(jiān)控大盤：實(shí)時(shí)監(jiān)控訂單業(yè)務(wù)指標(biāo)，異常時(shí)報(bào)警；

系統(tǒng)監(jiān)控大盤：實(shí)時(shí)監(jiān)控訂單系統(tǒng)指標(biāo)，異常時(shí)報(bào)警；

完善的SOP：報(bào)警后，通過標(biāo)準(zhǔn)流程，快速定位問題、解決問題。

事后措施

事后措施是指問題發(fā)生后，分析問題原因，徹底解決。并將相關(guān)經(jīng)驗(yàn)教訓(xùn)反哺給事前、事中措施，不斷加強(qiáng)事先、事中措施，爭取盡量提前發(fā)現(xiàn)問題，將問題扼殺在萌芽階段。

通過將之前人肉進(jìn)行的運(yùn)維操作自動(dòng)化、智能化，提升了處理效率、減少了運(yùn)維的人力投入。

總結(jié)

以上是生活随笔為你收集整理的美团外卖订单系统演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。