前言

美團外賣從2013年9月成交第一單以來，已走過了三個年頭。期間，業務飛速發展，美團外賣由日均幾單發展為日均500萬單（9月11日已突破600萬）的大型O2O網際網路外賣服務平臺。平臺支援的品類也由最初外賣單品拓展為全品類。

隨著訂單量的增長、業務複雜度的提升，外賣訂單系統也在不斷演變進化，從早期一個訂單業務模組到現在分散式可擴充套件的高效能、高可用、高穩定訂單系統。整個發展過程中，訂單系統經歷了幾個明顯的階段，下面本篇文章將為大家介紹一下訂單系統的演進過程，重點關注各階段的業務特徵、挑戰及應對之道。

為方便大家更好地瞭解整個演進過程，我們首先看一下外賣業務。

外賣訂單業務

外賣訂單業務是一個需要即時送的業務，對實時性要求很高。從使用者訂餐到最終送達使用者，一般在1小時內。如果最終送達使用者時間變長，會帶來槽糕的使用者體驗。在1小時內，訂單會快速經過多個階段，直到最終送達使用者。各個階段需要緊密配合，確保訂單順利完成。

下圖是一個使用者視角的訂單流程圖。

從普通使用者的角度來看，一個外賣訂單從下單後，會經歷支付、商家接單、配送、使用者收貨、售後及訂單完成多個階段。以技術的視角來分解的話，每個階段依賴於多個子服務來共同完成，比如下單會依賴於購物車、訂單預覽、確認訂單服務，這些子服務又會依賴於底層基礎系統來完成其功能。

外賣業務另一個重要特徵是一天內訂單量會規律變化，訂單會集中在中午、晚上兩個“飯點”附近，而其它時間的訂單量較少。這樣，飯點附近系統壓力會相對較大。

下圖是一天內的外賣訂單量分佈圖

總結而言，外賣業務具有如下特徵：

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

下面將按時間脈絡為大家講解訂單系統經歷的各個階段、各階段業務特徵、挑戰以及應對之道。

訂單系統雛型

外賣業務發展早期，第一目標是要能夠快速驗證業務的可行性。技術上，我們需要保證架構足夠靈活、快速迭代從而滿足業務快速試錯的需求。

在這個階段，我們將訂單相關功能組織成模組，與其它模組（門店模組等）一起形成公用jar包，然後各個系統通過引入jar包來使用訂單功能。

早期系統的整體架構圖如下所示：

早期，外賣整體架構簡單、靈活，公共業務邏輯通過jar包實現後集成到各端應用，應用開發部署相對簡單。比較適合業務早期邏輯簡單、業務量較小、需要快速迭代的情況。但是，隨著業務邏輯的複雜、業務量的增長，單應用架構的弊端逐步暴露出來。系統複雜後，大家共用一個大專案進行開發部署，協調的成本變高；業務之間相互影響的問題也逐漸增多。

早期業務處於不斷試錯、快速變化、快速迭代階段，通過上述架構，我們能緊跟業務，快速滿足業務需求。隨著業務的發展以及業務的逐步成熟，我們對系統進行逐步升級，從而更好地支援業務。

獨立的訂單系統

2014年4月，外賣訂單量達到了10萬單/日，而且訂單量還在持續增長。這時候，業務大框架基本成型，業務在大框架基礎上快速迭代。大家共用一個大專案進行開發部署，相互影響，協調成本變高；多個業務部署於同一VM，相互影響的情況也在增多。

為解決開發、部署、執行時相互影響的問題。我們將訂單系統進行獨立拆分，從而獨立開發、部署、執行，避免受其它業務影響。

系統拆分主要有如下幾個原則：

• 相關業務拆分獨立系統；
• 優先順序一致的業務拆分獨立系統；
• 拆分系統包括業務服務和資料。

基於以上原則，我們將訂單系統進行獨立拆分，所有訂單服務通過RPC介面提供給外部使用。訂單系統內部，我們將功能按優先順序拆分為不同子系統，避免相互影響。訂單系統通過MQ（佇列）訊息，通知外部訂單狀態變更。

獨立拆分後的訂單系統架構如下所示：

其中，最底層是資料儲存層，訂單相關資料獨立儲存。訂單服務層，我們按照優先順序將訂單服務劃分為三個系統，分別為交易系統、查詢系統、非同步處理系統。

獨立拆分後，可以避免業務間的相互影響。快速支援業務迭代需求的同時，保障系統穩定性。

高效能、高可用、高穩定的訂單系統

訂單系統經過上述獨立拆分後，有效地避免了業務間的相互干擾，保障迭代速度的同時，保證了系統穩定性。這時，我們的訂單量突破百萬，而且還在持續增長。之前的一些小問題，在訂單量增加後，被放大，進而影響使用者體驗。比如，使用者支付成功後，極端情況下（比如網路、資料庫問題）會導致支付成功訊息處理失敗，使用者支付成功後依然顯示未支付。訂單量變大後，問題訂單相應增多。我們需要提高系統的可靠性，保證訂單功能穩定可用。

另外，隨著訂單量的增長、訂單業務的複雜，對訂單系統的效能、穩定性、可用性等提出了更高的要求。

為了提供更加穩定、可靠的訂單服務，我們對拆分後的訂單系統進行進一步升級。下面將分別介紹升級涉及的主要內容。

效能優化

系統獨立拆分後，可以方便地對訂單系統進行優化升級。我們對獨立拆分後的訂單系統進行了很多的效能優化工作，提升服務整體效能，優化工作主要涉及如下幾個方面。

非同步化

服務所需要處理的工作越少，其效能自然越高。可以通過將部分操作非同步化來減少需要同步進行的操作，進而提升服務的效能。非同步化有兩種方案。

• 執行緒或執行緒池：將非同步操作放在單獨執行緒中處理，避免阻塞服務執行緒；
• 訊息非同步：非同步操作通過接收訊息完成。

非同步化帶來一個隱患，如何保障非同步操作的執行。這個場景主要發生在應用重啟時，對於通過執行緒或執行緒池進行的非同步化，JVM重啟時，後臺執行的非同步操作可能尚未完成。這時，需要通過JVM優雅關閉來保證非同步操作進行完成後，JVM再關閉。通過訊息來進行的，訊息本身已提供持久化，不受應用重啟影響。

具體到訂單系統，我們通過將部分不必同步進行的操作非同步化，來提升對外服務介面的效能。不需要立即生效的操作即可以非同步進行，比如發放紅包、PUSH推送、統計等。

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

PUSH非同步化後，執行緒#1在更新訂單狀態、傳送訊息後立即返回，而不用同步等待PUSH推送完成。而PUSH推送非同步線上程#2中完成。

並行化

操作並行化也是提升效能的一大利器，並行化將原本序列的工作並行執行，降低整體處理時間。我們對所有訂單服務進行分析，將其中非相互依賴的操作並行化，從而提升整體的響應時間。

以使用者下單為例，第一步是從各個依賴服務獲取資訊，包括門店、菜品、使用者資訊等。獲取這些資訊並不需要相互依賴，故可以將其並行化，並行後的處理流程變更如下所示：

通過將獲取資訊並行化，可有效縮短下單時間，提升下單介面效能。

快取

通過將統計資訊進行提前計算後快取，避免獲取資料時進行實時計算，從而提升獲取統計資料的服務效能。比如對於首單、使用者已減免配送費等，通過提前計算後快取，可以簡化實時獲取資料邏輯，節約時間。

以使用者已減免配送費為例，如果需要實時計算，則需要取到使用者所有訂單後，再進行計算，這樣實時計算成本較高。我們通過提前計算，快取使用者已減免配送費。需要取使用者已減免配送費時，從快取中取即可，不必實時計算。具體來說，包括如下幾點：

• 通過快取儲存使用者已減免配送費；
• 使用者下單時，如果訂單有減免配送費，增加快取中使用者減免配送費金額（非同步進行）；
• 訂單取消時，如果訂單有減免配送費，減少快取中使用者減免配送費金額（非同步進行）；

一致性優化

訂單系統涉及交易，需要保證資料的一致性。否則，一旦出現問題，可能會導致訂單不能及時配送、交易金額不對等。

交易一個很重要的特徵是其操作具有事務性，訂單系統是一個複雜的分散式系統，比如支付涉及訂單系統、支付平臺、支付寶/網銀等第三方。僅通過傳統的資料庫事務來保障不太可行。對於訂單交易系統的事務性，並不要求嚴格滿足傳統資料庫事務的ACID性質，只需要最終結果一致即可。針對訂單系統的特徵，我們通過如下種方式來保障最終結果的一致性。

重試/冪等

通過延時重試，保證操作最終會最執行。比如退款操作，如退款時遇到網路或支付平臺故障等問題，會延時進行重試，保證退款最終會被完成。重試又會帶來另一個問題，即部分操作重複進行，需要對操作進行冪等處理，保證重試的正確性。

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

退款操作首先會檢查是否已經退款，如果已經退款，直接返回。否則，向支付平臺發起退款，從而保證操作冪等，避免重複操作帶來問題。如果發起退款失敗（比如網路或支付平臺故障），會將任務放入延時佇列，稍後重試。否則，直接返回。

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

2PC

2PC是指分散式事務的兩階段提交，通過2PC來保證多個系統的資料一致性。比如下單過程中，涉及庫存、優惠資格等多個資源，下單時會首先預佔資源（對應2PC的第一階段），下單失敗後會釋放資源（對應2PC的回滾階段），成功後會使用資源（對應2PC的提交階段）。對於2PC，網上有大量的說明，這裡不再繼續展開。

高可用

分散式系統的可用性由其各個元件的可用性共同決定，要提升分散式系統的可用性，需要綜合提升組成分散式系統的各個元件的可用性。

針對訂單系統而言，其主要組成元件包括三類：儲存層、中介軟體層、服務層。下面將分層說明訂單系統的可用性。

儲存層

儲存層的元件如MySQL、ES等本身已經實現了高可用，比如MySQL通過主從叢集、ES通過分片複製來實現高可用。儲存層的高可用依賴各個儲存元件即可。

中介軟體層

分散式系統會大量用到各類中介軟體，比如服務呼叫框架等，這類中介軟體一般使用開源產品或由公司基礎平臺提供，本身已具備高可用。

服務層

在分散式系統中，服務間通過相互呼叫來完成業務功能，一旦某個服務出現問題，會級聯影響呼叫方服務，進而導致系統崩潰。分散式系統中的依賴容災是影響服務高可用的一個重要方面。

依賴容災主要有如下幾個思路：

• 依賴超時設定；
• 依賴災備；
• 依賴降級；
• 限制依賴使用資源；

訂單系統會依賴多個其它服務，也存在這個問題。當前訂單系統通過同時採用上述四種方法，來避免底層服務出現問題時，影響整體服務。具體實現上，我們採用Hystrix框架來完成依賴容災功能。Hystrix框架採用上述四種方法，有效實現依賴容災。訂單系統依賴容災示意圖如下所示

通過為每個依賴服務設定獨立的執行緒池、合理的超時時間及出錯時回退方法，有效避免服務出現問題時，級聯影響，導致整體服務不可用，從而實現服務高可用。

另外，訂單系統服務層都是無狀態服務，通過叢集+多機房部署，可以避免單點問題及機房故障，實現高可用。

小結

上面都是通過架構、技術實現層面來保障訂單系統的效能、穩定性、可用性。實際中，有很多的事故是人為原因導致的，除了好的架構、技術實現外，通過規範、制度來規避人為事故也是保障效能、穩定性、可用性的重要方面。訂單系統通過完善需求review、方案評審、程式碼review、測試上線、後續跟進流程來避免人為因素影響訂單系統穩定性。

通過以上措施，我們將訂單系統建設成了一個高效能、高穩定、高可用的分散式系統。其中，交易系統tp99為150ms、查詢系統tp99時間為40ms。整體系統可用性為6個9。

可擴充套件的訂單系統

訂單系統經過上面介紹的整體升級後，已經是一個高效能、高穩定、高可用的分散式系統。但是系統的的可擴充套件性還存在一定問題，部分服務只能通過垂直擴充套件（增加伺服器配置）而不能通過水平擴充套件（加機器）來進行擴容。但是，伺服器配置有上限，導致服務整體容量受到限制。

到2015年5月的時候，這個問題就比較突出了。當時，資料庫伺服器寫接近單機上限。業務預期還會繼續快速增長。為保障業務的快速增長，我們對訂單系統開始進行第二次升級。目標是保證系統有足夠的擴充套件性，從而支撐業務的快速發展。

分散式系統的擴充套件性依賴於分散式系統中各個元件的可擴充套件性，針對訂單系統而言，其主要組成元件包括三類：儲存層、中介軟體層、服務層。下面將分層說明如何提高各層的可擴充套件性。

儲存層

訂單系統儲存層主要依賴於MySQL持久化、tair/redis cluster快取。tair/redis cluster快取本身即提供了很好的擴充套件性。MySQL可以通過增加從庫來解決讀擴充套件問題。但是，對於寫MySQL存在單機容量的限制。另外，資料庫的整體容量受限於單機硬碟的限制。

儲存層的可擴充套件性改造主要是對MySQL擴充套件性改造。

• 分庫分表

寫容量限制是受限於MySQL資料庫單機處理能力限制。如果能將資料拆為多份，不同資料放在不同機器上，就可以方便對容量進行擴充套件。

對資料進行拆分一般分為兩步，第一步是分庫，即將不同表放不同庫不同機器上。經過第一步分庫後，容量得到一定提升。但是，分庫並不能解決單表容量超過單機限制的問題，隨著業務的發展，訂單系統中的訂單表即遇到了這個問題。

針對訂單表超過單庫容量的問題，需要進行分表操作，即將訂單表資料進行拆分。單表資料拆分後，解決了寫的問題，但是如果查詢資料不在同一個分片，會帶來查詢效率的問題（需要聚合多張表）。由於外賣線上業務對實時性、效能要求較高。我們針對每個主要的查詢維度均儲存一份資料（每份資料按查詢維度進行分片），方便查詢。

具體來說，外賣主要涉及三個查詢維度：訂單ID、使用者ID、門店ID。對訂單表分表時，對於一個訂單，我們存三份，分別按照訂單ID、使用者ID、 門店ID以一定規則儲存在每個維度不同分片中。這樣，可以分散寫壓力，同時，按照訂單ID、使用者ID、門店ID三個維度查詢時，資料均在一個分片，保證較高的查詢效率。

訂單表分表後，訂單表的儲存架構如下所示：

可以看到，分表後，每個維度共有100張表，分別放在4個庫上面。對於同一個訂單，冗餘儲存了三份。未來，隨著業務發展，還可以繼續通過將表分到不同機器上來持續獲得容量的提升。

分庫分表後，訂單資料儲存到多個庫多個表中，為應用層查詢帶來一定麻煩，解決分庫分表後的查詢主要有三種方案：

• MySQL伺服器端支援：目前不支援。
• 中介軟體。
• 應用層。

由於MySQL伺服器端不能支援，我們只剩下中介軟體和應用層兩個方案。中介軟體方案對應用透明，但是開發難度相對較大，當時這塊沒有資源去支援。於是，我們採用應用層方案來快速支援。結合應用開發框架（SPRING+MYBATIS），我們實現了一個輕量級的分庫分表訪問外掛，避免將分庫分表邏輯嵌入到業務程式碼。分庫分表外掛的實現包括如下幾個要點。

• 配置檔案管理分庫分表配置資訊；
• JAVA註解說明SQL語句分庫分表資訊；
• JAVA AOP解析註解+查詢配置檔案，獲取資料來源及表名；
• MYBATIS動態替換表名；
• SPRING動態替換資料來源。

通過分庫分表，解決了寫容量擴充套件問題。但是分表後，會給查詢帶來一定的限制，只能支援主要維度的查詢，其它維度的查詢效率存在問題。

• ES搜尋

訂單表分表之後，對於ID、使用者ID、門店ID外的查詢（比如按照手機號字首查詢）存在效率問題。這部分通常是複雜查詢，可以通過全文搜尋來支援。在訂單系統中，我們通過ES來解決分表後非分表維度的複雜查詢效率問題。具體來說，使用ES，主要涉及如下幾點。

• 通過databus將訂單資料同步到ES。
• 同步資料時，通過批量寫入來降低ES寫入壓力。
• 通過ES的分片機制來支援擴充套件性。

小結

通過對儲存層的可擴充套件性改造，使得訂單系統儲存層具有較好的可擴充套件性。對於中間層的可擴充套件性與上面提到的中間層可用性一樣，中間層本身已提供解決方案，直接複用即可。對於服務層，訂單系統服務層提供的都是無狀態服務，對於無狀態服務，通過增加機器，即可獲得更高的容量，完成擴容。

通過對訂單系統各層可擴充套件性改造，使得訂單系統具備了較好的可擴充套件性，能夠支援業務的持續發展，當前，訂單系統已具體千萬單/日的容量。

上面幾部分都是在介紹如何通過架構、技術實現等手段來搭建一個可靠、完善的訂單系統。但是，要保障系統的持續健康執行，光搭建系統還不夠，運維也是很重要的一環。

智慧運維的訂單系統

早期，對系統及業務的運維主要是採用人肉的方式，即外部反饋問題，RD通過排查日誌等來定位問題。隨著系統的複雜、業務的增長，問題排查難度不斷加大，同時反饋問題的數量也在逐步增多。通過人肉方式效率偏低，並不能很好的滿足業務的需求。

為提升運維效率、降低人力成本，我們對系統及業務運維進行自動化、智慧化改進，改進包括事前、事中、事後措施。

• 事前措施

事前措施的目的是為提前發現隱患，提前解決，避免問題惡化。

在事前措施這塊，我們主要採取如下幾個手段：

1. 定期線上壓測：通過線上壓測，準確評估系統容量，提前發現系統隱患；
2. 週期性系統健康體檢：通過週期檢測CPU利用率、記憶體利用率、介面QPS、介面TP95、異常數，取消訂單數等指標是否異常，可以提前發現提前發現潛在問題、提前解決；
3. 全鏈路關鍵日誌：通過記錄全鏈路關鍵日誌，根據日誌，自動分析反饋訂單問題原因，給出處理結果，有效提高反饋處理效率。

• 事中措施

事中措施的目的是為及時發現問題、快速解決問題。

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

1. 訂單監控大盤：實時監控訂單業務指標，異常時報警；
2. 系統監控大盤：實時監控訂單系統指標，異常時報警；
3. 完善的SOP：報警後，通過標準流程，快速定位問題、解決問題。

• 事後措施

事後措施是指問題發生後，分析問題原因，徹底解決。並將相關經驗教訓反哺給事前、事中措施，不斷加強事先、事中措施，爭取儘量提前發現問題，將問題扼殺在萌芽階段。

通過將之前人肉進行的運維操作自動化、智慧化，提升了處理效率、減少了運維的人力投入。