作為國內最大的OTA公司，攜程為數以億計的海內外使用者提供優質的旅遊產品及服務。2014年底攜程技術中心的框架、系統和運維團隊共同啟動了架構改造專案，歷時2年，涉及所有業務線。本文回顧了攜程在整個技術架構改造過程中的一些實踐和收穫。
一、寫在前面
隨著攜程業務量迅速增長、業務變化越來越敏捷，對於應用交付的效率也提出了更高的要求。根據統計，截止2014年底攜程總應用數在5000個左右，平均每週約有3000次以上的釋出需求。所以作為整體交付環節中極為重要的一環，應用的部署和釋出是提高交付效率的關鍵，然而攜程原來的釋出系統Croller卻成為了阻礙交付效率提升的一大瓶頸。
【關於攜程火車釋出】 
*攜程火車釋出規定：每天定時安排釋出車次，以pool為單位安排車廂，在一個pool中的應用必須在“同一車次”的“同一個車廂”內做釋出。 
*攜程實際釋出情況：每個應用在釋出前需要“買票”，也就是申請和備案的過程，然後被分配到某個“車次”與同在一個pool且需要釋出的其他應用形成一個“車廂”，當到達規定釋出時間時，該“車廂”內的所有應用以灰度的方式做釋出。 
*該模式的弊端：（1）如果提前準備好了釋出，在未到達規定發車時間，只能等待，不能釋出。（2）如果錯過了某個發車時間點，只能等待下一次。（3）如果釋出過程中，同一個車廂內有一個應用釋出失敗，則整個車廂中的應用全部發布失敗。
具體來說，攜程Croller設計的是火車模式釋出，主要面臨的核心問題包括：
（1）由於ASP.NET的應用佔大多數，基本都採用的是Windows + IIS 的單機多應用的部署模式，應用和應用之間的隔離性較弱，且由於應用劃分的顆粒度比較細，在單機上往往可能同時部署20~30個應用，多的甚至達到60個，導致大量不同應用之間共用應用程式池的情況存在，即多個應用執行在同一個程序下，這種情況下任何一個應用的釋出都可能影響到其他的關聯應用。
（2）使用硬體負載均衡裝置承載應用的訪問入口，以域名為單位隔離。單機上的多個應用程式共享同一個訪問入口（同一個域名），所以健康檢測也只能實現到伺服器級別，無法識別應用級的故障。
（3）由於治理系統中的應用資訊不統一或不準確，影響監控和排障。
二、從破題到解題
1.破題思路
針對混亂又複雜的情況，如果要想從根本上去解決這些問題，提高交付效率，則必須要從配置管理、部署架構上全面支援以應用為最小顆粒度的管理能力。
我們解決思路包括：
（1）引入Group的概念，設計從App、Server、Pool、Group、Route的完整資料結構模型來描述應用相關的配置部署資訊，並由CMS作為權威資料來源向外提供資料介面，確保資料的一致性和準確性。

這些定義如下： 

（2）引入七層負載均衡（SLB），實現應用的訪問入口的隔離。使每個訪問入口（叢集）的成員（即應用程序例項）可具備獨立的管理能力，實現應用級的健康檢測。 

（3）設計實現新一代的釋出系統Tars，解決Croller釋出系統的痛點，支援應用級的釋出。

2.具體實現
雖然有了破題思路，但具體實現仍然有很多細節需要考慮，主要包括： 
（1）統一配置（CMS） 
（2）彈性路由（SLB） 
（3）想發就發（TARS）
統一配置（CMS）
正如大型傳統企業發展初期缺失ERP系統一樣，網際網路公司也需要發展到一定規模才能意識到一個完備的配置資訊系統的重要性。
網際網路公司在整個產品研發和執行生命週期中不斷產生大量的系統和工具，例如測試平臺、釋出平臺、監控系統和資源管理工具等。業務產品研發效率和業務系統穩定執行依賴這些工具平臺的高效協同工作。而如果要實現這種高效協同，關鍵就是擁有一個統一的配置資訊平臺。
不成熟的配置管理往往有以下特徵：
（1）配置系統之間相對獨立和分散，缺少關聯關係，且運維、研發工具、測試生產環境都有各自視角的區域性配置管理系統； 
（2）缺少明確的定義和抽象。例如，不同語言開發的應用對配置的描述方式有很大的差異性；或者對叢集、釋出節點和訪問入口等重要物件的定義很模糊； 
（3）配置資訊不準，依賴手工維護，沒有工具和流程約束，要執行者自己來保證操作和配置資料的一致性； 
（4）配置描述不完整，使得系統架構，比如叢集、域名對映等關鍵環節缺乏嚴格的配置管理。
而攜程這種配置管理暴露出很多問題，當監控到伺服器資源異常時，例如CPU、記憶體出現異常，無法快速查詢該異常影響的範圍，造成不知道應該聯絡誰進行排障；而對於非.NET的應用無法提供釋出工具，或只是提供了一些功能有限的釋出模組，但由於不同技術使用的釋出工具有著很大的差異性，給使用方和開發維護方都帶來了極大的不便；當資源和應用之間的關係不清晰，運維無法實現完善的資源計費等重要管理職能。
要應對這些問題，需要定義統一的配置模型和一致的配置資料，清晰地描述組織、業務、應用、系統架構和資源等要素及互相間的關係。從更高層次設計一套配置管理系統，使得各個維度的配置資訊既要專注於自身的領域，又能和其他相關的配置資訊維度建立起關聯，確保這些工具能以一致的定義來理解配置資料，進行順暢而有效的協同工作。
於是攜程的配置管理系統CMS就應運而生了，CMS核心目標包括：
（1）資料準確（即與實際保持一致）且合規 
（2）資料關係的查詢方便高效 
（3）資料變動可追溯 
（4）系統高可用 
（5）資料模型簡潔易懂
1. CMS系統演變過程
（1）抽象，定義，建立關係，儲存資料；
對於應用層面運維所涉及到的物件進行統一地抽象，使得使用不同技術、不同架構的應用體系都能使用一樣的模型結構來進行描述。
根據攜程的應用體系和管理方式，我們抽象出一套最核心的應用配置物件，包括組織、產品線、產品、應用、叢集、釋出節點、伺服器等。經過與那些不同語言不同技術架構所開發的應用間的磨合實驗，我們驗證了這套抽象的配置物件有其普適性，並可以完備地描述攜程範圍內各種應用的配置狀態。 
只要按照這套配置物件系統對一個應用完成了描述，那麼該應用從釋出到上線執行再到下線的全生命週期內，各種相關工具均能通過獲取這些配置狀態得到足夠的資訊進行工作。換句話說，通過這套統一的配置資訊資料庫，不同開發者、不同階段、不同功能的平臺實現了協同工作。 

（2）將CMS作為一種服務提供出去。
由於建立了描述應用體系的核心配置資料庫，這必然會有大量使用者和工具成為CMS的消費者。所以我們希望CMS消費者可以通過網路隨時隨地獲取、維護和管理CMS。這要求CMS能提供完備的API和一套簡潔直觀的管理介面。
（3）通過Portal和工作流引擎完成配置變更，實現業務邏輯的自動化執行。
除了建立統一的應用配置模型，還要建立應用配置的生命週期管理，做到生成配置，修改配置以及銷燬配置都合規，都經過授權，都有記錄可查。
（4）搭建一個強壯可靠的配置管理體系。
通過更多的子模組助力搭建配置管理體系來提高穩定性和可用性，實現查錯追溯和資料巡檢糾錯等功能。
2. CMS系統架構
CMS系統在開發過程中遇到和解決了一系列的棘手問題，系統本身的架構也反映了這些方案的設計實施情況。 
（1）資料治理
CMS系統最基本而關鍵的需求是提供正確的資料，資料必須能真實反映生產環境的配置現狀，並且還要符合公司制定的運維規範，不能出現違規配置。例如，攜程不允許同一個應用在一臺伺服器上執行多於一個例項；不允許在一臺伺服器上執行多於一個Java應用；每個伺服器上只能運行同樣型別的應用等。

所以為保證資料的準確性，CMS資料需要持續治理。我們把這部分的治理工作通過一個相對獨立的規則引擎來實現。該規則引擎主要完成的工作包括： 
允許快速新增新規則，可以使用輕量的指令碼語言快速定義各種規則進行資料檢查；
針對複雜規則設計了場景和規則兩層結構，不同場景可根據需求來配置不同規則；
資料入庫時做檢查，並進行定期巡檢，最大限度查詢和消滅錯誤配置。
（2）關係管理和變更追溯
對配置資料關聯關係的管理和使用是CMS使用者最為看重的功能之一。被CMS管理著的組織、產品、應用、叢集、伺服器、域名、釋出節點等配置間都有著千絲萬縷的複雜關係，使用者可能從任何一個配置物件開始查詢與另一個配置物件的關係，比如從應用查詢伺服器；從伺服器查詢組織；從域名查詢應用等等。
為提供最便利強大的查詢功能，我們專門設計了一套查詢框架，根據定義好的物件關係快速生成配置物件之間的查詢。現在使用者可以通過CMS介面和API非常方便地查詢到配置資料間的關聯關係。
與此相關的還有變更歷史的查詢，使用者除了需要查詢一個配置物件自身的變更歷史外，還經常需要查詢一個配置物件相關的物件變更歷史，比如要查詢一個應用下面所有伺服器的擴容縮容歷史；查詢一個叢集中應用上下線的歷史等等。於是我們採用了一種將變更訊息沿物件關係鏈廣播出去的方案，把變更和相關配置物件連線起來。
（3）完善的監控和應對訪問壓力
CMS因匯聚了生產環境核心的配置資料而被大量工具所依賴，因此其必須能夠承受大量而密集的查詢需求（工作時間內每分鐘上萬次請求是常態）。


（未完待續）