携程高可用架构的迭代与实践

内容来源：2017年9月23日，携程技术中心基础业务研发部高级研发经理周源“博学实践日：DevOps与高可用架构最佳实践之路”进行《在携程高可用架构的迭代与实践》演讲分享。本文经主办方和讲者审阅授权发布。

阅读字数：1120 3分钟阅读

今日内容由以下三个部分进行展开

1、架构组成

2、架构演变

3、UserProfile

架构组成

运维

a、携程的运维有一个集群策略，能够自动监听。每台机器都有一个健康检测的状态，如果健康检测是成功的，那么会拉入集群。何为健康检测，我们应用有个发布，发布过程中就会出现健康检测，并且是在线上实时循环检测。

b、第二个是FullDR，多个机房时，一个机房出现了故障，流量就会自动切换到另一个机房，无论是DB、Web还是Redis都会有这个FullDR机制。在申请应用时，首先就得评估高可用的程度，但具体是否需要FullDR需要根据应用场景来判断。

c、DBA，携程的数据库正在转型做MYSQL，所以做了MSSQL-MYSQL无缝迁移，以及SQL+NoSQL结合。

d、Noc，从订单维度来看，出现下降趋势时，监控订单的大图就会出现变化，就会启动Noc机制，就会电话联系各团队来解决问题。

框架

SOA&Gateway

发布系统

SOA治理平台

H5 Gateway

回退

刹车

切换

消息队列

配置管理

Partition有序

异步补偿

消息生命周期跟踪

跨APP

内存读取

监听机制

应用

架构的演变

发布系统

传统发布系统是人工操控发布，10年前引入ITSM发布系统，由系统来完成发布的过程，并且开发与发布实现隔离，但发布耗时极长；第二代发布系统是CITSM，将各种平台，包括SOA，Gateway等进行了整合，由于架构产生了变化，后来实现了版本切换及回退；第三代CRoller开始已经将很多东西集成到发布系统当中了，AllInOne：将所有DB连接字符串放在同一位置并进行统一的维护；依赖项加载：在大型公司中，很多应用、框架等都是是共用的，在发布过程中强制将这些共用的引入，但第三代的开发权限太大；第四代发布系统是CD，引入远程镜像，每次发布都会在远程进行备份。以及引入灰度发布，在机器之前再加一层，由这一层来控制流量，控制新旧版本流量的分配，最后在发布时进行实时的监控，有错误出现，发布立刻停止。

配置管理

ConfigWeb

1、导致应用重启；

2、简单便捷、立即生效；

3、对开发很友好

ConfigGen

1、全局静态变量；

2、发布式嵌入；

3、对用户很友好

FC

1、可跨APPID、IP；

2、内存级管理；

3、仅支持开关

APOllO

1、变更监听机制；

2、支持Json；

3、前所有优点

SOA

当服务数量多到一定程度一定是网状的，服务也就不可控的，携程在SOA上也花费了大量的经历，所有的调用方和服务方之间的请求和响应都可控了，同样经历了以下四个版本。

ESB1.0：这一版的SOA就是一个总线，所有的请求和响应都要经过总线，RequestType寻址。瓶颈在于CPU、高流量、响应时间一直是不可控的。

ESB2.0：提出去ESB化，服务直连，启动加载地址，轮询缓存。

SOA2.0：熔断/限流；filter热部署、动态路由、且支持IIP直流；心跳机制

Gateway：集成Auth认证（http head）；反爬；监控

UserProfile

UserProfile的组成

注册、采集、计算、存储、查询、监控

下图为产品架构图

所有BU的用户首先会在注册系统进行注册，注册完会有通道将注册数据更新到大仓库中，通道分为两个部分，传输和更新。仓库分发出服务，给实时的和非实时的两种场景用。

下图为技术架构图

注册系统进行注册，通过DataX进行批量更新到UserProfile数据仓库，以及实时通道的实时更新，仓库分出一层Redis的缓存，给到实时与非实时这两种应用。

UserProfile实例

点开产品列表时，就已经开始了用户推荐以及UserProfile计算，同时用到了熔断、限流、降级。

以上为今日的分享，感谢阅读！