携程的架构经历了长期的演进和迭代，旗下很多产品经历了5次以上的更新。每一次迭代都有它的背景和起点，在解决上一个版本的痛点的同时，也不可避免地会带来一些新的问题或遗漏一些问题。这种迭代，过去、现在、未来都在进行，体验可圈可点，值得技术人细细品味。本文首先从总体上介绍了携程的架构组成，然后结合发布系统、配置管理和SOA三个实际案例详细介绍了架构迭代，最后以我做的一个项目介绍了携程架构的亮点。架构构成总体来说，携程的架构由三部分组成：运维、框架、应用。01运维说到高可用和稳定性，我们首先想到的就是运维。携程的运维是应用和架构的坚强后盾，主要有四大亮点。集群管理策略携程的Web集群有slb来控制流量，可以根据healcheck的结果自动拉入拉出。发布和扩展过程对开发是透明的。当机器检查成功并且没有报错时，机器就会被拉入集群。当检查失败或者单位时间内报错超过阈值时，机器会自动拉出集群。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通过专门的订单图表和异常图表监控所有应用程序的运行状态。密切关注订单同比、环比涨跌情况。02Framework框架是应用的基石，携程框架经历过并正在经历着进化和迭代。其中，值得分享的有：SOA&GatewaySOA&Gateway是一个服务治理平台，历史非常悠久，后面会详细展开。发布系统携程的发布系统集成了很多功能，比如刹车、回滚、版本切换、共享dll打包、pom检测等等。出版系统经历了历史上最严重的灾难性失败，又在失败的灰烬中重生。值得与大家分享它的演进和迭代。消息队列市面上开源的消息队列工具很多，包括Storm、MSMQ、ActiveMQ、RabbitMQ等，携程结合各种第三方的优点，进行整合，结合自身情况独立开发了消息队列。核心功能包括分区排序、异步补偿和消息生命周期跟踪。配置管理任何规模的公司都会进行配置管理，配置最重要的是方便、高效、高性能。携程配置管理的演进恰好反映了这一趋势。03Application在与众多知名互联网企业架构师交流后，发现大家的应用架构都比较相似，普遍采用PreLoading&LayerLoading、Sharding、熔断、限流、降级等技术。无数的经验证明，以上措施确实大大提高了网站和APP的稳定性。比如当灾难发生时，PreLoading可以保证用户可以看到预设的内容；并且当网络状况不佳时，LayerLoading可以保证用户的操作不会卡顿。架构演进01发布系统携程的发布系统大致经历了以下四个“时代”：ITSM。CITSM。C辊(ROP)。焦油（CD）。说到出版，一定要提到“最传统”的出版方式。传统公司会有专门的售后团队负责部署，或者开发者直接负责发布。发布方式简单粗暴，直接登录服务器覆盖文件。作为一家互联网公司，携程的第一代发布系统实现了开发和发布的隔离。它使用C/S软件ITSM进行发布，发布人员只需点击一个按钮即可完成发布。但在那个年代，一到下水，我们往往要先买第二天的早餐。因为一个集群上的多个应用发布是排队的，所以在发布第二个应用之前必须先发布并验证一个应用。同时，因为C/S结构，发布者需要做本地安装，协同工作特别困难。鉴于对ITSM的不断诟病，携程自主研发了CITSM发布系统，其功能与ITSM类似，但采用B/S实现，协同发布成为可能，发布系统与其他框架系统集成，为开发者提供了极大的便利。同时引入了版本管理和回滚机制，形成了一个飞跃。第三代发布系统进一步收紧了开发者的权限，引入了AllInOne、ConfigGen、自动加载等，所谓AllInOne就是将发布系统原本配置在database.config中的内容实现。开发不再需要知道DB的连接字符串信息。而是需要获取一个Key，并在代码中配置这个Key。系统在发布时将这个Key翻译成DB连接字符串。但由于第三代发布系统集成的功能过多，自身权限过大，最终导致了一次重大的制作失败。这次失败之后，第三代出版系统和以人为主导的系统被淘汰了。取而代之的是第四代分发系统，称为Tars（又名CD）。对于前三代发布系统最致命的漏洞：发布都是本地备份。Tars引入异地备份，即使本地磁盘完全清空，依然可以远程恢复，网站的稳定性有了质的飞跃。02配置管理第二个值得一提的是配置管理。携程的配置管理大致经历了四个时代：第一代配置系统只是简单封装web.config，提供网页供开发者编辑。具有简单、方便等优点。对开发人员非常友好。第二代配置系统正好相反。config的修改集成到release中，直接导致config等于一个全局变量。这样就避免了网站重启，非常人性化。但是开发不需要配置。第三代配置系统具有颠覆性。没有改变传统config的缺陷，而是在应用启动时通过service获取配置信息并加载到内存中。当配置发生变化时，会触发监控机制进行更新。但是第三代配置系统只支持开和关两种状态。第四代配置系统支持Json等主流格式，优化了监控机制并开源。03SOASOA在携程一直有着特殊的地位，历史上还有更多有趣的故事。它的演进迭代过程值得细细品味。传统的API调用具有网络结构，难以管理和控制，故障排除也异常困难。如果处理不当，可能会出现循环调用，当服务器的地址发生变化时，对客户端来说就是一场灾难。携程作为一家互联网公司，吸取了上述教训，在第一代SOA中引入了治理平台，统一了管理服务地址，推出了ESB总线服务。所有的调用者都请求ESB，ESB负责寻址和分配。.这种架构一开始是非常漂亮和清晰的，但是有一个致命的问题，ESB总线是最大的瓶颈。那时候90%的故障都来自于ESB总线。第二代SOA主要是解决第一代SOA的瓶颈问题，直接对接服务。SOA仅用于治理和注册。调用者应用启动时，从管理平台获取服务器的URL，保存在内存中，调用者可以直接调用。第二代SOA的口号是“直连，去ESB”。随着时间的推移，企业逐渐意识到在SOA层面可以做更多的事情，比如熔断、限流、动态路由等，熔断意味着管理平台将决定是否响应调用者的请求根据服务商的异常情况。如果服务提供者异常，有返回默认值、返回空值、直接报错几种可能。限流侧重于监控服务提供者的连接数。如果超过阈值，则开启队列模式，阻塞后续请求。第三代SOA集成了大量的实用功能，做了大量的监控和嵌入，逐渐被大家所认可。进入无线时代后，H5与APP与服务端的交互成为了业界的研究热点，而GateWay这次也即将问世。GateWay取代了原来的MobileService设计，增加了防爬和Auth认证，进一步提高了SOA的使用范围。UserProfile结合我负责的“UserProfile”项目，给大家简单介绍一下携程的架构亮点。01构成“用户画像”作为大数据的核心组成部分，由典型的大数据模型构成。包括注册、采集、计算、存储、查询和监控六大功能。收集的数据来源包括个人信息、常旅信息、联系方式等用户信息、用户行为信息、用户订单信息等。用户行为和用户订单收集架构图如下：02架构收集的信息通过Batch和Steaming两个通道，计算汇总到UserProfile仓库中。实时通道采用Kafka+Storm和携程自主研发的Hermes消息平台。目前，“用户画像”仓库存储的数据已超过100亿条，所有存储介质包括Hive、MySQL、Redis均采用FullDR+M-S设计。如下图所示：在这样的数据水平下，服务的平均响应时间已经控制在10ms左右（包括4ms的网络消耗）。熔断、限流、降级、Sharding的使用构成了实现整体高可用的完整架构保障。作者：周源编辑：陶嘉龙、孙淑娟周源携程技术中心基础业务研发部高级研发经理2012年加入携程，先后参与支付、营销、客服、用户中心的设计开发。此前，他曾在全球最大的管理咨询和信息技术跨国公司、全国排名第一的职业教育软件公司埃森哲担任技术总监。
