异地多活高可用架构设计

如何构建应用的异地多活？

概要

随着业务的快速发展，对于不少公司来讲，构建于单地域的技术体系架构，会面临诸以下面的多种问题：基础设施的有限性限制了业务的可扩展性；机房、城市级别的故障灾害，影响服务的可持续性。

为解决遇到的这些问题，公司能够选择构建异地多活架构，在同城/异地构建多个单元(业务中心)。各个业务单元能够分布在不一样的地域，从而有效解决了单地域部署带来的基础设施的扩展限制、服务可持续性。

异地多活是近几年比较热门的一个话题，那么在实际业务中何时须要去作这件事？如何去作？作的时候须要考虑什么？

什么时候去作？

我的感受取决于如下几个方面：

• 业务发展
• 基础设施情况
• 技术积淀

如何作？

目前在网上搜索到的异地多活方案来看，基本都是阿里、饿了么、京东、微博这些互联网大厂的实践，这些大厂的方案有一个共同点就是：大量的自研组件，来作相关的数据同步，业务切分等等，那么，对于不少传统企业或者相对小一些的企业，应该如何来作这件事？

• 根据业务特性借助合适的公有云服务

作的时候，须要注意什么？

• 真正须要作异地多活的业务有哪些？
• 基础设施如何？
• 对于不可用时间的容忍程度是多少？

业务背景

• 在全部的系统中用户中心都是核心业务，由于它是进入其它不少业务前提。
• 咱们这边IDC不是很稳定，以前发生过几回机房大规模故障，好比机房网络挂了，整个机房对外不可用了。

以上两点是咱们此次要作用户中心异地容灾的出发点，以便在面对机房级别故障时，保证服务可用性。

业务梳理

用户中心从总体来看，对外主要提供：注册、登录、查询用户信息等服务。这些服务又有如下几个特色：

• 登录的优先级最高
• 事务性要求低

涉及的公共组件主要有：

• MySQL：用户数据存储
• Redis：Authorization Code、短信验证码、帐号锁定、access token等的存储
• Zookeeper：Dubbo依赖

方案

用户中心是经过外包的形式进行开发的，目前已上线并交付给另外一个外包商运维，因此在考虑容灾一期方案的时候，须要考虑尽可能不动代码。

目标

一期目标

当北京机房出现故障的时候，能够必定时间内把流量切到青岛机房这边，保证用户中心核心服务的基本可用。

二期目标

用户中心经过异地多活，实现高可用（须要集团智能DNS支持）。

架构设计

一期架构

当北京机房发生故障的时候，能够把流量快速切换到青岛这边，以保障用户中心核心服务可用。

具体方案以下：

• 经过otter近实时的将北京机房核心业务数据同步到青岛机房。
• 青岛机房部署Redis、ZooKeeper等中间件。
• 青岛机房部署用户中心的核心应用（实例正常部署、运行，只是平时不会有访问）。

具体架构以下：

能够达到的效果：

• 当北京机房出现故障的时候，能够在必定时间内把流量切到青岛机房这边，保证用户中心核心服务的基本可用，但此时已登陆用户须要从新登陆。
• 必定时间：取决于DNS修改ip时间+DNS TTL时间，目前来看TTL是10分钟，人工修改ip应该很快，因此必定时间是10~20分钟。

存在的缺点：

• 北京机房非故障期间，青岛机房的机器，仅作数据库同步，存在必定的资源浪费。
• 当北京机房出现故障，流量切换到青岛机房后，只能保证登录这一核心服务的可用。对于注册等须要修改数据库的服务，均不支持，若是在此期间访问这类服务，会发生异常。

二期架构

二期的目的就是修正一期架构的缺点，经过异地多活，实现高可用。

二期青岛机房会替换为阿里云机房。

具体方案以下：

• 经过阿里云DTS服务实现两地机房数据库同步，保证北京、阿里云数据的近实时一致性。
• 北京、阿里云两地机房均提供在线服务，提升资源利用率。
• 梳理服务优先级，修改应用代码，支持服务降级。
• 当某个机房（阿里云或者北京）出现故障的时候，经过DNS服务把流量切换到另外一个机房。
  • 若是两地部署的时候，没有冗余必定硬件资源，则须要实施服务降级。
  • 目前集团DNS解析，没法提供自动检测服务是否可用的功能，也就没法自动进行切换。
    • 服务可用性，能够经过咱们这边的多点拨测进行监控，当多点拨测不可用的时候，发送告警通知给相关人员，以便人工介入。
    • 多点拨测告警，应该会提供两类：一、某个拨测点不通的时候 二、全部拨测点均不可用的时候。
  • 目前集团DNS解析，TTL生效最短期是10分钟，没法自定义TTL时间。

具体架构以下：

能够达到的效果：

• 若是集团DNS能够提供，相似阿里云云解析的网站监控功能并能灵活设置TTL时间，这时当北京机房或者阿里云机房出现故障后，就能够在很短的时间（部分服务最大异常时间）内自动进行流量切换。

此处只是以阿里云云解析示例，只要能提供相似的服务都可。

• 若是集团DNS没法提供相似阿里云云解析的网站监控及灵活设置TTL时间的功能，则部分服务最大异常时间仍是取决于DNS修改ip时间+DNS TTL时间。

名词解释

什么是网站监控？

HTTP/HTTPS实时探测域名解析记录，支持自定义端口，实时发现宕机当即告警； 全网分布式监控，在中国各个地区模拟用户端真实请求，监控结果然实可靠； 支持宕机暂停、容灾切换，最大限度的解决服务中断对您的业务带来的损失； 容灾切换支持A记录、CNAME域名，知足各类场景的容灾切换需求；

什么状况会被网站监控判断为宕机并发送告警通知？

监控结果中，HTTP/HTTPS的返回码大于500的服务器错误状况，才会报警通知。 举例说明：若是设置了四个探测点 北京联通、深圳阿里巴巴、上海电信、重庆联通。 场景一：四个探测点中50%的监控点没法收到您服务器的响应，或50%的监控点收到返回码大于等于500时，才会判断您的网站为宕机状况。 场景二：四个探测点中有50%以上的探测点探测您的网站返回码是小于500的状况，则不会判断您的网站为宕机。

云解析DNS“流量管理”

云解析“流量管理”能够在您设置的每条解析线路下，根据权重比例轮询返回解析结果。当线路下的IP宕机时能够经过监控自动发现，并将宕机IP从当前线路下摘除，直到监控IP正常时会恢复解析。同时，当一条解析线路下的全部IP都宕机时，能够切换至其余正常线路。最大程度保证您的网站服务高可用，减少损失。

部分服务最大异常时间

好比北京机房出现异常，这时转发到阿里云机房的流量是能够正常访问，只有转发到北京机房的流量是异常的。

这时若是使用网站监控或者相似服务，进行监控，并设置拨测间隔为1分钟，TTL生效时间为1秒，那么最多有60+1秒部分服务异常时间，以后DNS会自动把北京机房的ip自动踢掉，流量所有切到阿里云。

补充

1. 一期、二期方案的实现均强依赖于集团的DNS服务

2. 用户中心经过ip暴露的服务，一但出现机房级别的故障，一期、二期方案均没法保证该部分服务可用。

3. 其实除了DNS这种方案，还有一种方案就是用相似F5这种设备，做跨机房负载，但必须是gslb，并且两端必须是相同的设备。

小结

对于，非一线互联网大厂的公司而言，是实现异地容灾的时候，借助公有云是颇有必要的，好比：

• 数据跨机房同步，可使用阿里云的DTS(Data Transmission Service) 服务，目前DTS支持关系型数据库、NoSQL、大数据(OLAP)等数据源间的数据传输。 它是一种集数据迁移、数据订阅及数据实时同步于一体的数据传输服务。

• 跨机房分布式数据库，可使用OceanBase。金融环境下一般对数据可靠性有更高的要求，OceanBase每一次事务提交，对应日志老是会在多个数据中心实时同步，并持久化。即便是数据中心级别的灾难发生，老是能够在其余的数据中心恢复每一笔已经完成的交易，实现了真正金融级别的可靠性要求。
• 异地多活因为各个公司的业务、基础设施及要解决的问题皆不尽相同，因此选择适合本身的就好。
• 或者直接使用云数据库RDS MySQL 版

我的微信公众号：

我的github：

github.com/jiankunking

我的博客：

jiankunking.com