應用開發者視角看攜程架構的演變
攜程的架構經歷了長期的演變和迭代，其中多個產品已經歷了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.配置管理
配置管理在任何規模的公司都會做，而對配置而言最重要的不外乎是便捷、高效和高性能。攜程配置管理的演變恰恰反映了這種趨勢。
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%