应用开发者视角看携程架构的演变

　　携程的架构经历了长期的演变和迭代，其中多个产品已经历了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.配置管理

　　配置管理在任何规模的公司都会做，而对配置而言最重要的不外乎是便捷、高效和高性能。携程配置管理的演变恰恰反映了这种趋势。