攜程高可用架構的演變和迭代——應用開發者視角

科技 07-02

作者簡介

周源，攜程技術中心基礎業務研發部高級研發經理，從事軟體開發10餘年。2012年加入攜程，先後參與支付、營銷、客服、用戶中心的設計和研發。

前言

攜程的架構經歷了長期的演變和迭代，其中多個產品已經歷了5次以上更新換代。每次迭代都有其背景和出發點，都解決了前一個版本的痛點又不可避免地帶來一些新的問題或遺漏一些問題。這種迭代過去、現在，以及將來將一直持續，其中經歷可圈可點，值得技術人細細品味。

本文會首先從總體介紹攜程架構的組成，然後以發布系統、配置管理和SOA三個實際案例，詳細介紹架構迭代，最後以UserProfile項目具體介紹攜程架構亮點的點滴。

聲明一下，本人現擔任攜程用戶帳戶信息的開發負責人，文章更多是從一位基層團隊負責人和一線開發人員的角度給大家分享攜程架構歷程。

文中涉及架構的方方面面，其中運維相關內容由運維團隊負責；架構相關內容由架構、框架、工具各團隊負責；應用相關內容除用戶帳戶信息以外都是由其他開發團隊負責。對於不是本人負責的產品，文章僅站在使用方、合作方的角度，作客觀、公正、事實的描述，且已盡量爭取各團隊負責人的授權、收集各團隊負責人的建議。

1.架構的組成

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

1.1.運維

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

1.1.1.集群管理策略

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

1.1.2.FullDR機制

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

1.1.3.DBA策略

數據的安全是重中之重，攜程將用戶數據放在穩定的首位。我們使用M-S機制和FullDR結合保證數據的高可用。同時為了因應互聯網的發展，我們將MSSQL的數據無縫遷移至MYSQL，雖然花費了很多時間和成本，但是為了穩定，投入也是值得的。同時我們保證遷移過程對用戶是透明的。

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

1.1.4.NOC機制

在攜程，作為開發負責人是非常艱苦的，因為如果你負責的應用一旦出現異常，NOC 7*24小時都可能聯繫你。NOC通過專門的訂單大圖和異常圖表監控所有應用的運行狀態。訂單量同比、環比的上升、下降都會被嚴密的監控。

1.2.框架

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

1.2.1.SOA&Gateway

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

1.2.2.發布系統

攜程的發布系統集成了很多特色功能，比如剎車、回退、版本切換、共用dll打包、pom檢測等等。發布系統經歷了歷史上最嚴重的災難性故障，在故障中浴火重生，非常值得給大家分享其演變和迭代。

1.2.3.消息隊列

市面上開源的消息隊列工具非常多，Storm、MSMQ、ActiveMQ、RabbitMQ等。攜程結合各第三方的優點，加以融合，結合自身情況，自主研發了消息隊列。核心功能有Partition有序、非同步補償和消息生命周期跟蹤。

1.2.4.配置管理

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

1.3.應用

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

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

2.架構的演變

2.1.發布系統

攜程發布系統至今大體經歷了四個「年代」。

1)ITSM

2)CITSM

3)CRoller（ROP）

4)Tars（CD）

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

攜程作為互聯網企業，第一代發布系統已經做到了開發和發布隔離，使用一個C/S的軟體名叫ITSM做發布，發布人員只需要簡單點擊按鈕就可以完成發布。但是那個年代，一旦提到發布，我們往往就先要買第二天的早飯了。因為一個集群上的若干應用發布是排隊的，必須一個應用發布且驗證完畢才發第二個。同時因為是C/S結構，需要發布人員做本地安裝，使得協同工作特別困難。

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

第三代的發布系統進一步收緊了開發人員的許可權，引入了All In One、ConfigGen、自動載入等。所謂All In One，是將原本配置在database.config中的內容，由發布系統實現，開發不再需要知道DB的連接字元串信息，取而代之的是獲得一個Key，在代碼中配置這個Key，由發布系統在發布過程中將這個Key翻譯成DB連接字元串。但第三代發布系統因為集成功能太多，自身許可權過大，最終導致了一個重大的生產故障，該故障以後第三代發布系統連人帶系統都被淘汰了。

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

2.2.配置管理

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

第一代配置系統，將web.config做了簡單的封裝，提供Web頁供開發人員做編輯，故有簡單便捷等優點。對開發人員非常友好。

第二代配置系統恰相反，將config的修改集成在發布中，直接導致config等於一個全局變數。這樣避免了網站的重啟，對用戶很友好。但開發也就不用config了。

第三代配置系統是顛覆性的，一改傳統config的缺陷，改為在應用啟動時通過服務獲取配置信息，載入到內存中。當配置發生變化時，觸發監聽機制更新。但第三代配置系統僅支持開和關兩個狀態。

第四代配置系統支持Json等主流格式，且優化了監聽機制，並做了開源。

2.3.SOA

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

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

攜程作為互聯網企業，吸取上述教訓，在第一代SOA就引入了治理平台，統一管理服務的地址。推出一個稱為ESB匯流排的服務，所有調用方都請求ESB，由ESB負責定址和分發。此種架構開始十分優美和清晰，但卻有個致命的問題，ESB匯流排是那個最大的瓶頸。那個年代，90%的故障來自於ESB匯流排。

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

隨著時間的推移，公司逐漸意識到在SOA層面可以做更多，比如熔斷、限流、動態路由等。熔斷即治理平台會根據服務提供方的異常情況，決定是否回應調用方的請求，如果服務提供方異常，有返回默認值、返回空值、直接報錯幾種可能。限流則重點監控服務提供方的連接數，如果超過閥值，則開啟隊列模式，阻止之後的請求。第三代SOA集成了大量實用功能，且做了大量監控、埋點，逐漸得到大家認可。

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

3.UserProfile