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

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

[[205510]]

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

架構組成

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

01運維

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

集群管理策略

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

FullDR 機制

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

DBA 策略

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

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

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

NOC 機制

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

NOC 通過專門的訂單大圖和異常圖表監控所有應用的運行狀態。訂單量同比、環比的上升、下降都會被嚴密的監控。

02框架

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

SOA&Gateway

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

發布系統

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

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

消息隊列

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

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

配置管理

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

03應用

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

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

架構演變

01發布系統

攜程發布系統至今大體經歷了如下四個“年代”：

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

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

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

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

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

第三代的發布系統進一步收緊了開發人員的權限，引入了 All In One、Config Gen、自動加載等。

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

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

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

02配置管理

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

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

03SOA

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

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

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

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

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

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

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

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

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

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

User Profile

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

01組成

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

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

02架構 

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

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

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

作者：周源

編輯：陶家龍、孫淑娟

[[205514]]

周源

攜程技術中心基礎業務研發部高級研發經理

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