途牛從一開始的單機(jī)系統(tǒng)，發(fā)展到現(xiàn)在已擁有數(shù)百個(gè)分布式部署的系統(tǒng)。本文主要將途牛網(wǎng)站無線系統(tǒng)在從小到大的過程中，遇到的問題以及解決方法與大家分享，希望為大家?guī)硪欢ń梃b。文章將從服務(wù)化推進(jìn)、南北京機(jī)房之痛、性能提升實(shí)踐、App客戶端技術(shù)演進(jìn)四個(gè)方面進(jìn)行介紹。
服務(wù)化推進(jìn)
途牛的服務(wù)化始于2011年，當(dāng)時(shí)途牛主要進(jìn)行了會(huì)員的服務(wù)化，2012年進(jìn)行了搜索2.0的服務(wù)化，2013年是服務(wù)化大舉前進(jìn)的時(shí)刻，主要進(jìn)行了搜索3.0、價(jià)格中心、訂單中心、產(chǎn)品基礎(chǔ)數(shù)據(jù)等系統(tǒng)的服務(wù)化，2014年將TSP（途牛服務(wù)治理平臺(tái)）、業(yè)務(wù)公共系統(tǒng)、資源搜索系統(tǒng)等進(jìn)行服務(wù)化，2015年對(duì)產(chǎn)類目、開放API進(jìn)行服務(wù)化。
從上面的過程可以看出，途牛的服務(wù)化不是一蹴而就的，而是經(jīng)歷了一個(gè)漫長(zhǎng)的過程，每一次拆分都相當(dāng)于為高速行駛的汽車更換輪胎的過程?？梢宰⒁獾?，在2012年途牛拆分了一個(gè)搜索2.0，之后很快又在2013年推出了搜索3.0。
這兩個(gè)版本的區(qū)別是：做搜索2.0一開始沒有什么經(jīng)驗(yàn)，雖然采用了Solr這樣非常成熟的開源搜索引擎來搭建搜索平臺(tái)，但是沒有明確界定搜索平臺(tái)和業(yè)務(wù)系統(tǒng)之間的關(guān)系，導(dǎo)致搜索平臺(tái)的邏輯非常重，被當(dāng)成一個(gè)數(shù)據(jù)聚合的平臺(tái)來使用，網(wǎng)站列表頁數(shù)據(jù)和詳情頁數(shù)據(jù)都從搜索中出來，導(dǎo)致搜索獲取數(shù)據(jù)源部分的邏輯非常復(fù)雜，搜索開發(fā)人員將70%的時(shí)間都放在和業(yè)務(wù)系統(tǒng)對(duì)接邏輯的處理上，索引效率也比較低，從而導(dǎo)致性能不穩(wěn)定，逐漸退役。吸取教訓(xùn)后，途牛搭建了搜索3.0的平臺(tái)，僅僅提供列表搜索，統(tǒng)一列表字段，將數(shù)據(jù)推送邏輯移到搜索外部，由各個(gè)產(chǎn)品系統(tǒng)來進(jìn)行數(shù)據(jù)推送，搜索本身專注于性能的提升與穩(wěn)定性，并逐步加入智能排序、人工干預(yù)搜索結(jié)果功能。迄今為止，搜索3.0是途牛公司最為穩(wěn)定的系統(tǒng)。
接下來是服務(wù)化過程中，技術(shù)層面做得比較好的兩個(gè)服務(wù)：價(jià)格計(jì)算服務(wù)和服務(wù)治理平臺(tái)。
價(jià)格計(jì)算服務(wù)
從技術(shù)上，價(jià)格計(jì)算服務(wù)有兩個(gè)難點(diǎn)：一個(gè)是團(tuán)期價(jià)格依賴的因素較多，并且依賴路徑較深；另一個(gè)是這些因素價(jià)格變動(dòng)的頻率較高，尤其在旺季。因此從設(shè)計(jì)上，價(jià)格計(jì)算服務(wù)必須要有較大的容量要求，同時(shí)具有實(shí)時(shí)性。
價(jià)格計(jì)算服務(wù)從13年開始構(gòu)建，架構(gòu)上也經(jīng)歷了四個(gè)階段：同步架構(gòu)、異步架構(gòu)、并發(fā)架構(gòu)和分布式架構(gòu)，如下圖所示。
同步架構(gòu)：系統(tǒng)間主要通過接口進(jìn)行交互，其他系統(tǒng)通過調(diào)用接口通知價(jià)格中心發(fā)起運(yùn)算，價(jià)格中心通過接口獲取其他系統(tǒng)價(jià)格依賴的所有資源。整個(gè)計(jì)算流程采用串行模型行，效率低僅能滿足小規(guī)模的計(jì)算需求。
異步架構(gòu)：系統(tǒng)間通過MQ進(jìn)行交互，價(jià)格中心通過依賴數(shù)據(jù)庫獲取其他系統(tǒng)的數(shù)據(jù)，加快了數(shù)據(jù)讀取的效率，并將計(jì)算價(jià)格變成兩段：先針對(duì)一個(gè)資源多個(gè)供應(yīng)商的情況，將資源的最低成本價(jià)計(jì)算好，然后再算產(chǎn)品最低價(jià)。這種架構(gòu)比同步架構(gòu)數(shù)據(jù)讀取的效率更高，并能通過預(yù)先生成數(shù)據(jù)，加快計(jì)算的速度，提升3倍整體性能。
并發(fā)架構(gòu)：首先將價(jià)庫自身的數(shù)據(jù)（資源的成本價(jià)，產(chǎn)品團(tuán)期起價(jià)）進(jìn)行了分庫分表，提升了系統(tǒng)的數(shù)據(jù)容量，然后再根據(jù)產(chǎn)品的訪問頻度區(qū)分冷熱數(shù)據(jù)的計(jì)算頻率，冷數(shù)據(jù)降低計(jì)算頻率，熱數(shù)據(jù)增加計(jì)算頻率——并通過在內(nèi)存中建立團(tuán)期、行程、資源這三個(gè)維度的數(shù)據(jù)結(jié)構(gòu)，提升計(jì)算過程中數(shù)據(jù)的讀寫效率。整體上性能比異步架構(gòu)提升了3.5倍，每次每個(gè)團(tuán)期的價(jià)格計(jì)算時(shí)間控制在200ms以下。
分布式架構(gòu)：通過解析依賴數(shù)據(jù)庫的Binlog，將依賴數(shù)據(jù)庫的數(shù)據(jù)轉(zhuǎn)換成適合使用的內(nèi)存數(shù)據(jù)庫結(jié)構(gòu)，進(jìn)一步提升數(shù)據(jù)讀取效率，從而解決計(jì)算過度依賴數(shù)據(jù)庫的問題，通過使用Sharding MQ，實(shí)現(xiàn)本地訪問、本地計(jì)算；通過使用Unix域通信的機(jī)制，實(shí)現(xiàn)本地通信，將每個(gè)計(jì)算實(shí)例所依賴的資源和通信盡量限制在本地服務(wù)器上，最大化提升I/O能力，降低I/O損耗。整體性能比并發(fā)架構(gòu)提升2倍，每次每個(gè)團(tuán)期的價(jià)格計(jì)算時(shí)間控制在100ms以下。
通過上面幾個(gè)階段的優(yōu)化，價(jià)格計(jì)算服務(wù)的整體架構(gòu)如下圖所示。
其中分發(fā)節(jié)點(diǎn)中的計(jì)算成本節(jié)點(diǎn)就是一些預(yù)處理節(jié)點(diǎn)，主要計(jì)算資源成本價(jià)，物理機(jī)中的計(jì)算節(jié)點(diǎn)是實(shí)際執(zhí)行價(jià)格計(jì)算的單元節(jié)點(diǎn)。調(diào)度節(jié)點(diǎn)通過一定路由規(guī)則，將價(jià)格計(jì)算分片到不同機(jī)器上，Binlog同步的時(shí)候也會(huì)按照類似規(guī)則，將數(shù)據(jù)同步到不同存儲(chǔ)節(jié)點(diǎn)物理機(jī)，從而整體上實(shí)現(xiàn)本地存儲(chǔ)、本地計(jì)算。
截止到2015年5月，價(jià)格計(jì)算服務(wù)每天的計(jì)算量在9億次左右，每個(gè)團(tuán)期平均每天被計(jì)算2次以上。價(jià)格計(jì)算服務(wù)始終在I/O能力和計(jì)算效率上不斷迭代改進(jìn)，期待未來能夠有更好的架構(gòu)出現(xiàn)。
服務(wù)治理平臺(tái)
隨著服務(wù)化推進(jìn)越來越深入，每個(gè)系統(tǒng)提供的接口也越來越多，整個(gè)系統(tǒng)逐漸產(chǎn)生了這樣一些問題：網(wǎng)狀接口調(diào)用；接口中存在循環(huán)依賴，可能引起雪崩效應(yīng)；服務(wù)調(diào)用缺乏監(jiān)控；使用硬件實(shí)現(xiàn)負(fù)載均衡，可維護(hù)性較差。針對(duì)這些問題，途牛急需一套服務(wù)治理平臺(tái)來將所有的服務(wù)管理起來。
基于開源的服務(wù)治理平臺(tái)，途牛進(jìn)行了部分定制，很快將適合于途牛的服務(wù)治理平臺(tái)搭建起來，架構(gòu)如下圖所示。
其中注冊(cè)中心采用主從模式進(jìn)行集群部署，“主”進(jìn)行服務(wù)地址的變更及心跳的保持，“從”提供查詢服務(wù)。主從之間建立長(zhǎng)連接，保持心跳。“主”宕機(jī)后，“從”接替，變更自己的身份標(biāo)識(shí)。注冊(cè)中心各個(gè)部署的實(shí)例只有獲得“主”身份才能接受客戶端長(zhǎng)連接請(qǐng)求。各個(gè)服務(wù)提供者、服務(wù)消費(fèi)者感知“主”宕機(jī)后，嘗試連接“從”，并與之建立長(zhǎng)連接，使用SQLLite數(shù)據(jù)庫持久化服務(wù)列表，使用高可用的內(nèi)存緩存保存可用服務(wù)地址列表，與服務(wù)提供者、服務(wù)消費(fèi)者之間建立長(zhǎng)連接，維持心跳。
服務(wù)提供者啟動(dòng)之后，通過通用組件將提供的服務(wù)告之注冊(cè)中心，注冊(cè)中心更新可用服務(wù)地址列表。如果該服務(wù)沒有審核記錄，則作為新服務(wù)待審核。新服務(wù)提交到注冊(cè)中心后，注冊(cè)中心不會(huì)更新到可用服務(wù)列表，需要人工在管理頁面進(jìn)行審核通過后才能進(jìn)入使用，被服務(wù)消費(fèi)者感知。
服務(wù)提供者發(fā)生宕機(jī)，心跳中斷的情況，注冊(cè)中心將更新可用服務(wù)地址列表，刪除提供者的所有服務(wù)，并發(fā)出變更通知。心跳具有重連保持機(jī)制。一定時(shí)間內(nèi)無心跳才斷開連接。服務(wù)提供者使用連接池，控制長(zhǎng)連接的數(shù)目，設(shè)置最高連接數(shù)。如果連接數(shù)得到最高限制，則拒絕新的連接接入，保證當(dāng)前系統(tǒng)的可用性。
管理頁面上可以查詢服務(wù)、查看服務(wù)詳細(xì)情況及可用服務(wù)地址列表，查看服務(wù)消費(fèi)者列表，新上線服務(wù)的審核，待下線服務(wù)的禁止，實(shí)時(shí)調(diào)整某個(gè)服務(wù)的負(fù)載均衡策略，對(duì)某個(gè)服務(wù)提供者進(jìn)行降權(quán)、倍權(quán)、禁用、允許操作。
南北京機(jī)房之痛
本節(jié)主要介紹途牛的機(jī)房部署策略。在2014年以前，途牛基本上都維持了南北京機(jī)房的結(jié)構(gòu)，在當(dāng)時(shí)的情況下，這種策略基本上還是比較合理的，但是隨著應(yīng)用體量越來越大，逐步出現(xiàn)了問題，途牛在2015年變成了南京單機(jī)房的策略，未來途牛將向兩地三中心這種更加穩(wěn)定、高可用的架構(gòu)演變。
南北京單機(jī)房的策略，在設(shè)計(jì)之初，很好的滿足了業(yè)務(wù)需求。在2010年以前，途牛70%以上的訂單均為電話訂單，加上旅游訂單的預(yù)訂流程又比較復(fù)雜，需要客服人工參與的環(huán)節(jié)較多，途牛需要將訂單系統(tǒng)部署在南京機(jī)房，以便為途牛的客服提供好的用戶體驗(yàn)。同時(shí)為了給互聯(lián)網(wǎng)用戶提供更好的機(jī)房條件，途牛需要將網(wǎng)站部署在北京。在這種機(jī)房架構(gòu)下，途牛進(jìn)行了大量系統(tǒng)優(yōu)化工作，主要是為了解決異地機(jī)房之間的數(shù)據(jù)同步問題。
首先針對(duì)網(wǎng)站數(shù)據(jù)“讀多寫少”的特征，途牛對(duì)每一個(gè)子系統(tǒng)，均采用如下的典型系統(tǒng)設(shè)計(jì)，如圖4所示。
南北京之間通過數(shù)據(jù)庫的主從同步機(jī)制進(jìn)行數(shù)據(jù)同步，北京機(jī)房的應(yīng)用讀取北京的數(shù)據(jù)庫，通過專線寫入南京的數(shù)據(jù)庫，從而確保兩邊數(shù)據(jù)的一致性。
該設(shè)計(jì)方案在系統(tǒng)容量小的時(shí)候，可以很好地運(yùn)行，但是在專線不穩(wěn)定的情況下，會(huì)產(chǎn)生較多問題，最常見的是數(shù)據(jù)同步延遲，比如用戶在網(wǎng)站注冊(cè)后，無法立刻登錄。針對(duì)這個(gè)問題，途牛采用了熔斷的設(shè)計(jì)方案，使用特定進(jìn)程監(jiān)控?cái)?shù)據(jù)庫同步延遲，如果延遲達(dá)到上限，將嘗試使用公網(wǎng)VPN進(jìn)行同步，當(dāng)專線情況好轉(zhuǎn)時(shí)，再切換回去。
另外為了控制數(shù)據(jù)同步的數(shù)據(jù)量，所有數(shù)據(jù)同步均采用了壓縮機(jī)制，最大限度減少同步的數(shù)據(jù)量。同時(shí)途牛也不斷擴(kuò)大專線的容量。
隨著業(yè)務(wù)不斷增長(zhǎng)，同步的數(shù)據(jù)量越來越多，這種部署架構(gòu)遇到的挑戰(zhàn)越來越大，最終在2015年初，途牛將兩地機(jī)房進(jìn)行合并。中途最大挑戰(zhàn)是南京機(jī)房的網(wǎng)絡(luò)條件問題，當(dāng)時(shí)南京地區(qū)尚無接入條件較好的多線BPG機(jī)房，為了給全國(guó)用戶提供較好的網(wǎng)絡(luò)服務(wù)，途牛最終采用了動(dòng)態(tài)CDN方案，南京機(jī)房出口僅提供電信出口的IP。對(duì)聯(lián)通、移動(dòng)的用戶通過動(dòng)態(tài)域名解析，解析到本地較近中轉(zhuǎn)服務(wù)器，再由中轉(zhuǎn)服務(wù)器優(yōu)化路由訪問南京的電信線路。該方案能為全國(guó)用戶提供良好的網(wǎng)絡(luò)服務(wù)。
在整個(gè)服務(wù)器部署成本上，途牛至少降低了30%，一是避免了同一套系統(tǒng)在南北京部署兩份，二是節(jié)省了大量的專線費(fèi)用。
目前的單機(jī)房策略，是一個(gè)過渡方案，為了保證系統(tǒng)進(jìn)一步的高可用和數(shù)據(jù)的安全性，途牛后期將向標(biāo)準(zhǔn)的兩地三中心機(jī)房部署策略邁進(jìn)。
性能優(yōu)化
性能優(yōu)化主要介紹途牛在優(yōu)化過程中總結(jié)出來幾個(gè)工具，途牛的思路是：首先，不斷推進(jìn)架構(gòu)演變，系統(tǒng)劃分整理，提前對(duì)資源進(jìn)行擴(kuò)展，保證總體的承載能力。然后，不斷推進(jìn)監(jiān)控完善，性能指標(biāo)具體化，發(fā)現(xiàn)問題、解決問題，保證總體的穩(wěn)定能力。主要由這樣三個(gè)工具實(shí)現(xiàn)：CODIS、BWT、OSS。
Codis是豌豆莢使用Go和C語言開發(fā)，以代理方式實(shí)現(xiàn)的一個(gè)Redis分布式集群解決方案，且完全兼容Twemproxy。Codis底層會(huì)處理請(qǐng)求的轉(zhuǎn)發(fā)、不停機(jī)的數(shù)據(jù)遷移等工作。所有底層的處理, 對(duì)于客戶端來說都是透明的。總之，可以簡(jiǎn)單地認(rèn)為后臺(tái)連接的是一個(gè)內(nèi)存無限大的Redis服務(wù)。途牛從無緩存，到文件緩存，到Memcache緩存，到今天的Codis緩存，緩存是大型架構(gòu)的必然。
使用Codis后，應(yīng)用端不需要再關(guān)心緩存具體存放在哪里，不需要關(guān)心緩存擴(kuò)容和數(shù)據(jù)遷移的工作，不需要關(guān)心緩存數(shù)據(jù)一致性的問題，極大提升了應(yīng)用開發(fā)和維護(hù)的效率。
BWT是途牛自主開發(fā)的一個(gè)主動(dòng)緩存更新服務(wù)，為了進(jìn)一步提升頁面的生成效率，應(yīng)用系統(tǒng)發(fā)生數(shù)據(jù)變更時(shí)，將要更新的數(shù)據(jù)請(qǐng)求發(fā)到BWT中，BWT根據(jù)設(shè)置好的更新策略，對(duì)緩存進(jìn)行更新。應(yīng)用系統(tǒng)推送過來的數(shù)據(jù)，一般會(huì)延時(shí)3分鐘，進(jìn)行更新。同時(shí)BWT也會(huì)通過日志分析出來的熱點(diǎn)數(shù)據(jù)，會(huì)根據(jù)設(shè)置的時(shí)間自動(dòng)更新。更新的過程中，若目標(biāo)機(jī)器負(fù)載高，會(huì)自動(dòng)停止更新。
OSS也是途牛自主研發(fā)的一個(gè)網(wǎng)站運(yùn)營(yíng)監(jiān)控系統(tǒng)，該系統(tǒng)初期目標(biāo)是對(duì)網(wǎng)站的性能、可用性和安全的進(jìn)行監(jiān)控和管理。后期將獨(dú)立成一個(gè)單獨(dú)的運(yùn)營(yíng)監(jiān)控系統(tǒng)，為所有系統(tǒng)提供監(jiān)控服務(wù)。圖5是OSS的系統(tǒng)結(jié)構(gòu)。
主要特點(diǎn)是使用UPD的方式將日志從應(yīng)用系統(tǒng)發(fā)送出來，盡可能降低發(fā)送日志對(duì)應(yīng)用系統(tǒng)的性能消耗。通過NSQ隊(duì)列接收日志，使用Go語言編寫的消費(fèi)進(jìn)程將日志匯總處理后，存入DB，并最終通過頁面將各種統(tǒng)計(jì)報(bào)表呈現(xiàn)出來。
網(wǎng)站的各種故障，可以通過錯(cuò)誤與性能圖表，很快找到問題。主要有依賴接口監(jiān)控，慢查SQL監(jiān)控，Memcache監(jiān)控，Redis監(jiān)控以及單頁面性能監(jiān)控。
App客戶端技術(shù)演進(jìn)
這里主要介紹途牛App在開發(fā)過程中的實(shí)踐心得，側(cè)重于線熱補(bǔ)丁和前端資源靜態(tài)化兩個(gè)方面。
1.在線熱補(bǔ)丁
由于App采用客戶端發(fā)布的方案，一旦發(fā)布出去的包有Bug，修復(fù)是一個(gè)非常頭疼的問題，傳統(tǒng)的修復(fù)方法主要有：服務(wù)器端屏蔽技術(shù)，也就是將有問題的功能暫時(shí)屏蔽掉；跳轉(zhuǎn)H5頁面，將產(chǎn)生問題的頁面直接跳轉(zhuǎn)到對(duì)應(yīng)的H5頁面；緊急發(fā)布新版本。這幾種辦法均有一定的局限性，對(duì)于服務(wù)端屏蔽技術(shù)，會(huì)增加服務(wù)端代碼復(fù)雜度并隱藏局部功能；對(duì)于跳轉(zhuǎn)到H5，會(huì)降低用戶體驗(yàn)；對(duì)于緊急發(fā)布新版本，會(huì)增加運(yùn)營(yíng)成本并降低用戶體驗(yàn)。
為此途牛引入了阿里的在線熱補(bǔ)丁技術(shù)，以便在問題發(fā)生時(shí)，能夠快速發(fā)布補(bǔ)丁包將問題解決。
2.前端資源靜態(tài)化
由于H5開發(fā)周期短，容易部署的特性，在途牛App中存在大量的H5頁面，但對(duì)于H5頁面，用戶體驗(yàn)的損失也是顯而易見。為了讓頁面中的元素更快渲染，呈現(xiàn)給用戶，途牛采用了前端資源靜態(tài)化的方案，主要思路是將H5頁面中的靜態(tài)資源提前加載，實(shí)現(xiàn)要點(diǎn)如下：
靜態(tài)資源異步加載，用戶打開App的時(shí)候異步下載或者更新靜態(tài)文件。優(yōu)化渲染，減少不必要的開銷。通過優(yōu)化DOM布局，將加載的靜態(tài)資源分組，可以打包的，優(yōu)先渲染，需要從服務(wù)器取的，后渲染，從而加快第一次進(jìn)入速度；減少第一屏DOM渲染數(shù)，使用懶加載，分步加載；優(yōu)化渲染結(jié)構(gòu)，由于App中的Webview性能低于手機(jī)瀏覽器，所以減少不必要的渲染開銷，比如減少消耗非常高的一些滾動(dòng)圖；優(yōu)化交互，有交互操作，造成DOM重排重繪的，盡量使用最小的DOM重排，將需要新加入的一些層，與原來的DOM結(jié)構(gòu)分開；使用一些3D CSS，使用GPU幫助頁面重繪。
以上就是途牛在架構(gòu)變遷過程中的一些實(shí)踐要點(diǎn)，雖然看起來有些散，但還是主要從架構(gòu)的以下三個(gè)方面進(jìn)行介紹。
邏輯架構(gòu)：服務(wù)化，如何將業(yè)務(wù)中通用的功能抽象出來，以服務(wù)的方式提供給其他各個(gè)系統(tǒng)。
物理架構(gòu)：南北京機(jī)房的設(shè)計(jì)初衷，遇到的問題，解決方案等。
系統(tǒng)架構(gòu)：非功能性的架構(gòu)，比如性能優(yōu)化，App客戶端性能改進(jìn)實(shí)踐。
隨著業(yè)務(wù)的發(fā)展，途牛的系統(tǒng)必然變得更加復(fù)雜，同時(shí)將產(chǎn)生更多技術(shù)挑戰(zhàn)，期待能夠有更多更好的實(shí)踐與大家分享。
