2016年5月28日，華為開發者匯南京站在安德門黑馬路演中心圓滿落幕。本次沙龍議題增加到六個，時間安排上也從之前的半天擴展到全天。講師有來自華為、蘇寧、途牛的多位好手，議題涵蓋”通訊即服務“、”內源開發“、”探索性測試“、”容器技術”、“電商平臺遷移”、“訂單架構優化”。

來自途牛網訂單研發中心副總經理高建給大家帶來的是《途牛價格中心的架構》。一開始筆者以為他只是要說IT架構，聽到一半才發現高建的厲害之處 —— 他很熟悉業務!

高建從旅游行業的定價特點、價格中心的計算方法、價格中心的實時計算與存儲架構等方面給大家上了一堂生動的“旅游行業線上業務架構”課程。通過這個議題，我們也能看出：作為一個技術人員，對業務的理解程度是可以決定自己今后職業高度的。

現場實錄：

大家好，我叫高建，非常高興能跟大家做一個分享。我來自途牛，在途牛待了六年，基本途牛80%的系統我都接觸過，都有帶過團隊做過開發。今天主要給大家介紹途牛的價格中心，這個是針對一個具體問題的說明或者是分享，可能會講的比較細一點，所以有任何問題我們隨時交流。

其實每個電商系統都會有價格中心，但是途牛作為一個旅游電商，它的價格中心還是有一些特點的。首先我們看一下旅游行業價格中心有一些怎樣的特點?這是一個去馬代的線路，首先一個產品會有團期的概念，可能有6月份、7月份、8月份，有三個月或者六個月的團期，每個團期會有一個價格。這里的價格也是不固定的，會有很多的因素影響。比如去馬代，馬代的產品是由酒店和機票組成的，機票又有ABC三個選項，酒店又有豪華房、海景房，不同房間的選項，這些因素的變化都會引起界面上顯示的價格的變化。現在價格中心最重要的任務是讓客戶能夠準確的看到上面的促銷價，以及每一個團期的***價，讓用戶更加準確。不然的話用戶在上面訂了一個產品一千塊，等他下單的時候變成九百塊，這時候他就會非常郁悶，一定會引起投訴，我們價格中心主要是解決這個問題。

旅游很大的趨勢就是碎片化，比如我們的資源包括這么多，最重要的就是機票和酒店，慢慢的也會有門票、簽證、保險，跟團是一個打包資源，最近我們又加了一些新的資源，比如像通信、領隊、火車票等等。碎片化越來越嚴重，也就是說用戶在旅游的時候選擇的資源會越來越豐富。不像以前我整體打包一個給你，你就去海南，跟團去玩就好了，現在用戶需求越來越多，這是我們面臨的問題。

資源越多，價格計算也就越復雜。這是我們價格中心所要計算的價格，首先是產品起價，在線上每一個產品如果在列表上面***都有一個產品起價，這是所有團期當中***的價格。這個起價也包括促銷前的價格和促銷后的價格，一般我們會呈現促銷后的價格。這是團期起價，每一個團期會有不同的價格。我們設計的這個價格還會有成本起價，舉個簡單的例子，我們有一個金陵酒店的總統套房，總統套房可能會從多個供應商當中采購，每個供應商給出的價格也會不一樣，我們做售賣的時候對于用戶來說會選擇一個價格***的供應商的資源進行售賣，這也是我們要去計算的。

這個采購定調價是今年剛剛在做的一個大的項目，對價格中心的改造。同一個資源是為了支持它更多渠道的售賣。舉個簡單的例子，假如說我們采購酒店，在官網上賣八百塊，但是在京東上可能賣九百塊，在分銷渠道商可能賣八百五十塊。我們會針對某一個采購來的批次，在不同的渠道、不同的售賣維度上，去設定不同的加價規則。這個規則引入進來以后，對同一個資源就引入了非常海量的售賣價。這個加價規則我們一共會有七個維度，組合起來對同一個資源就***可能會有幾萬個價格，這個對我們來說也是一個非常大的挑戰。因為采購定調價，我們價格中心數據量快增加了接近一百倍，大概是這樣的一個數據規模。

***一個是促銷價，每一個團期還會有不同的促銷方案，不同的促銷方案會帶來不同的促銷價。前面我們主要是給大家介紹一下整個價格中心所要計算的價格到底是什么，從整體上來看最基本的首先是一個團期的***價，有促銷前和促銷后的價格，還有每個團期本身的價格，以及一些團期當中資源的成本價等等，這些都是我們要計算的一些東西。接下來了解這些東西之后，我們就要看一看這個價格中心實時計算的規模，以及存儲的規模。

現在大概是這樣一個情況，最左側會有一些數據庫的依賴，我們依賴了大概45臺數據庫，這塊現在主要還是外期的數據庫，比如像庫存的數據庫，或者產品的數據庫?，F在為了提升讀取的速度，我們現在直接讀取別人的同步，采用這種方式做的。一開始也考慮到直接通過http接口訪問，但是畢竟http還要比直接讀取數據庫要慢一些。所以后來我們直接去讀取其他系統的同步。中間會有兩臺接口服務器，以及八臺計算服務器。接口服務器主要是提供外系統查詢***價的服務，還有一些計算服務器。計算服務器主要就是當一些資源發生變化的時候，會觸發一些計算，以及我們會對一些產品做全面的價格計算，都是在這些服務器上?，F在我們是14臺的MySQL的存儲服務器，去存剛才提到的一些價格，比如說成本價啊，報價，原價，售價，促銷后的價格等等，大概是這樣一個，這是服務器的情況。

這是我們的計算規模，我們是從2014年8月開始價格中心的運行。到4月份平均每天被計算的次數達到八千萬，團期每天被計算的次數基本達到十三億。我們現在有的團期數是3.5億，每個團期每天會被計算三到四次，大概是這樣的一個規模。從這個數據上來看，價格中心在途牛內部系統當中是被稱作數據量與計算量***的一個系統?，F在說實話也面臨一些問題，我們在不斷的改善。

這是促銷價平均被計算的次數，我們在2016年初的時候做了一些降級處理。原先的時候，每個渠道已上線、未上線的產品都做計算，但是到今年年初算不過來了，計算服務器壓力太大，后面我們做了一些降級處理，就是未上線的產品我們不參與計算，只去計算上線的產品，所以有了一些降幅。但是現在慢慢的又增長起來，我們后續還會繼續做一些優化。

這是我們的存儲規模，左側會有報價庫和采購庫，我們也都做了一些分庫分表的操作，中間是產品庫和資源庫。產品庫和資源庫我們是采用一主多從，中間的產品和資源庫因為價格中心的讀取量、計算量實在太大了，產品系統跟資源系統也是不堪其擾，非常郁悶。一開始我們價格中心讀取數據讀取的太多了，經常被讀掛了。所以我們就采用了一主多從，不停的給產品系統和資源系統加很多很多從步，并且通過一些路由的策略，平均把產品數據和資源的報價數據等等讀取的操作，平均達到每一個從步上面去，來減少一些負載?，F在基本上是產品庫一主三從，資源庫一主四從，基本還能夠保證不被我們爬掛，大概是這樣一個情況。***這一塊是價格庫，價格庫我們也做了分庫分表，分成了1024份。

前面主要還是屬于介紹性的內容，主要是講了我們價格中心實時計算的類型，存儲規模。這邊主要介紹一下我們在價格中心不斷迭代過程當中的一些優化的點，這個里面應該還是會有蠻多實戰性的東西。我們價格中心從2014年8月份到現在大概有四個版本的迭代，我們從一開始的時候也沒有太多經驗，可以從左到右分別講一下。一開始基本是所謂的同步架構，我們主要通過http接口去資源系統當中抓取資源的***價，從產品系統當中抓取它的加價規則，等等這樣一些方式。說實話通過http接口的話，它的性能損耗是比較大的，并且也是串性的計算，復雜度也會比較高。一個產品有N個團期的話，我們采用便利的方式，這個方式也會有一些問題。帶來的問題是ON的復雜度，每算一個產品的***價的時候，它的性能消耗會比較大。

基本到第二個版本異步架構的時候，這里面我們做了一些改進。***個我們啟用MQ去異步觸發。原先基本是全量，不停的全量去計算。到了第二個版本通過MQ去異步觸發。比如說一個酒店房型的成本價被供應商編輯了，或者一個機票的價格被供應商編輯了，這時候觸發一條消息，把這個酒店所關聯的所有的產品價格都要更新一下。這時候他通過一條消息發到我們價格中心，這時候價格中心開始做計算了。第二塊我們把它改成了，直接從依賴庫抓數據，而不是通過http接口。引入半步計算，串性計算，這里的半步計算主要還是我們在算價格的時候分成了兩步，先算資源的成本價，先把資源的成本價算出來存儲在那個地方。原先的地方因為資源的成本價是不存儲的，算過了就丟掉了，會引起一些性能的浪費。這時候還是串性計算，對于成本報價這種數據基本是OE的復雜度。我們把從數組的存儲，從哈希改成存儲，這部分稍微提升了一些性能。所以整個異步價格概括起來就是MQ出發，依賴庫抓數據，半步計算，這樣基本我們的性能有了翻倍的提升。

到第三個版本的迭代，我們主要引入了***個是分庫分表，圖形分離。分庫分表主要是把我們報價庫拆成1024份，它的存儲是大大提升了。第二個是冷熱分離，我們做全量計算的話，對產品來說它的訪問量也是有多有少。比如有些熱門產品一天到晚被訪問，用戶很喜歡被預定，這時候我們需要確保這些產品價格的穩定性。我們也通過產品每天的PB的訪問量，去給每條產品打一個標記。對熱產品我們是每隔多長時間，比如每隔15分鐘全量計算一遍。但是對于冷的產品來說可能就不計算了。當用戶有訪問的時候我們才去計算，這種雖然慢一點，但基本上用戶還能計算，基本是這樣一個冷熱模型。

第四個我們采用了一些三維內存模型，我們在構造產品起價計算的時候，通過三維模型，其實就是構造一個數，能夠很方便、很快速的抓取到產品的各項資源數據，能夠提升它的一些計算速度，在多行程和多資源的時候降低了一些復雜性?；驹诘谌姹镜臅r候我們從業務上引入了一個多行程的概念。一個產品可能會分成多個行程，在旅游早期，比如在2015年之前，其實一個產品只有一個行程，但是隨著自有產品越來越多，一個產品會有多個行程。舉個例子，我們去港澳游，比如說南京先飛香港是一個行程，香港到澳門又是第二個行程，可能澳門還會有繼續的行程，可能會有多個行程。這種增加行程的概念對我們價格中心也是增加了一個維度的計算，原先只有一個行程，變成兩個行程的話，這時候他的價格，計算的復雜度會乘以2。在這種多行程、多資源的情況下，通過三維內存模型，也有效的降低了它的復雜度。

這時候我們有了并發計算，因為一個產品可能會有多個行程，每個行程下面會有不同的資源組成，每個資源在不同團期的報價我們是把它作為一個***的計算單元。這時候同一個產品下面，如果說有多個資源報價的時候，這時候會去做并發的計算，有效的提升一些性能，所以整個并發架構主要是這些改進。

我們現在所謂的叫分布式架構，主要的改動點在第二、第三點。第四點現在沒有太好的應用。第二點主要是采用MQ的方式降壓，簡單來講，因為外部可能會有非常多的數據請求進來，比如要求我們重新計算價格。原先我們是一個數據提供者，多個數據消費者。因為他要取數據消費的時候，有時候可能會存在大家都去取到同一條數據計算，這樣會浪費一些性能。我們在MQ通過一些鎖機制，確保同一個產品的***價同時只能夠被一個消費者消費，通過一些鎖機制的設定，可以確保一對一的計算，也可以做一些壓力的降低。

第三點主要是分布式的內存存儲，分布式內存存儲是怎么樣一個應用場景呢。比如說產品資源的價格做一些變更的時候，我們現在主要是通過定時的抓從步的數據，知道變更了，應該說它是一個變動式的計算。我們怎么去更加實時的做這個計算，我們是希望在資源變價的時候，它的某一個資源價格變更了，我們就可以直接把數據通過MySQL(23：02)的方式，去讀取MySQL(23：07)的方式，把這個變更的數據抓取到。抓取之后我們再去實時的對資源所在的產品進行價格變更。這塊主要是把底層數據的變更，通過MySQL(23：32)解析的方式知道它的變更，知道變更之后能夠更加及時的做一些數據計算，主要是這樣一個過程。

第四個NoSQL的存儲我們現在沒有太多的用。這就是我們整個架構中心四步架構的優化，大概是這樣的一些點。

這個主要是三維數據模型，就不詳細講了。

這個是我們的實時并發計算，我們在內存當中構造了一個數，每一個產品可能有多個行程，行程1、行程2。一個行程下面資源也有不同的組合方式，每個資源下面有團期，應該說每一個R就是我們的最小計算單元。我們通過并發會有一個行程池管理這些計算單元，做一些并發計算。

還有***五分鐘，我簡單介紹一下，這是我們整體的架構。前面講了這么多，從整體上看可以分成左邊和右邊，上面是一些外部系統的數據庫，我們有一層適配器，這塊我們現在還做的比較弱，但是未來我們會不斷的加強，主要是做一些留空的策略，這些外部系統如果有資源變價的話，會直接進到我們的MTO里面。MTO首先會做每個資源的成本計算，做完之后會通過下面的分發節點，路由到不同的MTO當中去，做串性的計算，在串性的節點當中順序的把每一個產品取出來，***做一些數據存儲。大概整個是這樣一個架構。

這塊跟前面差不多，我就不詳細講了，高并發場景下的問題及其解決辦法，這個是一些我們在過程當中遇到的問題，我簡單講一下。我們途牛在2015年之前還是南北機房的問題，我們在南京有一個機房，在北京有一個機房，價格中心最多的還是在給北京機房的比如說網站、APP系統提供服務，所以在這個里面會導致帶寬被占的問題。比如北京的請求量非常大的時候，后續很多價格數據，這時候南北京帶寬被占滿了。這個在當時也是蠻難的問題，也就是因為這個問題，我們在2015年初的時候決定把南北京機房合并了，是在2015年8月份，現在我們途牛所有的機器都在南京機房里面。

在當時的情況下，也就是做冷熱分離，對于冷數據可能是只有被訪問的時候才會被計算，熱數據是定時批量的計算。第二個是并發查詢，更新時連接不夠用。剛才我們看到的圖當中有一個并發計算單元，一個產品下面會掛很多資源，在資源數比較少的時候還OK。但是在一個產品上面，如果掛的資源數超過10個，甚至15個的時候，它對依賴庫，可能瞬間的把依賴庫連接數給占滿了。這時候可能就導致其他的一些計算很難進行，就被等待。這時候我們做了一個連接數的控制，就把每一個并發計算單元所擁有的連接數控制在4個，能夠讓單個計算的稍微慢一點，但是你不要影響別人，大概是這樣的情況。

其他我們也做了一些實時分析、離線分析等工作，這個就不詳細介紹了。

今天基本演講就到這邊，大家有沒有什么問題。

提問：我來問一個問題，你們家的數據選用的是MySQL，一般數據庫要么選的是甲骨文，一般選的是(29：47)，你們家選用的是MySQL，我想請你介紹一下MySQL的優點和缺點，甲骨文有什么缺點?

嘉賓：MySQL一般基本都是開源的數據庫，首先MySQL是開源的，對于構建成本來說，因為一開始基本互聯網公司都沒錢，成本會低一點，一個甲骨文動輒幾十萬，甚至上百萬，我們是買不起的，這是***點。第二個，MySQL上面非常靈活，它的數據同步，主從同步的機制，可以讓我們很快速的橫向的擴展我們的應用。但是說實話甲骨文我沒有非常深入的應用，所以這塊你說甲骨文有什么缺點，我沒有辦法回答你。

提問：我想問一下比如你們是做旅游的，以前聽說南北機房是分開的，你們現在做了一個整合，如果在某個時段，馬上快暑假了，七日游肯定會很多，或者自駕游。如果大量的涌入時段，你做了促銷，大量的數據進行訪問服務器的話，你那邊有沒有方式保證你那個服務器是正常的，或者說到一個時候會有一些癱瘓或者怎么樣。

嘉賓：這是每家電商公司都必須有的技能，剛才蘇寧的同事也講了很多，我們其實跟他們也差不多。首先會有流控，前端會有流量控制，最簡單的例子，你的IP不可能同時一分鐘訪問多少次，如果訪問多少次我就把你限流了，就要求你輸入驗證碼，這是***塊。第二塊像后端的緩存，基本上互聯網公司都是讀多寫少，所以基本所有的頁面，商品頁，首頁等等，這些都是放在緩存里面的，這個緩存當然也會有分級，有大的緩存和小的緩存，應該說大的頁面的緩存，小的數據的緩存。后端還會有一些分布式的服務去提供給這些緩存，當它失效的時候來用。這個要講起來是蠻復雜的。

提問：我想問一下你們這邊有沒有遇到，比如我們把平時的業務數據從業務系統里面抽出來，抽到大數據，做OLAP之后，再重新放出來做存儲MPP的模式，這種場景。

嘉賓：會。

提問：這種時候我們在數據，慣性數據出來之后，做了OLAP，再重新做MPP的話，MPP這塊是用什么技術。

嘉賓：您說的MPP是什么?

提問：大規模并發網絡，比如說我們重新把這個業務開放。

嘉賓：我了解。舉個例子，我們途牛產品的排序其實就是通過這種方式做的，比如說產品的排序說實話是一個很復雜的規則，它需要算每一個產品的權重，這個權重又是通過很大量的數據，比如說可能是用戶的點評，或者是每天被訪問的次數，等等很多很多的維度數據一起算出來的。這時候的數據我們就是把它抽取出來，通過OLP的方式把它分析出來。最終我們會通過OLP，其實就是輸出一張數據表，比如每個產品會對應它的一個權重的最終值。輸出這樣一張數據表之后，當然前端會有構建一些服務了，這個可能和一些普通的高并發的應用差不多。比如首先是主從，一主多從，去增強數據庫的并發量，前端可能也會有多個實例，去承載更多的并發量，大概是這樣的一種情況。

提問：我們這邊MPP本身也是SQL兼容的，還是有專門的?

嘉賓：我們就是SQL兼容的，我們就是直接輸出一些數據。

提問：直接輸出到那個庫里面。

嘉賓：對。

提問：高老師，看了你的分享之后，發現價格計算這塊也挺復雜的。因為這個業務邏輯復雜，引入了很多制度性的東西，采用很多制度手段，但是這樣從制度的角度出發，感覺太復雜化了。現在隨著云計算、云存儲這些東西的成熟之后，是不是里面優化的東西可以去掉，這樣就直接一點，我就關心我的業務邏輯，沒考慮導致后面的服務不方面嗎，投入這么大。

嘉賓：你說考慮往云上面遷移。

提問：現在很多問題是不是沒有那么復雜。

嘉賓：首先是業務邏輯的復雜性，因為旅游行業確實沒辦法降低。我們確實在目前價格中心，資源這塊是蠻大的瓶頸，比如計算資源和存儲資源這一塊。比如說云計算能夠幫我們動態的擴容，我們也可以考慮往這方面做一些遷移。但是目前我們在途牛主要還是考慮私有云的方案。

提問：現在不是好多大公司都在推云計算嗎，我自己沒有親身的感受，但是這塊目前的性能來看還是達不到你剛才說的要求嗎，現在是一個階段。

嘉賓：能不能達到要求還是要看具體的情況。

提問：寬帶啊，存儲啊，我現在聽到的、感受到的都有大的發展。我一直覺得把業務邏輯，把技術的東西搞的太復雜了，我想簡單，就關心業務。

嘉賓：所以這塊確實是可以考慮往云上面遷移，因為云的彈性對我們來說是非常非常大，現在我們途牛也在構建自己的私有云。

提問：兩個問題。***個，我想問一下途牛有沒有什么軟件、工具可以開源出來，有這個計劃。第二個，有沒有類似開放平臺這樣子的，可以支持其他更擴大一個生態圈的計劃。

嘉賓：***個開源是實話我們暫時還沒有，我們內部有在做一些項目了，但是還沒有最終開源出來，后面也是一個方向。第二個，是否有一些開放平臺，我們有，這個可能沒有大規模的宣傳，主要是在供應鏈這一塊，我們有一些開放的API可以支持，比如讓我們的供應商把產品、訂單這樣一些數據接入到我們的系統當中去。最近也在做所謂的叫低類，就是自己生產的一些系統，這樣的一些系統就是你說的能夠把它產品訂單都能夠開放出去的平臺，這個應該也是我們2016年、2017年這兩年的戰略重點。

主持人：因為時間的關系，我們先問答到這邊，掌聲謝謝高老師。

(結束)