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

内容来源: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计算,同时用到了熔断、限流、降级。

以上为今日的分享,感谢阅读!

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180103G0LKF000?refer=cp_1026

同媒体快讯

相关快讯

扫码关注云+社区