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

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

[[205510]]

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

架構(gòu)組成

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

01運(yùn)維

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

集群管理策略

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

FullDR 機(jī)制

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

DBA 策略

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

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

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

NOC 機(jī)制

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

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

02框架

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

SOA&Gateway

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

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

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

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

消息隊(duì)列

市面上開(kāi)源的消息隊(duì)列工具非常多，包括 Storm、MSMQ、ActiveMQ、RabbitMQ 等。

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

配置管理

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

03應(yīng)用

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

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

架構(gòu)演變

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

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

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

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

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

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

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

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

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

但第三代發(fā)布系統(tǒng)因?yàn)榧晒δ芴?，自身?quán)限過(guò)大，最終導(dǎo)致了一個(gè)重大的生產(chǎn)故障，該故障以后第三代發(fā)布系統(tǒng)連人帶系統(tǒng)都被淘汰了。

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

02配置管理

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

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

03SOA

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

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

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

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

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

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

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

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

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

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

User Profile

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

01組成

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

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

02架構(gòu) 

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

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

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

作者：周源

編輯：陶家龍、孫淑娟

[[205514]]

周源

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

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