攜程的架構(gòu)經(jīng)歷了長期的演變和迭代，其中多個產(chǎn)品已經(jīng)歷了 5 次以上的更新?lián)Q代。每次迭代都有其背景和出發(fā)點，都解決了前一個版本的痛點又不可避免帶來一些新的問題或遺漏一些問題。

這種迭代過去、現(xiàn)在、將來一直持續(xù)著，其中經(jīng)歷可圈可點，值得技術(shù)人細細品味。

[[205510]]

本文先從總體介紹攜程架構(gòu)的組成，接著以發(fā)布系統(tǒng)、配置管理和 SOA 三個實際案例詳細介紹架構(gòu)迭代，最后以自己做的一個項目具體介紹攜程架構(gòu)亮點的點滴。

架構(gòu)組成

總體來說，攜程的架構(gòu)由三部分組成：運維、框架、應(yīng)用。

01運維

談到高可用和穩(wěn)定性，我們首先想到的肯定是運維。攜程的運維是應(yīng)用和架構(gòu)堅強的后盾，主要有四大亮點。

集群管理策略

攜程的 Web 集群有 slb 控制流量，根據(jù) healcheck 的結(jié)果可以自動拉出和拉入。發(fā)布和擴容過程對開發(fā)透明，當(dāng)機器 check 成功且沒有報錯時，機器將拉入集群。當(dāng) check 失敗或單位時間報錯超過閥值，機器將自動拉出集群。

FullDR 機制

Web、DB、Redis 集群都有長效的 FullDR 機制，當(dāng)一個 IDC 完全掛掉，比如網(wǎng)絡(luò)故障、網(wǎng)線拔斷等發(fā)生時，F(xiàn)ullDR 將發(fā)揮功效。攜程定期對 FullDR 進行演練，以確定DR對訂單的影響。

DBA 策略

數(shù)據(jù)的安全是重中之重，攜程將用戶數(shù)據(jù)放在穩(wěn)定的首位。我們使用 M-S 機制和 FullDR 結(jié)合保證數(shù)據(jù)的高可用。

同時為了順應(yīng)互聯(lián)網(wǎng)的發(fā)展，我們將 MSSQL 的數(shù)據(jù)無縫遷移至 MySQL，雖然花費了很多時間和成本，但是為了穩(wěn)定，投入也是值得的。同時我們保證遷移過程對用戶是透明的。

SQL+NoSQL 的結(jié)合是互聯(lián)網(wǎng)發(fā)展的趨勢，而攜程的數(shù)據(jù)存儲更是包含 MSSQL、MySQL、Redis、Hive、ES 等多種方式和技術(shù)，保證數(shù)據(jù)的高可用、最終一致性。

NOC 機制

在攜程，作為開發(fā)負責(zé)人是非常艱苦的，因為如果你負責(zé)的應(yīng)用一旦出現(xiàn)異常，NOC 7*24 小時都可能聯(lián)系你。

NOC 通過專門的訂單大圖和異常圖表監(jiān)控所有應(yīng)用的運行狀態(tài)。訂單量同比、環(huán)比的上升、下降都會被嚴(yán)密的監(jiān)控。

02框架

框架是應(yīng)用的基石，而攜程框架更是經(jīng)歷過且正在經(jīng)歷著演變和迭代。其中特別值得分享的包括：

SOA&Gateway

SOA&Gateway 是服務(wù)的治理平臺，它有著非常悠久的歷史，后面會詳細展開。

發(fā)布系統(tǒng)

攜程的發(fā)布系統(tǒng)集成了很多特色功能，比如剎車、回退、版本切換、共用 dll 打包、pom 檢測等等。

發(fā)布系統(tǒng)經(jīng)歷了歷史上最嚴(yán)重的災(zāi)難性故障，在故障中浴火重生，非常值得給大家分享其演變和迭代。

消息隊列

市面上開源的消息隊列工具非常多，包括 Storm、MSMQ、ActiveMQ、RabbitMQ 等。

攜程結(jié)合各第三方的優(yōu)點，加以融合，結(jié)合自身情況，自主研發(fā)了消息隊列。核心功能有 Partition 有序、異步補償和消息生命周期跟蹤。

配置管理

配置管理在任何規(guī)模的公司都會做，而對配置而言最重要的不外乎是便捷、高效和高性能。攜程配置管理的演變恰恰反映了這種趨勢。

03應(yīng)用

經(jīng)過和多家知名互聯(lián)網(wǎng)企業(yè)架構(gòu)師溝通，我們發(fā)現(xiàn)大家的應(yīng)用架構(gòu)都是比較相近的，一般都會用到 PreLoading&LayerLoading、Sharding、熔斷、限流、降級等技術(shù)。

而經(jīng)過無數(shù)經(jīng)驗證明，上述措施確實極大的提升了網(wǎng)站和 APP 的穩(wěn)定性。比如，當(dāng)災(zāi)難發(fā)生時，PreLoading 可以保證用戶可以看到預(yù)設(shè)的內(nèi)容;而網(wǎng)絡(luò)情況較差情況下，LayerLoading 可以保證用戶操作不卡頓。

架構(gòu)演變

01發(fā)布系統(tǒng)

攜程發(fā)布系統(tǒng)至今大體經(jīng)歷了如下四個“年代”：

• ITSM。
• CITSM。
• CRoller(ROP)。
• Tars(CD)。

說到發(fā)布，一定要提一下 “最傳統(tǒng)”的發(fā)布方式。傳統(tǒng)公司會有專門的售后團隊負責(zé)部署、或直接由開發(fā)人員負責(zé)發(fā)布。發(fā)布方式簡單粗暴，直接登錄到服務(wù)器上覆蓋文件。

攜程作為互聯(lián)網(wǎng)企業(yè)，第一代發(fā)布系統(tǒng)已經(jīng)做到了開發(fā)和發(fā)布隔離，使用一個 C/S 的軟件 ITSM 做發(fā)布，發(fā)布人員只需要簡單點擊按鈕就可以完成發(fā)布。

但是那個年代，一旦提到發(fā)布，我們往往就先要買第二天的早飯了。因為一個集群上的若干應(yīng)用發(fā)布是排隊的，必須一個應(yīng)用發(fā)布且驗證完畢才發(fā)第二個。同時因為是 C/S 結(jié)構(gòu)，需要發(fā)布人員做本地安裝，使得協(xié)同工作特別困難。

鑒于 ITSM 不斷被詬病，攜程自主開發(fā)了 CITSM 發(fā)布系統(tǒng)，功能和 ITSM 相似，但用 B/S 實現(xiàn)，協(xié)同發(fā)布變成可能，且將發(fā)布系統(tǒng)與框架其他系統(tǒng)進行整合，為開發(fā)人員提供了極大的便利。同時引入版本管理和回退機制，形成了一個飛躍。

第三代的發(fā)布系統(tǒng)進一步收緊了開發(fā)人員的權(quán)限，引入了 All In One、Config Gen、自動加載等。

所謂All In One，是將原本配置在 database.config 中的內(nèi)容，由發(fā)布系統(tǒng)實現(xiàn)，開發(fā)不再需要知道 DB 的連接字符串信息，取而代之的是獲得一個 Key，在代碼中配置這個 Key，由發(fā)布系統(tǒng)在發(fā)布過程中將這個 Key 翻譯成 DB 連接字符串。

但第三代發(fā)布系統(tǒng)因為集成功能太多，自身權(quán)限過大，最終導(dǎo)致了一個重大的生產(chǎn)故障，該故障以后第三代發(fā)布系統(tǒng)連人帶系統(tǒng)都被淘汰了。

取而代之的是第四代發(fā)布系統(tǒng)，被取名叫 Tars(又名 CD)。針對前三代發(fā)布系統(tǒng)最致命的漏洞：發(fā)布都是本地備份。Tars 引入了異地備份，即使本地磁盤整個被清空，仍可以從遠程恢復(fù)，網(wǎng)站的穩(wěn)定性又得到了質(zhì)的飛躍。

02配置管理

其次值得一提的就是配置管理，攜程的配置管理大體也經(jīng)歷了四個時代：

• 第一代配置系統(tǒng)，將 web.config 做了簡單的封裝，提供 Web 頁供開發(fā)人員做編輯，故有簡單便捷等優(yōu)點。對開發(fā)人員非常友好。
• 第二代配置系統(tǒng)恰相反，將 config 的修改集成在發(fā)布中，直接導(dǎo)致 config 等于一個全局變量。這樣避免了網(wǎng)站的重啟，對用戶很友好。但開發(fā)也就不用 config 了。
• 第三代配置系統(tǒng)是顛覆性的，一改傳統(tǒng) config 的缺陷，改為在應(yīng)用啟動時通過服務(wù)獲取配置信息，加載到內(nèi)存中。當(dāng)配置發(fā)生變化時，觸發(fā)監(jiān)聽機制更新。但第三代配置系統(tǒng)僅支持開和關(guān)兩個狀態(tài)。
• 第四代配置系統(tǒng)支持 Json 等主流格式，且優(yōu)化了監(jiān)聽機制，并做了開源。

03SOA

SOA 在攜程一直有著特殊的地位，在歷史上也有更多有趣的故事。其演變和迭代過程值得我們細細品味。

傳統(tǒng)的 API 調(diào)用，是一種網(wǎng)狀結(jié)構(gòu)，難以管理和控制，故障的排查也異常的困難。如果處理不當(dāng)可能出現(xiàn)循環(huán)調(diào)用的情況，當(dāng)服務(wù)端地址變化對客戶端將是一場災(zāi)難。

攜程作為互聯(lián)網(wǎng)企業(yè)，吸取上述教訓(xùn)，在第一代 SOA 就引入了治理平臺，統(tǒng)一管理服務(wù)的地址，并推出一個稱為 ESB 總線的服務(wù)，所有調(diào)用方都請求 ESB，由 ESB 負責(zé)尋址和分發(fā)。

此種架構(gòu)開始十分優(yōu)美和清晰，但卻有個致命的問題，ESB 總線是那個最大的瓶頸。那個年代，90% 的故障來自于 ESB 總線。

第二代 SOA 主要就是為了解決第一代 SOA 瓶頸問題，改為服務(wù)直連。SOA 僅作為治理和注冊，在調(diào)用方應(yīng)用啟動時從治理平臺獲取服務(wù)端的 URL，并存到內(nèi)存中，之后調(diào)用方就可以直接調(diào)用，第二代 SOA 的口號是“直連和去 ESB”。

隨著時間的推移，公司逐漸意識到在 SOA 層面可以做更多，比如熔斷、限流、動態(tài)路由等。

熔斷即治理平臺會根據(jù)服務(wù)提供方的異常情況，決定是否回應(yīng)調(diào)用方的請求，如果服務(wù)提供方異常，有返回默認值、返回空值、直接報錯幾種可能。

限流則重點監(jiān)控服務(wù)提供方的連接數(shù)，如果超過閥值，則開啟隊列模式，阻止之后的請求。

第三代 SOA 集成了大量實用功能，且做了大量監(jiān)控、埋點，逐漸得到大家認可。

而進入無線時代后，H5 和 APP 和服務(wù)端的交互成為了業(yè)界研究熱點，而 Gate Way 這次就呼之欲出了。Gate Way取代了原先的 Mobile Service 設(shè)計，加入了反爬和 Auth 認證，使得 SOA 的使用范圍進一步提升。

User Profile

結(jié)合本人負責(zé)的“User Profile”項目，給大家簡述一下攜程的架構(gòu)亮點。

01組成

“User Profile”作為大數(shù)據(jù)的核心組成部分，由典型的大數(shù)據(jù)模型構(gòu)成。包括注冊、采集、計算、存儲、查詢、監(jiān)控六大功能。

其中采集的數(shù)據(jù)來源包括個人信息、常旅信息、聯(lián)系人信息等用戶信息、用戶行為信息、用戶訂單信息等。用戶行為和用戶訂單采集的架構(gòu)圖如下所示：

02架構(gòu) 

采集到的信息通過 Batch 和 Steaming 兩種通道，經(jīng)過計算匯總到 User Profile 倉庫中。實時通道采用 Kafka+Storm 以及攜程自主研發(fā)的 Hermes 消息平臺。

目前存儲在”User Profile”倉庫中的數(shù)據(jù)已經(jīng)達到 100 億條以上，而所有儲存介質(zhì)，包括 Hive 、MySQL、Redis 都是用 FullDR+M-S 設(shè)計。如下圖：

在這樣的數(shù)據(jù)量級下，服務(wù)平均響應(yīng)時間一直控制在 10ms 左右(包括網(wǎng)絡(luò)消耗 4ms)。使用了熔斷、限流、降級和 Sharding 組成了完整的架構(gòu)保障，以實現(xiàn)整體的高可用。

作者：周源

編輯：陶家龍、孫淑娟

[[205514]]

周源

攜程技術(shù)中心基礎(chǔ)業(yè)務(wù)研發(fā)部高級研發(fā)經(jīng)理

2012 年加入攜程，先后參與支付、營銷、客服、用戶中心的設(shè)計和研發(fā)。此前在全球最大的管理咨詢及信息技術(shù)跨國公司 Accenture、全國排名第一的職業(yè)教育軟件公司任技術(shù)負責(zé)人。