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

來自途牛網(wǎng)訂單研發(fā)中心副總經(jīng)理高建給大家?guī)淼氖恰锻九r格中心的架構(gòu)》。一開始筆者以為他只是要說IT架構(gòu)，聽到一半才發(fā)現(xiàn)高建的厲害之處 —— 他很熟悉業(yè)務(wù)!

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

現(xiàn)場實錄：

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

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

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

資源越多，價格計算也就越復(fù)雜。這是我們價格中心所要計算的價格，首先是產(chǎn)品起價，在線上每一個產(chǎn)品如果在列表上面***都有一個產(chǎn)品起價，這是所有團(tuán)期當(dāng)中***的價格。這個起價也包括促銷前的價格和促銷后的價格，一般我們會呈現(xiàn)促銷后的價格。這是團(tuán)期起價，每一個團(tuán)期會有不同的價格。我們設(shè)計的這個價格還會有成本起價，舉個簡單的例子，我們有一個金陵酒店的總統(tǒng)套房，總統(tǒng)套房可能會從多個供應(yīng)商當(dāng)中采購，每個供應(yīng)商給出的價格也會不一樣，我們做售賣的時候?qū)τ谟脩魜碚f會選擇一個價格***的供應(yīng)商的資源進(jìn)行售賣，這也是我們要去計算的。

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

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

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

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

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

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

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

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

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

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

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

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

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

第四個NoSQL的存儲我們現(xiàn)在沒有太多的用。這就是我們整個架構(gòu)中心四步架構(gòu)的優(yōu)化，大概是這樣的一些點。

這個主要是三維數(shù)據(jù)模型，就不詳細(xì)講了。

這個是我們的實時并發(fā)計算，我們在內(nèi)存當(dāng)中構(gòu)造了一個數(shù)，每一個產(chǎn)品可能有多個行程，行程1、行程2。一個行程下面資源也有不同的組合方式，每個資源下面有團(tuán)期，應(yīng)該說每一個R就是我們的最小計算單元。我們通過并發(fā)會有一個行程池管理這些計算單元，做一些并發(fā)計算。

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

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

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

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

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

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

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

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

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

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

嘉賓：會。

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

嘉賓：您說的MPP是什么?

提問：大規(guī)模并發(fā)網(wǎng)絡(luò)，比如說我們重新把這個業(yè)務(wù)開放。

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

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

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

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

嘉賓：對。

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

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

提問：現(xiàn)在很多問題是不是沒有那么復(fù)雜。

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

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

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

提問：寬帶啊，存儲啊，我現(xiàn)在聽到的、感受到的都有大的發(fā)展。我一直覺得把業(yè)務(wù)邏輯，把技術(shù)的東西搞的太復(fù)雜了，我想簡單，就關(guān)心業(yè)務(wù)。

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

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

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

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

(結(jié)束)