途牛訂單的服務化演進

乙個系統無論視同開發還是執行時的資源，都無法滿足業務的需求，服務化是我們架構演進的方向，不是為了服務化而去做服務化，是由業務發展的複雜度和發展的業務量驅動的架構進化，是為了滿足更快速的支撐更大規模的更複雜業務規則的擴充套件性要求設計，所以，我們做第一步，垂直拆分。

各系統通過webservice或者rest等方式整合，以前最流行的soa實施方式，看起來解決了業務發展過程中存在的一些問題。

業務型別較少的情況下解決了部分執行時資源緊張和故障隔離問題，**拆分出來，專案構建影響小。就是松耦合，獨立演進等等。

在只有乙隻手可以數的清楚的業務型別下，這種可以說基本上解決了我們一些問題，但是，我們的業務發展太速度了，每一種型別的訂單，基本上都離不開這些領域的資料的互動，但是業務規則變化多樣。

如果按照原來的思路，繼續不斷的增加一些型別判斷如if...else...也能滿足我們的要求，但是到最後可能就是四五十個if else，而且相互影響，每個規則都相似又不同，所以其實大家發現了，其實這個時候訂單的組裝業務的規則已經成了現在的主要矛盾。

設計的問題，加一層就能解決很多問題，這個時候其實我們就需要吧我們的一些公共的服務（訂單域）抽象出來，變化的規則通過具體的服務組裝和編排去解決。

這個其實遠了，我想說的就是，業務拆分，soa能解決一部分問題，但是也有缺點，沒有統一的管理，呼叫鏈不知誰依賴了誰，可靠性，可用性等的監控得不到保障，所以，這時候我們進入了服務化的第二階段，服務治理。

通過合理的管理和監控，保證所有的呼叫有據可循，有序有章法。

犧牲一小部分去換取更大規模的業務，這是值得的，所以總結下：

我們服務化的過程就是拆分-》治理-》拆分，其實是乙個不斷迭代的過程，是隨著業務發展和業務認知深度的發展而不斷的拆分和治理的迭代。