導讀：價格中心系統是途牛網眾多系統中很重要的一個，幾乎所有的售賣價格計算都由此系統產生。初期由于缺乏合理設計，無法及時滿足業務高速增長的需求，出現價格計算速度慢、系統不穩定、增加功能困難等問題，系統面臨巨大壓力，在這種情況下我們啟動了系統優化。經過優化系統的穩定性得到巨大提升，特殊場景下的性能提升為原來的幾十倍，平均性能提升為原來的幾倍。本文將就途牛價格中心系統的優化實踐作深入分享。

一、旅游產品的特點

旅游產品是各種資源的整合，包括機票、酒店、門票、簽證等所有旅行過程中使用到的各種服務。如圖1，以三亞五日游這個產品為例，第一天飛到三亞并入住酒店，然后各種玩，第五天飛走，其中涉及到很多種服務。

圖1 三亞五日游

在計算過程中需要處理這些場景:

產品的每個團期都需要排列選出最低價格的資源組成；

同一資源在不同的團期下價格可能不同(淡旺季,不同供應商報價不同,資源庫存影響)；

需要考慮同行程下的酒店連住天數,選出連住多天總價最便宜的酒店資源；

某些資源只有計算時通過多個條件篩選才知道其價格(如飛機散客票)；

某些產品配置很多資源,如上千酒店。

因此，得到一個產品的價格需要很多的數據和計算。另外，資源的價格會頻繁變化，比如機票的價格；或者因一批低價格的庫存賣光了那么這個資源就無法再以低價售賣，價格就要漲。這些情況就會使價格發生變化。這種變化的頻率很高，加上資源的數量較多，每天達到幾百萬次，且每個資源會被多個產品使用，所以每個資源變化都會引起多個產品的價格計算。這些因素造成價格中心面臨兩大難點：計算復雜、計算量大。

二、重構實踐

在整個系統優化重構的過程中我們遇到了很多問題，正是這些問題得到了很好的解決，才使得系統優化成功。

●2.1 系統最關注什么？

系統最關注的是響應時間？吞吐量？并發數？功能正確？還是穩定性？這些都是我們關注的，但當魚和熊掌不可兼得的時候，我們更關注什么？這個問題關系到我們的技術選型以及更深入地理解系統。

舉個例子，假設是一個對響應時間要求很高的系統，一個請求要求立即得到響應，那么就不太適合過多的異步處理方式。價格中心系統更專注吞吐量，即資源的價格變化必須能夠反映到產品的價格上。在響應時間方面不是強制要求必須毫秒級或秒級，事實上只要幾秒內可以變過來就可以，因為客人在價格變化的一瞬間預定產品的概率是很低的。某些場景下響應時間可以更長，比如夜里刷價格，所以我們完全可以采用異步處理的方式。

●2.2 系統的瓶頸在哪里？

系統的性能優化往往落到CPU/IO/內存這三個里面（圖2）。那我們的系統瓶頸在哪里？

圖2 CPU/IO/內存

這個問題決定著系統優化該往哪走。拿價格中心系統舉例，假如CPU很低、IO時間很長、內存使用量很大，就能得出一個結論：速度上不去，時間都消耗在IO上了，CPU得不到有效利用。進而得出對策：提升并發線程數，把CPU打上去。但是這樣做會帶來內存的消耗增加，所以不合適。

經過分析就會有疑問：這么多IO讀取出來的數據占用了內存，而CPU較低，是不是有冗余的數據讀?。繋е@個疑問再次檢查發現確實存在，這只是一個附帶的發現，經過分析我們基本確定的方向是降IO，通過控制計算規模降低內存使用量。

●2.3 抽象領域模型

圖3 領域模型

抽象領域模型為了解決什么問題？

原系統中的功能邏輯混亂，耦合嚴重；

大家對一個功能如何實現缺乏統一的認識；

產品和開發之間的溝通缺乏統一的語言。

領域模型凝聚了領域知識的元素，是系統運行不可或缺的成員，但領域模型不具備系統整體運行所具有的知識，只負責模型內部的邏輯。

系統至少要有領域層和應用層，領域模型在領域層完成各自的邏輯實現，應用層再將這些領域模型關聯起來。我們經過抽象將系統提煉出大的領域模型為資源、產品、促銷、交通、基礎等（圖3）。

●2.4 微服務的劃分

劃分微服務是為了解決以下問題：

功能耦合；

數據耦合，即沒有劃分和保護的數據被多個功能模塊依賴，導致一處數據的改動將波及大面積的功能模塊；

升級的影響范圍，因某個功能需要擴充實例將導致所有實例都重新部署，某一個小功能引起的上線也將是整個應用的上線。

具體做法是：通過抽象，基于之前建立的領域模型劃分出符合系統特點的微服務，每個服務應對系統的一類復雜度。不同的微服務之間在邏輯功能、被調用頻率、依賴的數據、實例個數等方面都是不一樣的。我們的系統經過提煉劃分為資源管理服務、產品價格管理服務、計算控制服務、促銷計算服務、價格查詢服務。

微服務之間的配合推薦采用異步消息隊列的方式，這樣服務只關心自己的處理邏輯，而不用關心自己產生的數據被誰以哪種方式處理，服務之間是互相不感知的。

當然這是這個系統的特點決定的，因為可以稍微犧牲一點響應時間。通過RESTFUL接口的方式調用也是不錯的選擇，這時服務提供方一定是提供通用的服務，即不會在自身邏輯里出現“當調用者是XX的時候如何處理”這種判斷。

●2.5 控制每次計算的粒度

我們的系統還面臨一個特殊的問題：一個旅游產品由多種資源構成，比如酒店/門票/機票等，正如前文所說，一個產品的價格計算可能有多種資源和選擇。

比如一個三亞5日游的產品，可以從北京/南京/上海/西安等多個城市出發（如圖4），這些城市的航班都不一樣，會有許多航班線路可供選擇，數量與可以去三亞的城市數量成正比。而這種城市數量會有多少，程序事先無法知道，完全由業務人員的產品設計決定。

這種情況帶來的問題就是：計算一個產品的價格時，不容易預先知道計算量大小，有時城市很少那么計算量就小，而有時出發去目的地的城市很多那么計算量就很大。

圖4 多地出發

這至少會帶來兩個麻煩：

一是系統的能力不容易評估，因為每次技術的粒度都不得而知，沒有統一的衡量標準；

二是內存會有很大的浪費。

經過分析，我們認為從北京出發到三亞的產品價格和從上海去三亞的產品價格不要求在同一個時間產生，所以可以分開計算。這樣就可以縮小每次計算的粒度，使每次計算的粒度控制在一個相對原子的大小上。這就大大降低了內存的使用，同時也加速了計算速度。

●2.6 無縫升級

每次升級都要考慮如何做到對外無感知、同時可回滾的設計，將風險控制在最低。一般如果涉及到數據庫結構變化，可以選擇雙寫，新結構數據庫穩定之后再將老庫作廢。

但我們遇到一個問題：希望改變輸入規則，如圖5，將配置方式由藍色方式改為綠色方式，因為綠色的方式更靈活，更符合業務需求，但問題是線上已經有大量的藍色方式數據配置，把這些數據全刪掉再按照綠色方式配置上去是不可能的。

那么怎么做到平滑切換？除非找到一個算法將藍色配置映射成為綠色，遺憾的是沒有這種方法。

圖5 改變輸入規則

我們的做法是將藍色數據配置和綠色數據配置都向一個固定的模型去映射，把它們全部視為規則，那么藍色和綠色就是四種規則，如圖6所示。這樣就做到了新老數據共存和平滑升級。

圖6 規則

三、 技術實現

●3.1 擴展立方體

隨著業務對計算資源、存儲資源的需求不斷增加，另一方面摩爾定律失效，人們無法找到擁有巨大資源又價格合適的計算機來支撐自己的業務，所以轉而通過大量廉價的小型計算機一起工作來達到超級計算機的目的。當計算需求增加，只要增加小型機的數量，就可以近似線性地增加系統性能。擴展性，是分布式系統的重要考量因素。

圖7 擴展立方體

在圖7所示的擴展立方體中：

X軸代表每個結點同質（同類型、同功能），只要增加結點數就可以增加系統處理能力；

Y軸代表基于不同業務的擴展；

Z軸代表不同用戶類型（優先級、地域等）的擴展。

目前我們的系統主要是基于X軸和Y軸的擴展。

我們的存儲水平擴展方式是分表分庫，但分庫容易帶來跨庫Join的問題。我們是基于產品ID作為分表關鍵字的，基本上沒有產品之間需要關聯計算價格的場景，所以基本規避了跨庫Join的問題。

●3.2 RESTFUL調用組件

在服務治理上我們開發了一個RESTFUL的調用組件（圖8），通過它來解決服務發現/調用管理的問題。服務提供者將自身標識注冊到注冊中心，服務消費者通過注冊中心獲得可提供服務的列表。

圖8 RESTFUL調用組件

●3.3 消息隊列

我們在較多場景下使用了消息隊列。消息隊列的一個好處是解耦，在發送端看只需要將消息送到隊列，send and forget，不需要關注消息會被誰以哪種方式處理。

另外，負載均衡可以在消費側完成，發送方無感知。這樣就可以動態地增加或減少消費者數量。當然這樣做也基本上要求業務的設計是無狀態、異步化的。

四、案例總結

●4.1 架構是為業務服務的。

評價架構的優劣要看是否更好地支撐業務發展，而不是使用了什么技術。只有最適合本業務特點的架構和技術選型才是好的。所以只有深刻理解業務本身才有好的架構。

諸多開源中間件的出現，減少了業務人員需要自己實現的功能（除非開源的項目不滿足要求），而架構師也從設計實現更多地轉向對業務需求的判斷，從而進行架構決策和技術選型與模式的運用。

本案例是百億次計算量的系統優化，其實第一個應該討論的話題就是這100億次是否是必要的。事實上我們確實通過優化降低了計算量，也降低了單次計算規模，這些都是建立在對業務的理解之上的。所以架構永遠是從業務出發。

●4.2 服務之間的邊界要清晰，盡量耦合小。

DDD的思想可以幫助我們找到服務邊界。

●4.3 盡量異步化設計,這樣的耦合很小，邏輯上更清晰。

異步的系統要穩定得多，某一個系統出現瓶頸的時候還有消息中間件幫助緩沖。同步的調用在等待時(線程會阻塞）會間接影響并發和吞吐量。另外，異步的系統在升級時會更容易，系統之間的限制要小一些，可以在隊列里面積壓一些。

●4.4 無狀態省去了很多負載均衡的煩惱, 不需要做黏性。

可以很容易地做到水平擴展.有狀態系統在水平擴展時是非常痛苦的。

●4.5 小步迭代，可回滾低風險。

我們做到了每一次上線都是可回滾的，數據庫的設計在上線后的一段時間內都是向下兼容的。而且新老數據是可以并存的。

11月9-12日，北京國家會議中心，第六屆TOP100全球軟件案例研究峰會，劉曉濤：途牛研發總監將分享《天下武功唯快不破－微服務實踐快速響應瞬息萬變的市場》。

TOP100全球軟件案例研究峰會已舉辦六屆，甄選全球軟件研發優秀案例，每年參會者達2000人次。包含產品、團隊、架構、運維、大數據、人工智能等多個技術專場，現場學習谷歌、微軟、騰訊、阿里、百度等一線互聯網企業的最新研發實踐。

TOP100大會將于11月9日-12日在北京國家會議中心舉辦，在現場通過對案例的復盤總結，分享成功者背后的經驗和方法。大會開幕式單天體驗票免費入口。