异地多活高可用架构设计 _架构

概要随着业务的快速发展，对于很多公司来说，构建于单地域的技术体系架构，会面临诸如下面的多种问题：基础设施的有限性限制了业务的可扩展性；机房、城市级别的故障灾害，影响服务的可持续性。
为解决遇到的这些问题，公司可以选择构建异地多活架构，在同城/异地构建多个单元(业务中心) 。各个业务单元可以分布在不同的地域，从而有效解决了单地域部署带来的基础设施的扩展限制、服务可持续性。
【异地多活高可用架构设计】异地多活是近几年比较热门的一个话题，那么在实际业务中什么时候需要去做这件事？如何去做？做的时候需要考虑什么？
何时去做？
个人感觉取决于以下几个方面：

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

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

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

做的时候，需要注意什么？

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

业务背景

在所有的系统中用户中心都是核心业务，因为它是进入其它很多业务前提。
我们这边IDC不是很稳定，之前发生过几次机房大规模故障，比如机房网络挂了，整个机房对外不可用了。

以上两点是我们这次要做用户中心异地容灾的出发点，以便在面对机房级别故障时，保证服务可用性。
业务梳理用户中心从整体来看，对外主要提供：注册、登陆、查询用户信息等服务。这些服务又有以下几个特点：

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

涉及的公共组件主要有：

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

方案用户中心是通过外包的形式进行开发的，目前已上线并交付给另一个外包商运维，所以在考虑容灾一期方案的时候，需要考虑尽量不动代码。
目标
一期目标
当北京机房出现故障的时候，可以一定时间内把流量切到青岛机房这边，保证用户中心核心服务的基本可用。
二期目标
用户中心通过异地多活，实现高可用（需要集团智能DNS支持）。
架构设计
一期架构
当北京机房发生故障的时候，可以把流量快速切换到青岛这边，以保障用户中心核心服务可用。
具体方案如下：