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

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

[[205510]]

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

架構組成

總體來說，攜程的架構由三部分組成：運維、框架、應用。

01運維

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

集群管理策略

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

FullDR 機制

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

DBA 策略

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

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

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

NOC 機制

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

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

02框架

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

SOA&Gateway

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

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

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

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

消息隊列

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

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

配置管理

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

03應用

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

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

架構演變

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

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

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

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

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

但是那個年代，一旦提到發(fā)布，我們往往就先要買第二天的早飯了。因為一個集群上的若干應用發(fā)布是排隊的，必須一個應用發(fā)布且驗證完畢才發(fā)第二個。同時因為是 C/S 結構，需要發(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ā)人員的權限，引入了 All In One、Config Gen、自動加載等。

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

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

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

02配置管理

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

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

03SOA

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

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

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

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

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

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

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

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

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

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

User Profile

結合本人負責的“User Profile”項目，給大家簡述一下攜程的架構亮點。

01組成

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

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

02架構 

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

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

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

作者：周源

編輯：陶家龍、孫淑娟

[[205514]]

周源

攜程技術中心基礎業(yè)務研發(fā)部高級研發(fā)經理

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