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

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

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

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

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

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

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

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

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