《餓了麼：業務井噴時，訂單系統架構這樣演進》閱讀筆記

1、背景

　　餓了麼是一家創業公司，業務發展很是快，可能準備不是很充分，好比說監控、日誌、告警、框架、消息、數據庫，不少基礎設施還在建設之中。

　　在這個過程當中出現一些問題是在所不免的，對系統的要求不是不能掛、不能出問題，而是出了問題要第一時間能恢復。

2、「拆」以及跟「拆」對等的就是分治的思想

　　怎麼拆分呢？面向服務有不少拆分原則，羅列了如下幾條：

　　一、明確的定義：

　　以前也確實犯了一些錯誤，爲了拆而拆。其實咱們須要更明確，什麼纔算是一個服務？服務必定具備很是獨立的技術能力或者業務能力，並且必定意義上可以很抽象

　　二、鬆耦合：

　　最基本的鬆耦合就是Customer的消費不依賴於Provider的某一個特定實現，這樣服務器的內部變動不會影響外部消費，消費者能夠切換到其餘服務能力的提供方，這是最基本的鬆耦合。

　　還有時間上的鬆耦合或者位置上的鬆耦合，咱們但願的鬆耦合是消費方和服務方是能夠分離的

　　三、基於領域認知：

　　這對於整個產品起到很是大的做用。

　　由於當時整個餓了麼全部系統是在一塊兒的，基於領域的認知，在面向用戶的維度和麪向商戶的維度作了切分，還有基於交易鏈路作了切分。

　　四、單一職責與關注分離：

　　簡單說，咱們但願一個服務或者一個模塊擁有單一的能力，而不是承擔過多的職責，不然責任不清晰，致使能力也不清晰。

　　五、可被驗證的結果：

　　在訂單拆分的過程當中咱們犯了一些錯誤，當時認爲這樣拆分是沒有問題的，可是過1、兩個月，並無帶來效率和能力的提高，反而是跨團隊的要求愈來愈多，能力要求也愈來愈多。這時候多是拆錯了。若是是一個好的拆分必定有利於發展，拆分以後的發展是更迅速的。

　　基於這幾條原則，他們對餓了麼的總體服務作拆分以後，如上圖所示，架構就有了一些變化，看起來跟剛纔架構區別不大。把Order Service作了分離。當時拆分雖然比較垂直，可是用戶、商戶、金融、訂單等仍是有一些橫向交互。

　　一個接口有一個很是明確的Owner，一個表、一個庫也能保證僅有單一的操做方，讓我感覺比較直接的是，爲服務的治理奠基了基礎，之後能夠針對某項特定業務作一些降級、熔斷，以及單獨的監控。拆分其實是讓各自模塊的掌控力變得更強了，對業務起到更好的支撐做用。

　　這時每一個部門或者每一個團隊都負責本身獨立的領域，代碼和數據都拆分完畢是否是就能夠了？

　　可是後來發現好像還不對。由於雖然大的領域上確實已經乾淨了，可是在小的領域上依然問題不少，訂單並不只僅只有一張表，一個單一的模塊，其實還有不少複雜的內容。

　　在一些技術工做上，這些問題曝露得並非那麼明顯，那時候你們對於一些領域認知或者業務邊界的認識仍是模糊的，沒有人界定這些。可是當更進一步地去發展一個領域的時候，仍是會有職責不清晰或者能力模糊的地方。咱們思考，還要基於業務進行更細膩的規劃。

　　因而咱們把訂單自己作了一些業務層次的拆分，拆分以前首先要確認訂單到底在整個系統中，尤爲是交易系統、O2O系統中承擔什麼角色，擔負什麼職責。

3、在這個思考過程當中，咱們的認知大概是如下四點：

　　一、第一，訂單是整個交易鏈路的核心，圍繞了一些相關服務，好比金額計算服務、催單服務、售中異常服務等，咱們但願這些服務之間有明確的區別。

　　二、第二，訂單實時處理是整個鏈路的中心，咱們將這個過程定義得儘可能簡潔。

　　一筆交易中，訂單被推動得越複雜，說明系統設計得越複雜，出問題的機率也會越高。因此咱們但願訂單核心流程很是簡單、輕薄，把複雜的東西剝離出來，把簡單和複雜明確成兩個部分。

　　三、第三，考慮到交易的時效性和異常場景愈來愈複雜，將交易分紅正向交易流程和逆向交易流程兩個部分。

　　正向交易流程，99%的訂單會根據這個流程走完生命週期；逆向交易流程，好比說退單要求時效性比較低，處理會牽扯多方業務可能很複雜，因此經過一個逆向的交易流程來解決。

　　四、第四，可以在功能和業務上獨立的部分，儘量抽象爲單獨的模塊或服務。

　　簡單來講，好比催單的服務，它其實對交易鏈路沒法起到推動做用，它只是一個動做或者附帶服務，咱們把它單獨抽象出來，爲後面的發展作出鋪墊。

 　　基於這些以後，咱們對訂單進行完整的認知，對訂單的服務架構和業務架構作成圖中的樣子，大概是三層。

　　下面一層是基本數據；中間層是正向逆向的流程、最核心的狀態和最關聯的交易鏈上耦合的服務；上層是用戶服務、商戶服務，包括跟交易鏈相關的，好比餓了麼最近推出的「準時達」的服務。

　　監控和告警的峯值很是明顯，午間和晚間兩個高峯，其餘時間流量相對平緩。下面主要講三個部分。

　　一、第一，對於訂單而言，吞吐量是最須要重點關注的指標。

　　一開始對業務指標的感知並非特別清晰，就在某一個接口耗費了不少時間。後來發現一些很小BD的問題不太容易從小接口感知到，可是從業務方面感知就比較明顯，因此就更多關注業務指標的控制。

　　二、第二，一般咱們重視系統指標，而容易忽視業務指標，其實業務指標更能反映出隱晦的問題。

　　三、第三，目前咱們致力於基於監控和數據學習的過載保護和業務自動降級。

　　雖然如今尚未徹底作好，可是已經能感受到一些效果。若是商戶長時間不接單，用戶會自動取消訂單，自動取消功能的開關目前是人工控制的，咱們更但願是系統來控制。

　　好比說有大量訂單取消了，有多是接單功能出了問題，就須要臨時關閉這個功能，若是仍是依靠人來作，每每已經來不及，這時候就應該基於數據的學習，讓系統自動降級這個功能。

　　Kennel有四個主要的做用。

　　一、首先，幫助咱們發現鏈路中隱蔽的缺陷，將小几率事件放大。好比說緩存不一致的問題，以前極少出現，一旦出現以後，處理手段比較缺少，那就能夠經過Kennel來模擬。網絡的抖動是很隨機的，那麼Kennel能夠在某個時間段專門進行模擬，把小几率事件放大。若是懷疑某個地方出了問題，能夠經過它來測試是否是真的能查出問題。

　　二、第二，重大功能能夠在發佈以前經過其進行測試，迫使你更深刻地設計和編碼。經過模擬流量或者線上流量回放，來檢驗系統運行是否如你設計那樣工做，好比監控的曲線或者告警以及相關服務之間的依賴等。

　　三、第三，咱們作了不少失敗的準備和設計，要看到底會不會起做用、起多大做用。能夠經過Kennel進行校驗，在某個時間經過隨機手段攻擊相關服務，服務方不知道具體的攻擊內容，這時本來設定的監控告警，降級熔斷等措施有沒有及時起做用就是一個很好的校驗。同時還能夠檢驗以前準備的容錯或者補償措施是否能按照預期工做。

　　四、第四，須要驗證FailOver的設計，只有驗證經過才能夠依靠。全部的設計都是經歷了一次一次的失敗，一些設計原覺得有用，可是真實問題發生時並無起到做用。真正有意義的FailOver設計必定是通過驗證的。

 

　　原文連接：

　　https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650993858&idx=1&sn=ce2cc36b737da8c00ba5cfb5cfe9488a&scene=21#wechat_redirect