途牛從一開始的單機系統(tǒng)，發(fā)展到現(xiàn)在已擁有數(shù)百個分布式部署的系統(tǒng)。本文主要將途牛網(wǎng)站無線系統(tǒng)在從小到大的過程中，遇到的問題以及解決方法與大家分享，希望為大家?guī)硪欢ń梃b。文章將從服務(wù)化推進、南北京機房之痛、性能提升實踐、App客戶端技術(shù)演進四個方面進行介紹。
　　
服務(wù)化推進
　　途牛的服務(wù)化始于2011年，當時途牛主要進行了會員的服務(wù)化，2012年進行了搜索2.0的服務(wù)化，2013年是服務(wù)化大舉前進的時刻，主要進行了搜索3.0、價格中心、訂單中心、產(chǎn)品基礎(chǔ)數(shù)據(jù)等系統(tǒng)的服務(wù)化，2014年將TSP（途牛服務(wù)治理平臺）、業(yè)務(wù)公共系統(tǒng)、資源搜索系統(tǒng)等進行服務(wù)化，2015年對產(chǎn)類目、開放API進行服務(wù)化。
　　從上面的過程可以看出，途牛的服務(wù)化不是一蹴而就的，而是經(jīng)歷了一個漫長的過程，每一次拆分都相當于為高速行駛的汽車更換輪胎的過程?？梢宰⒁獾剑?012年途牛拆分了一個搜索2.0，之后很快又在2013年推出了搜索3.0。
　　這兩個版本的區(qū)別是：做搜索2.0一開始沒有什么經(jīng)驗，雖然采用了Solr這樣非常成熟的開源搜索引擎來搭建搜索平臺，但是沒有明確界定搜索平臺和業(yè)務(wù)系統(tǒng)之間的關(guān)系，導致搜索平臺的邏輯非常重，被當成一個數(shù)據(jù)聚合的平臺來使用，網(wǎng)站列表頁數(shù)據(jù)和詳情頁數(shù)據(jù)都從搜索中出來，導致搜索獲取數(shù)據(jù)源部分的邏輯非常復雜，搜索開發(fā)人員將70%的時間都放在和業(yè)務(wù)系統(tǒng)對接邏輯的處理上，索引效率也比較低，從而導致性能不穩(wěn)定，逐漸退役。吸取教訓后，途牛搭建了搜索3.0的平臺，僅僅提供列表搜索，統(tǒng)一列表字段，將數(shù)據(jù)推送邏輯移到搜索外部，由各個產(chǎn)品系統(tǒng)來進行數(shù)據(jù)推送，搜索本身專注于性能的提升與穩(wěn)定性，并逐步加入智能排序、人工干預搜索結(jié)果功能。迄今為止，搜索3.0是途牛公司最為穩(wěn)定的系統(tǒng)。
　　接下來是服務(wù)化過程中，技術(shù)層面做得比較好的兩個服務(wù)：價格計算服務(wù)和服務(wù)治理平臺。
　　
價格計算服務(wù)
　　從技術(shù)上，價格計算服務(wù)有兩個難點：一個是團期價格依賴的因素較多，并且依賴路徑較深；另一個是這些因素價格變動的頻率較高，尤其在旺季。因此從設(shè)計上，價格計算服務(wù)必須要有較大的容量要求，同時具有實時性。
　　價格計算服務(wù)從13年開始構(gòu)建，架構(gòu)上也經(jīng)歷了四個階段：同步架構(gòu)、異步架構(gòu)、并發(fā)架構(gòu)和分布式架構(gòu)，如下圖所示。

同步架構(gòu)：系統(tǒng)間主要通過接口進行交互，其他系統(tǒng)通過調(diào)用接口通知價格中心發(fā)起運算，價格中心通過接口獲取其他系統(tǒng)價格依賴的所有資源。整個計算流程采用串行模型行，效率低僅能滿足小規(guī)模的計算需求。
　　異步架構(gòu)：系統(tǒng)間通過MQ進行交互，價格中心通過依賴數(shù)據(jù)庫獲取其他系統(tǒng)的數(shù)據(jù)，加快了數(shù)據(jù)讀取的效率，并將計算價格變成兩段：先針對一個資源多個供應(yīng)商的情況，將資源的最低成本價計算好，然后再算產(chǎn)品最低價。這種架構(gòu)比同步架構(gòu)數(shù)據(jù)讀取的效率更高，并能通過預先生成數(shù)據(jù)，加快計算的速度，提升3倍整體性能。
　　并發(fā)架構(gòu)：首先將價庫自身的數(shù)據(jù)（資源的成本價，產(chǎn)品團期起價）進行了分庫分表，提升了系統(tǒng)的數(shù)據(jù)容量，然后再根據(jù)產(chǎn)品的訪問頻度區(qū)分冷熱數(shù)據(jù)的計算頻率，冷數(shù)據(jù)降低計算頻率，熱數(shù)據(jù)增加計算頻率——并通過在內(nèi)存中建立團期、行程、資源這三個維度的數(shù)據(jù)結(jié)構(gòu)，提升計算過程中數(shù)據(jù)的讀寫效率。整體上性能比異步架構(gòu)提升了3.5倍，每次每個團期的價格計算時間控制在200ms以下。
　　分布式架構(gòu)：通過解析依賴數(shù)據(jù)庫的Binlog，將依賴數(shù)據(jù)庫的數(shù)據(jù)轉(zhuǎn)換成適合使用的內(nèi)存數(shù)據(jù)庫結(jié)構(gòu)，進一步提升數(shù)據(jù)讀取效率，從而解決計算過度依賴數(shù)據(jù)庫的問題，通過使用Sharding MQ，實現(xiàn)本地訪問、本地計算；通過使用Unix域通信的機制，實現(xiàn)本地通信，將每個計算實例所依賴的資源和通信盡量限制在本地服務(wù)器上，最大化提升I/O能力，降低I/O損耗。整體性能比并發(fā)架構(gòu)提升2倍，每次每個團期的價格計算時間控制在100ms以下。
　　通過上面幾個階段的優(yōu)化，價格計算服務(wù)的整體架構(gòu)如下圖所示。

其中分發(fā)節(jié)點中的計算成本節(jié)點就是一些預處理節(jié)點，主要計算資源成本價，物理機中的計算節(jié)點是實際執(zhí)行價格計算的單元節(jié)點。調(diào)度節(jié)點通過一定路由規(guī)則，將價格計算分片到不同機器上，Binlog同步的時候也會按照類似規(guī)則，將數(shù)據(jù)同步到不同存儲節(jié)點物理機，從而整體上實現(xiàn)本地存儲、本地計算。
　　截止到2015年5月，價格計算服務(wù)每天的計算量在9億次左右，每個團期平均每天被計算2次以上。價格計算服務(wù)始終在I/O能力和計算效率上不斷迭代改進，期待未來能夠有更好的架構(gòu)出現(xiàn)。
　　
服務(wù)治理平臺
　　隨著服務(wù)化推進越來越深入，每個系統(tǒng)提供的接口也越來越多，整個系統(tǒng)逐漸產(chǎn)生了這樣一些問題：網(wǎng)狀接口調(diào)用；接口中存在循環(huán)依賴，可能引起雪崩效應(yīng)；服務(wù)調(diào)用缺乏監(jiān)控；使用硬件實現(xiàn)負載均衡，可維護性較差。針對這些問題，途牛急需一套服務(wù)治理平臺來將所有的服務(wù)管理起來。
　　基于開源的服務(wù)治理平臺，途牛進行了部分定制，很快將適合于途牛的服務(wù)治理平臺搭建起來，架構(gòu)如下圖所示。

其中注冊中心采用主從模式進行集群部署，“主”進行服務(wù)地址的變更及心跳的保持，“從”提供查詢服務(wù)。主從之間建立長連接，保持心跳。“主”宕機后，“從”接替，變更自己的身份標識。注冊中心各個部署的實例只有獲得“主”身份才能接受客戶端長連接請求。各個服務(wù)提供者、服務(wù)消費者感知“主”宕機后，嘗試連接“從”，并與之建立長連接，使用SQLLite數(shù)據(jù)庫持久化服務(wù)列表，使用高可用的內(nèi)存緩存保存可用服務(wù)地址列表，與服務(wù)提供者、服務(wù)消費者之間建立長連接，維持心跳。
　　服務(wù)提供者啟動之后，通過通用組件將提供的服務(wù)告之注冊中心，注冊中心更新可用服務(wù)地址列表。如果該服務(wù)沒有審核記錄，則作為新服務(wù)待審核。新服務(wù)提交到注冊中心后，注冊中心不會更新到可用服務(wù)列表，需要人工在管理頁面進行審核通過后才能進入使用，被服務(wù)消費者感知。
　　服務(wù)提供者發(fā)生宕機，心跳中斷的情況，注冊中心將更新可用服務(wù)地址列表，刪除提供者的所有服務(wù)，并發(fā)出變更通知。心跳具有重連保持機制。一定時間內(nèi)無心跳才斷開連接。服務(wù)提供者使用連接池，控制長連接的數(shù)目，設(shè)置最高連接數(shù)。如果連接數(shù)得到最高限制，則拒絕新的連接接入，保證當前系統(tǒng)的可用性。
　　管理頁面上可以查詢服務(wù)、查看服務(wù)詳細情況及可用服務(wù)地址列表，查看服務(wù)消費者列表，新上線服務(wù)的審核，待下線服務(wù)的禁止，實時調(diào)整某個服務(wù)的負載均衡策略，對某個服務(wù)提供者進行降權(quán)、倍權(quán)、禁用、允許操作。
　　
南北京機房之痛
　　本節(jié)主要介紹途牛的機房部署策略。在2014年以前，途牛基本上都維持了南北京機房的結(jié)構(gòu)，在當時的情況下，這種策略基本上還是比較合理的，但是隨著應(yīng)用體量越來越大，逐步出現(xiàn)了問題，途牛在2015年變成了南京單機房的策略，未來途牛將向兩地三中心這種更加穩(wěn)定、高可用的架構(gòu)演變。
　　南北京單機房的策略，在設(shè)計之初，很好的滿足了業(yè)務(wù)需求。在2010年以前，途牛70%以上的訂單均為電話訂單，加上旅游訂單的預訂流程又比較復雜，需要客服人工參與的環(huán)節(jié)較多，途牛需要將訂單系統(tǒng)部署在南京機房，以便為途牛的客服提供好的用戶體驗。同時為了給互聯(lián)網(wǎng)用戶提供更好的機房條件，途牛需要將網(wǎng)站部署在北京。在這種機房架構(gòu)下，途牛進行了大量系統(tǒng)優(yōu)化工作，主要是為了解決異地機房之間的數(shù)據(jù)同步問題。
　　首先針對網(wǎng)站數(shù)據(jù)“讀多寫少”的特征，途牛對每一個子系統(tǒng)，均采用如下的典型系統(tǒng)設(shè)計，如圖4所示。

南北京之間通過數(shù)據(jù)庫的主從同步機制進行數(shù)據(jù)同步，北京機房的應(yīng)用讀取北京的數(shù)據(jù)庫，通過專線寫入南京的數(shù)據(jù)庫，從而確保兩邊數(shù)據(jù)的一致性。
　　該設(shè)計方案在系統(tǒng)容量小的時候，可以很好地運行，但是在專線不穩(wěn)定的情況下，會產(chǎn)生較多問題，最常見的是數(shù)據(jù)同步延遲，比如用戶在網(wǎng)站注冊后，無法立刻登錄。針對這個問題，途牛采用了熔斷的設(shè)計方案，使用特定進程監(jiān)控數(shù)據(jù)庫同步延遲，如果延遲達到上限，將嘗試使用公網(wǎng)VPN進行同步，當專線情況好轉(zhuǎn)時，再切換回去。
　　另外為了控制數(shù)據(jù)同步的數(shù)據(jù)量，所有數(shù)據(jù)同步均采用了壓縮機制，最大限度減少同步的數(shù)據(jù)量。同時途牛也不斷擴大專線的容量。
　　隨著業(yè)務(wù)不斷增長，同步的數(shù)據(jù)量越來越多，這種部署架構(gòu)遇到的挑戰(zhàn)越來越大，最終在2015年初，途牛將兩地機房進行合并。中途最大挑戰(zhàn)是南京機房的網(wǎng)絡(luò)條件問題，當時南京地區(qū)尚無接入條件較好的多線BPG機房，為了給全國用戶提供較好的網(wǎng)絡(luò)服務(wù)，途牛最終采用了動態(tài)CDN方案，南京機房出口僅提供電信出口的IP。對聯(lián)通、移動的用戶通過動態(tài)域名解析，解析到本地較近中轉(zhuǎn)服務(wù)器，再由中轉(zhuǎn)服務(wù)器優(yōu)化路由訪問南京的電信線路。該方案能為全國用戶提供良好的網(wǎng)絡(luò)服務(wù)。
　　在整個服務(wù)器部署成本上，途牛至少降低了30%，一是避免了同一套系統(tǒng)在南北京部署兩份，二是節(jié)省了大量的專線費用。
　　目前的單機房策略，是一個過渡方案，為了保證系統(tǒng)進一步的高可用和數(shù)據(jù)的安全性，途牛后期將向標準的兩地三中心機房部署策略邁進。
　　
性能優(yōu)化
　　性能優(yōu)化主要介紹途牛在優(yōu)化過程中總結(jié)出來幾個工具，途牛的思路是：首先，不斷推進架構(gòu)演變，系統(tǒng)劃分整理，提前對資源進行擴展，保證總體的承載能力。然后，不斷推進監(jiān)控完善，性能指標具體化，發(fā)現(xiàn)問題、解決問題，保證總體的穩(wěn)定能力。主要由這樣三個工具實現(xiàn)：CODIS、BWT、OSS。
　　Codis是豌豆莢使用Go和C語言開發(fā)，以代理方式實現(xiàn)的一個Redis分布式集群解決方案，且完全兼容Twemproxy。Codis底層會處理請求的轉(zhuǎn)發(fā)、不停機的數(shù)據(jù)遷移等工作。所有底層的處理, 對于客戶端來說都是透明的?？傊?，可以簡單地認為后臺連接的是一個內(nèi)存無限大的Redis服務(wù)。途牛從無緩存，到文件緩存，到Memcache緩存，到今天的Codis緩存，緩存是大型架構(gòu)的必然。
　　使用Codis后，應(yīng)用端不需要再關(guān)心緩存具體存放在哪里，不需要關(guān)心緩存擴容和數(shù)據(jù)遷移的工作，不需要關(guān)心緩存數(shù)據(jù)一致性的問題，極大提升了應(yīng)用開發(fā)和維護的效率。
　　BWT是途牛自主開發(fā)的一個主動緩存更新服務(wù)，為了進一步提升頁面的生成效率，應(yīng)用系統(tǒng)發(fā)生數(shù)據(jù)變更時，將要更新的數(shù)據(jù)請求發(fā)到BWT中，BWT根據(jù)設(shè)置好的更新策略，對緩存進行更新。應(yīng)用系統(tǒng)推送過來的數(shù)據(jù)，一般會延時3分鐘，進行更新。同時BWT也會通過日志分析出來的熱點數(shù)據(jù)，會根據(jù)設(shè)置的時間自動更新。更新的過程中，若目標機器負載高，會自動停止更新。
　　OSS也是途牛自主研發(fā)的一個網(wǎng)站運營監(jiān)控系統(tǒng)，該系統(tǒng)初期目標是對網(wǎng)站的性能、可用性和安全的進行監(jiān)控和管理。后期將獨立成一個單獨的運營監(jiān)控系統(tǒng)，為所有系統(tǒng)提供監(jiān)控服務(wù)。圖5是OSS的系統(tǒng)結(jié)構(gòu)。

　主要特點是使用UPD的方式將日志從應(yīng)用系統(tǒng)發(fā)送出來，盡可能降低發(fā)送日志對應(yīng)用系統(tǒng)的性能消耗。通過NSQ隊列接收日志，使用Go語言編寫的消費進程將日志匯總處理后，存入DB，并最終通過頁面將各種統(tǒng)計報表呈現(xiàn)出來。
　　網(wǎng)站的各種故障，可以通過錯誤與性能圖表，很快找到問題。主要有依賴接口監(jiān)控，慢查SQL監(jiān)控，Memcache監(jiān)控，Redis監(jiān)控以及單頁面性能監(jiān)控。
　　
App客戶端技術(shù)演進
　　這里主要介紹途牛App在開發(fā)過程中的實踐心得，側(cè)重于線熱補丁和前端資源靜態(tài)化兩個方面。
　　
1.在線熱補丁
　　由于App采用客戶端發(fā)布的方案，一旦發(fā)布出去的包有Bug，修復是一個非常頭疼的問題，傳統(tǒng)的修復方法主要有：服務(wù)器端屏蔽技術(shù)，也就是將有問題的功能暫時屏蔽掉；跳轉(zhuǎn)H5頁面，將產(chǎn)生問題的頁面直接跳轉(zhuǎn)到對應(yīng)的H5頁面；緊急發(fā)布新版本。這幾種辦法均有一定的局限性，對于服務(wù)端屏蔽技術(shù)，會增加服務(wù)端代碼復雜度并隱藏局部功能；對于跳轉(zhuǎn)到H5，會降低用戶體驗；對于緊急發(fā)布新版本，會增加運營成本并降低用戶體驗。
　　為此途牛引入了阿里的在線熱補丁技術(shù)，以便在問題發(fā)生時，能夠快速發(fā)布補丁包將問題解決。
　　
2.前端資源靜態(tài)化
　　由于H5開發(fā)周期短，容易部署的特性，在途牛App中存在大量的H5頁面，但對于H5頁面，用戶體驗的損失也是顯而易見。為了讓頁面中的元素更快渲染，呈現(xiàn)給用戶，途牛采用了前端資源靜態(tài)化的方案，主要思路是將H5頁面中的靜態(tài)資源提前加載，實現(xiàn)要點如下：
　　靜態(tài)資源異步加載，用戶打開App的時候異步下載或者更新靜態(tài)文件。優(yōu)化渲染，減少不必要的開銷。通過優(yōu)化DOM布局，將加載的靜態(tài)資源分組，可以打包的，優(yōu)先渲染，需要從服務(wù)器取的，后渲染，從而加快第一次進入速度；減少第一屏DOM渲染數(shù)，使用懶加載，分步加載；優(yōu)化渲染結(jié)構(gòu)，由于App中的Webview性能低于手機瀏覽器，所以減少不必要的渲染開銷，比如減少消耗非常高的一些滾動圖；優(yōu)化交互，有交互操作，造成DOM重排重繪的，盡量使用最小的DOM重排，將需要新加入的一些層，與原來的DOM結(jié)構(gòu)分開；使用一些3D CSS，使用GPU幫助頁面重繪。
　　以上就是途牛在架構(gòu)變遷過程中的一些實踐要點，雖然看起來有些散，但還是主要從架構(gòu)的以下三個方面進行介紹。
　　邏輯架構(gòu)：服務(wù)化，如何將業(yè)務(wù)中通用的功能抽象出來，以服務(wù)的方式提供給其他各個系統(tǒng)。
　　物理架構(gòu)：南北京機房的設(shè)計初衷，遇到的問題，解決方案等。
　　系統(tǒng)架構(gòu)：非功能性的架構(gòu)，比如性能優(yōu)化，App客戶端性能改進實踐。
　　隨著業(yè)務(wù)的發(fā)展，途牛的系統(tǒng)必然變得更加復雜，同時將產(chǎn)生更多技術(shù)挑戰(zhàn)，期待能夠有更多更好的實踐與大家分享。

版權(quán)聲明：本站文章來源標注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責任。本站部分內(nèi)容來源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來，僅供學習參考，不代表本站立場，如有內(nèi)容涉嫌侵權(quán)，請聯(lián)系alex-e#qq.com處理。