携程的架构经历了长期的演变和迭代，其中多个产品已经历了
5 次以上的更新换代。每次迭代都有其背景和出发点，都解决了前一个版本的痛点又不可避免带来一些新的问题或遗漏一些问题。
这种迭代过去、现在、将来一直持续着，其中经历可圈可点，值得技术人细细品味。
本文先从总体介绍携程架构的组成，接着以发布系统、配置管理和 SOA 三个实际案例详细介绍架构迭代，最后以自己做的一个项目具体介绍携程架构亮点的点滴。
架构组成
总体来说，携程的架构由三部分组成：运维、框架、应用。
01运维
谈到高可用和稳定性，我们首先想到的肯定是运维。携程的运维是应用和架构坚强的后盾，主要有四大亮点。
集群管理策略
携程的 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 通过专门的订单大图和异常图表监控所有应用的运行状态。订单量同比、环比的上升、下降都会被严密的监控。
02框架
框架是应用的基石，而携程框架更是经历过且正在经历着演变和迭代。其中特别值得分享的包括：
SOA&Gateway
SOA&Gateway 是服务的治理平台，它有着非常悠久的历史，后面会详细展开。
发布系统
携程的发布系统集成了很多特色功能，比如刹车、回退、版本切换、共用 dll 打包、pom 检测等等。
发布系统经历了历史上最严重的灾难性故障，在故障中浴火重生，非常值得给大家分享其演变和迭代。
消息队列
市面上开源的消息队列工具非常多，包括 Storm、MSMQ、ActiveMQ、RabbitMQ 等。
携程结合各第三方的优点，加以融合，结合自身情况，自主研发了消息队列。核心功能有 Partition
有序、异步补偿和消息生命周期跟踪。
配置管理
配置管理在任何规模的公司都会做，而对配置而言最重要的不外乎是便捷、高效和高性能。携程配置管理的演变恰恰反映了这种趋势。
03应用
经过和多家知名互联网企业架构师沟通，我们发现大家的应用架构都是比较相近的，一般都会用到 PreLoading&LayerLoading、Sharding、熔断、限流、降级等技术。
而经过无数经验证明，上述措施确实极大的提升了网站和 APP 的稳定性。比如，当灾难发生时，PreLoading
可以保证用户可以看到预设的内容;而网络情况较差情况下，LayerLoading 可以保证用户操作不卡顿。
架构演变
01发布系统
携程发布系统至今大体经历了如下四个“年代”：
1.ITSM。
2.CITSM。
3.CRoller(ROP)。
4.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
引入了异地备份，即使本地磁盘整个被清空，仍可以从远程恢复，网站的稳定性又得到了质的飞跃。
02配置管理
其次值得一提的就是配置管理，携程的配置管理大体也经历了四个时代：
第一代配置系统，将 web.config 做了简单的封装，提供 Web 页供开发人员做编辑，故有简单便捷等优点。对开发人员非常友好。
第二代配置系统恰相反，将 config 的修改集成在发布中，直接导致 config 等于一个全局变量。这样避免了网站的重启，对用户很友好。但开发也就不用
config 了。
第三代配置系统是颠覆性的，一改传统 config 的缺陷，改为在应用启动时通过服务获取配置信息，加载到内存中。当配置发生变化时，触发监听机制更新。但第三代配置系统仅支持开和关两个状态。
第四代配置系统支持 Json 等主流格式，且优化了监听机制，并做了开源。
03SOA
SOA 在携程一直有着特殊的地位，在历史上也有更多有趣的故事。其演变和迭代过程值得我们细细品味。
传统的 API 调用，是一种网状结构，难以管理和控制，故障的排查也异常的困难。如果处理不当可能出现循环调用的情况，当服务端地址变化对客户端将是一场灾难。
携程作为互联网企业，吸取上述教训，在第一代 SOA 就引入了治理平台，统一管理服务的地址，并推出一个称为
ESB 总线的服务，所有调用方都请求 ESB，由 ESB 负责寻址和分发。
此种架构开始十分优美和清晰，但却有个致命的问题，ESB 总线是那个最大的瓶颈。那个年代，90% 的故障来自于
ESB 总线。
第二代 SOA 主要就是为了解决第一代 SOA 瓶颈问题，改为服务直连。SOA 仅作为治理和注册，在调用方应用启动时从治理平台获取服务端的
URL，并存到内存中，之后调用方就可以直接调用，第二代 SOA 的口号是“直连和去 ESB”。
随着时间的推移，公司逐渐意识到在 SOA 层面可以做更多，比如熔断、限流、动态路由等。
熔断即治理平台会根据服务提供方的异常情况，决定是否回应调用方的请求，如果服务提供方异常，有返回默认值、返回空值、直接报错几种可能。
限流则重点监控服务提供方的连接数，如果超过阀值，则开启队列模式，阻止之后的请求。
第三代 SOA 集成了大量实用功能，且做了大量监控、埋点，逐渐得到大家认可。
而进入无线时代后，H5 和 APP 和服务端的交互成为了业界研究热点，而
Gate Way 这次就呼之欲出了。Gate Way取代了原先的 Mobile Service 设计，加入了反爬和
Auth 认证，使得 SOA 的使用范围进一步提升。
User Profile
结合本人负责的“User Profile”项目，给大家简述一下携程的架构亮点。
01组成
“User Profile”作为大数据的核心组成部分，由典型的大数据模型构成。包括注册、采集、计算、存储、查询、监控六大功能。
其中采集的数据来源包括个人信息、常旅信息、联系人信息等用户信息、用户行为信息、用户订单信息等。用户行为和用户订单采集的架构图如下所示：
02架构
采集到的信息通过 Batch 和 Steaming 两种通道，经过计算汇总到
User Profile 仓库中。实时通道采用 Kafka+Storm 以及携程自主研发的 Hermes
消息平台。
目前存储在”User Profile”仓库中的数据已经达到 100
亿条以上，而所有储存介质，包括 Hive 、MySQL、Redis 都是用 FullDR+M-S 设计。如下图：
在这样的数据量级下，服务平均响应时间一直控制在 10ms 左右(包括网络消耗 4ms)。使用了熔断、限流、降级和
Sharding 组成了完整的架构保障，以实现整体的高可用。
