實例分析途牛網站的無線架構變遷實踐之路
大小：0.6 MB 人氣： 2017-10-12 需要積分：1
標簽：無線架構(1832)
途牛從一開始的單機系統，發展到現在已擁有數百個分布式部署的系統。本文主要將途牛網站無線系統在從小到大的過程中，遇到的問題以及解決方法與大家分享，希望為大家帶來一定借鑒。文章將從服務化推進、南北京機房之痛、性能提升實踐、App客戶端技術演進四個方面進行介紹。服務化推進
途牛的服務化始于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年開始構建，架構上也經歷了四個階段：同步架構、異步架構、并發架構和分布式架構，如圖1所示。
圖1 服務化的推薦 - 價格計算服務
同步架構：系統間主要通過接口進行交互，其他系統通過調用接口通知價格中心發起運算，價格中心通過接口獲取其他系統價格依賴的所有資源。整個計算流程采用串行模型行，效率低僅能滿足小規模的計算需求。
異步架構：系統間通過MQ進行交互，價格中心通過依賴數據庫獲取其他系統的數據，加快了數據讀取的效率，并將計算價格變成兩段：先針對一個資源多個供應商的情況，將資源的最低成本價計算好，然后再算產品最低價。這種架構比同步架構數據讀取的效率更高，并能通過預先生成數據，加快計算的速度，提升3倍整體性能。
并發架構：首先將價庫自身的數據（資源的成本價，產品團期起價）進行了分庫分表，提升了系統的數據容量，然后再根據產品的訪問頻度區分冷熱數據的計算頻率，冷數據降低計算頻率，熱數據增加計算頻率——并通過在內存中建立團期、行程、資源這三個維度的數據結構，提升計算過程中數據的讀寫效率。整體上性能比異步架構提升了3.5倍，每次每個團期的價格計算時間控制在200ms以下。
分布式架構：通過解析依賴數據庫的Binlog，將依賴數據庫的數據轉換成適合使用的內存數據庫結構，進一步提升數據讀取效率，從而解決計算過度依賴數據庫的問題，通過使用Sharding MQ，實現本地訪問、本地計算；通過使用Unix域通信的機制，實現本地通信，將每個計算實例所依賴的資源和通信盡量限制在本地服務器上，最大化提升I/O能力，降低I/O損耗。整體性能比并發架構提升2倍，每次每個團期的價格計算時間控制在100ms以下。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%