途牛的服務器部署及架構有哪些演進

本篇內容主要講解“途牛的服務器部署及架構有哪些演進”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“途牛的服務器部署及架構有哪些演進”吧!　

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

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

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

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

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

　主要特點是使用UPD的方式將日志從應用系統(tǒng)發(fā)送出來，盡可能降低發(fā)送日志對應用系統(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客戶端技術演進
　　這里主要介紹途牛App在開發(fā)過程中的實踐心得，側重于線熱補丁和前端資源靜態(tài)化兩個方面。
　　
1.在線熱補丁
　　由于App采用客戶端發(fā)布的方案，一旦發(fā)布出去的包有Bug，修復是一個非常頭疼的問題，傳統(tǒng)的修復方法主要有：服務器端屏蔽技術，也就是將有問題的功能暫時屏蔽掉；跳轉H5頁面，將產(chǎn)生問題的頁面直接跳轉到對應的H5頁面；緊急發(fā)布新版本。這幾種辦法均有一定的局限性，對于服務端屏蔽技術，會增加服務端代碼復雜度并隱藏局部功能；對于跳轉到H5，會降低用戶體驗；對于緊急發(fā)布新版本，會增加運營成本并降低用戶體驗。
　　為此途牛引入了阿里的在線熱補丁技術，以便在問題發(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)先渲染，需要從服務器取的，后渲染，從而加快第一次進入速度；減少第一屏DOM渲染數(shù)，使用懶加載，分步加載；優(yōu)化渲染結構，由于App中的Webview性能低于手機瀏覽器，所以減少不必要的渲染開銷，比如減少消耗非常高的一些滾動圖；優(yōu)化交互，有交互操作，造成DOM重排重繪的，盡量使用最小的DOM重排，將需要新加入的一些層，與原來的DOM結構分開；使用一些3D CSS，使用GPU幫助頁面重繪。
　　以上就是途牛在架構變遷過程中的一些實踐要點，雖然看起來有些散，但還是主要從架構的以下三個方面進行介紹。
　　邏輯架構：服務化，如何將業(yè)務中通用的功能抽象出來，以服務的方式提供給其他各個系統(tǒng)。
　　物理架構：南北京機房的設計初衷，遇到的問題，解決方案等。
　　系統(tǒng)架構：非功能性的架構，比如性能優(yōu)化，App客戶端性能改進實踐。

到此，相信大家對“途牛的服務器部署及架構有哪些演進”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！