携程的架构经历了长期的演变和迭代，其中多个产品已经历了 5 次以上的更新换代。每次迭代都有其背景和出发点，都解决了前一个版本的痛点又不可避免带来一些新的问题或遗漏一些问题。
这种迭代过去、现在、将来一直持续着，其中经历可圈可点，值得技术人细细品味。
本文先从总体介绍
携程架构的组成，接着以发布系统、配置管理和 SOA 三个实际案例详细介绍架构迭代，最后以自己做的一个项目具体介绍携程架构亮点的点滴。
总体来说，携程的架构由三部分组成：运维、框架、应用。
谈到高可用和稳定性，我们首先想到的肯定是运维。携程的运维是应用和架构坚强的后盾，主要有四大亮点。
集群管理策略
携程的 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 通过专门的订单大图和异常图表监控所有应用的运行状态。订单量同比、环比的上升、下降都会被严密的监控。
框架是应用的基石，而携程框架更是经历过且正在经历着演变和迭代。其中特别值得分享的包括：
SOA&Gateway
SOA&Gateway 是服务的治理平台，它有着非常悠久的历史，后面会详细展开。
发布系统
携程的发布系统集成了很多特色功能，比如刹车、回退、版本切换、共用 dll 打包、pom 检测等等。
发布系统经历了历史上最严重的灾难性故障，在故障中浴火重生，非常值得给大家分享其演变和迭代。
消息队列
市面上开源的消息队列工具非常多，包括 Storm、MSMQ、ActiveMQ、RabbitMQ 等。
携程结合各第三方的优点，加以融合，结合自身情况，自主研发了消息队列。核心功能有 Partition 有序、异步补偿和消息生命周期跟踪。
配置管理
配置管理在任何规模的公司都会做，而对配置而言最重要的不外乎是便捷、高效和高性能。携程配置管理的演变恰恰反映了这种趋势。
经过和多家知名互联网企业架构师沟通，我们发现大家的应用架构都是比较相近的，一般都会用到 PreLoading&LayerLoading、Sharding、熔断、限流、降级等技术。
而经过无数经验证明，上述措施确实极大的提升了网站和 APP 的稳定性。比如，当灾难发生时，PreLoading 可以保证用户可以看到预设的内容；而网络情况较差情况下，LayerLoading 可以保证用户操作不卡顿。
携程发布系统至今大体经历了如下四个“年代”：
-
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 引入了异地备份，即使本地磁盘整个被清空，仍可以从远程恢复，网站的稳定性又得到了质的飞跃。
