途牛旅遊系統架構的優化實踐

途牛是以出遊度假為主的綜合類的線上旅遊入口，在進入正題之前，這裡先介紹下旅遊產品的幾大特點或者說難點。

首先是產品構成複雜，呈現組合性而不是獨立的。其次價格波動大，眾所周知機票的波動幅度很大，相對的與機票關聯的旅遊產品價格也就會隨之浮動。另外由於途牛對應的供應商眾多，這些供應商對資料的描繪以及互動方式都不一樣，所以我們要對這些資料進行計算匹配變成途牛內部的規則化描述形式呈現給客人。

在瞭解了旅遊產品的難點之後，接下看下途牛的整體架構，這套架構目前還在不斷演化過程中。系統的最上層是前端應用，App、web、M站等入口，中間是資料適配層和介面代理以及一些獨立的應用，再往下是兩層業務層，主要的業務邏輯都發生在這裡，最下層是基礎設施。

系統的構建過程中我們的原則是把公共的抽象的事務都落到下層。

垂直架構其實很好理解，比如一個公司內部每個業務部門都有自己的應用系統和伺服器，互相之間相互獨立，這樣的形式就是垂直架構。

能夠確定一點的就是垂直架構架構並不適用於所有情況，如果有足夠的人力和資金但是沒有充足時間的情況下，選擇垂直架構快速堆建業務可能會比較便捷。

而當公司發展到一定程度的時候，垂直架構的問題就凸顯出來了，主要有三個問題。首先就是重複建設，不同的組織之間獨立工作就一定會有重複的部分，這就造成了人力的損失。另一方面系統間的資料流難以打通，資源無法共享，這是因為垂直架構下每個業務的系統設計都是針對本身的，資料結構和互動方式都存在差異，因此很難打通兩個業務。最後就是缺少業務沉澱，平臺能力喪失了。

在談論微服務之前首先要明確一點，就是服務化技術框架不等於服務化，充其量只是披上微服務化的技術外衣。服務化追求的是解耦和複用，要做服務化得從問題域上思考，從概念層理解服務化然後再思考如何實現。

服務化中如果對系統拆分過細又管理不善的話，至少會帶來三個問題。第一個問題是服務管理，無法理清眾多服務之間的邏輯。其次是問題排查，通常一個業務鏈會串多個服務系統，一旦出現問題很難判斷哪個系統出錯。最後是溝通協同的問題，拆散的服務由不同的團隊負責，那麼團隊之間的步調就很難保證。所以說微服務化是有成本的，而我們要做的就是讓收益大於成本。

而服務化面臨的第一個問題是重複，比如在一個系統架構中A呼叫b，而此時有需求要在b系統內實現某個功能，該功能和b原來的功能大部分相近，同時要求該功能儘快上線並且不影響原來的業務。對此最直接的做法就是拷貝一份b作為b1，然後在b1上實現新功能，這樣就實現了隔離以及儘快部署的需求。

一般正常來說追求隔離是沒問題的，但是不能以重複作為代價，重複所帶來的問題長期下來會拖垮團隊的開發能力，使得維護的系統越來越多而且還有些相似。

在分散式系統下本來就會造成資料一致性的問題，微服務下這個問題則會更加明顯或容易出現，因此要小心避免，不要再人為的增加資料一致性的問題。

上圖中a呼叫b，b呼叫c，最後b對c返回的資料進行加工然後返回給a，b為了加快對a的響應速度，呼叫完c後會將c的資料快取到自身的系統內。這樣的好處在於加快了對a的響應時間同時減輕了c的壓力，但是同時帶來了一個問題，c的資料傳送變化無法通知給b，因為b快取資料c是不知情的。面對這樣的情況我們要做出權衡，是要追求多級快取帶來的效能提升還是將快取放在c上減少系統一致性問題。

以下為我們總結的微服務化原則。

- 面向業務，圍繞領域模型

- 隱藏實現細節

- 聚焦使用者和API

- 去中心化

- 獨立、自動化部署

不同場景下企業應用面對的複雜性是不同的，大致可分為三類。第一類是量的問題，大使用者量，大流量，高併發等，第二類是業務邏輯複雜，第三類是業務功能的快速變化。

途牛有很多的業務品類，不同品類的訂單人機互動邏輯不同，狀態流轉不完全相同，另一方面資源型別多，每種資源的處理方式又不同。

直觀看來我們現在面臨的是業務邏輯複雜並且品類較多的問題，這種問題最好的解決方案是在領域模型上尋找答案。

上圖是應用領域模型的軟體架構，可以看到所有的資源都被抽象出來變成了領域模型，雖然不同的資源操作方式不同，但可以將資源委託給具體的資源，這樣新增資源時就不會產生任何影響。

不同的訂單在價格、合同、資源管理器等方面都存在不同，而我們可以將這些部分抽象出不同的角色用不同的品類去實現，在訂單生成時通過品類將不同的職責注入進去。

從大體上看整個架構採用的是CQS的模式。

做為架構師首要目標是理解業務，需要注意的是清楚實現細節和理解業務是不同的，理解業務是要明白業務形態、商務模式。另外要能夠定義問題並能提出解決方案，同時還要關注人的因素，畢竟要和不同職位上的人溝通，每個人的處理方式都是不同的。最後就是權衡，比如我們經常會需要在執行表現、工作量和功能上做權衡，那麼如何做權衡呢，我認為必須要基於對業務的理解出發。