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

內容來源：2017 年 12 月 2 日，途牛首席架構師趙國光在「IAS2017互聯網架構峯會」進行《途牛系統架構優化實踐》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2391 | 6分鐘閱讀

嘉賓演講視頻及PPT回顧：suo.im/5j0Pik

摘要

本分享介紹途牛在業務高速增加同時的系統架構發展過程，以及這過程當中總結下來的經驗和架構實例。

途牛業務與系統總體介紹

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

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

在瞭解了旅遊產品的難點以後，接下看下途牛的總體架構，這套架構目前還在不斷演化過程當中。系統的最上層是前端應用，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的模式。

架構師的角色

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