除了美團外賣之外，餓了么，我們大家也時非常熟悉。當初，餓了么平台訂單的數量在一定時間內也經歷過井噴期，下通過學習雲時代架構的文章，我對餓了么的架構進化升級有了一定程度的了解。
在2014年初，餓了么訂單量只有日均10萬單，到2014年底超過百萬，這是一個質的飛躍，10萬訂單的量級和百萬訂單的量級的要求非常不一樣。在2015年突破了日均300萬，到今年5月單日峰值突破500萬。快速發展涉及很多問題。大家都知道，餓了么是一家新興的公司，在美團之后發展起來的，那么隨着業務發展非常快，也就 會帶來一系列的問題。可能准備不是很充分，比如說監控、日志、告警、框架、消息、數據庫，很多基礎設施還在建設之中。在這個過程中出現一些問題是在所難免的，對系統的要求不是不能掛、不能出問題，而是出了問題要第一時間能恢復。這是整個系統架構的前提。下午是早起餓了么訂單架構的圖解。
圖中所示是訂單的早期架構圖，比較簡單。這個架構在2014年的時候支撐了日均10萬的訂單，是一套很不錯的架構，依然在很多系統中完美運行。但是對於后來發展的場景，它已經曝露問題了，比如業務邏輯嚴重耦合、代碼管理很困難，因為數據庫都在一起，操作變更很難追溯。
更進一步的是，性能的瓶頸只能是靠服務器去硬抗，從物理架構到邏輯架構，都已經成為業務發展的掣肘了。於是，為了業務的發展，我們做了一些演進的工作。
演進工作的核心就是一個字“拆”，跟“拆”對等的就是分治的思想。怎么拆分呢？面向服務有很多拆分原則。我將拆分過程中最具幫助和指導性的點羅列了以下幾條。
- 第一是明確的定義。之前也確實犯了一些錯誤，為了拆而拆。其實我們需要更明確，什么才算是一個服務？服務一定具有非常獨立的技術能力或者業務能力，而且一定意義上能夠很抽象。
- 第二是松耦合。最基本的松耦合就是Customer的消費不依賴於Provider的某一個特定實現，這樣服務器的內部變更不會影響外部消費，消費者可以切換到其他服務能力的提供方，這是最基本的松耦合。還有時間上的松耦合或者位置上的松耦合，我們希望的松耦合是消費方和服務方是可以分離的。
- 第三是基於領域的認知，這對於整個產品起到非常大的作用。因為當時整個餓了么所有系統是在一起的，基於領域的認知，在面向用戶的維度和面向商戶的維度做了切分，還有基於交易鏈路做了切分。
- 第四是單一職責和關注分離。簡單說，我們希望一個服務或者一個模塊擁有單一的能力，而不是承擔過多的職責，否則責任不清晰，導致能力也不清晰。
- 最后一點是可被驗證的結果。在訂單拆分的過程中我們犯了一些錯誤，當時認為這樣拆分是沒有問題的，但是過一、兩個月，並沒有帶來效率和能力的提升，反而是跨團隊的要求越來越多，能力要求也越來越多。這時候可能是拆錯了。如果是一個好的拆分一定有利於發展，拆分之后的發展是更迅速的。
通過對餓了么訂單架構的升級學習分析，我更加理解了上課王老師經常強調的分而治之的思想。對於一個具體的宏觀問題，我們采取分而治之的策略，將問題逐步進行分解。