三、建立多活保证高可用
3.1 目标
- 满足监管要求
- 满足全行业务连续性要求
- 实现一键切换
- 缩短计划内停机时间
我们可以看一下业界比较主流的灾备是怎么做的？最主流的灾备技术是两地三中心，数据中心A和数据中心B在同城作为生产级的机房，当用户访问的时候随机访问到数据中心A或B。
之所以随便访问，因为A和B会同步做数据复制，所以两边的数据是完全一样的。但是因为是同步复制的，所以只能在同城去做两个数据中心，否则太远的话同步复制的延时会太长。
在两地三中心的概念里，一定会要求这两个生产级的数据中心是必须在同一个城市，或者在距离很近的另外一个城市也可以，但是距离是有要求的，一般要求在60公里之内，比如雄安和北京城区。异地备份数据中心通过异步数据复制来实现，银行两地三中心的特点是异地备份数据中心一般不作为关键应用宿主地，某些情况下是完全冷备，有些机构的做法是将统计分析和非关键的内部管理系统放到灾备机房。对于关键业务应用异地灾备中心不对外服务，所以用户不会访问到异地的点。原因是因为数据从生产级数据中心到异地的节点是异步去复制，所以整个有延时。这个模式在灾难到来的情况下可能会出现冷切换的问题，不能很顺畅的切换，虽然在平时的演练中，已经模拟了生产切换，但往往是众多情况中比较乐观的设定。
另外一种模式为异地多活模式，也是目前正在兴起的一种模式，对于某些大型银行的核心关键应用已经在此模式下进行了成功验证。异地多活首先是要做到同城双活或者同城多活，就是数据在同城网络环境下进行高速备份，也可以在做楼宇级同步，一般在10ms类的数据差异。异地多活需要多个跨地域的数据中心。异地多活是跨地域的，而且距离一定要做到1000公里以上的范围，其实在中国范围内全国城市都可以去部署了。降低数据同步量，同步服务根据一定业务键通过Zookeeper路由到对应的主数据中心，备数据中心可以通过旁路报文或者异步数据同步方式补全。
2.3.2 互联网行业多活架构
最近十年，互联网发生了翻天覆地的变化,现在的互联网服务相比于银行系统有以下几个特点,访问量大,并发量大,非强一直要求，RTO和RCO要求都非常高,低成本。在这些要求的前提下,产生了一套适用于互联网行业的多活架构。
互联网的多活架构通常是通常双活双中心+混合云的方式,基于各种自研组件,开源组件和MySQL数据库来实现多活。
下图是多活双中心示意图。
下图是多活双中心与公有云示意图。
双中心主要实现业务架构的双活,任意一个机房挂掉,可以快速的切换到另外一个机房。混合云的架构主要为机房提供快速扩容的弹性能力。
在实践这个架构的时候,有几个关键点。
1、单元化
2、前端路由
3、数据路由
4、数据同步
单元化
单元化是多活架构的基石。单元化通常有几个维度，用户维护,功能维度，用户与功能的混合模式,作为电商,核心业务只有一个，就是购物流程。我们一定要确保购物流程的高可用。因此购物流程功能肯定不能拆分成更细的单元,如果拆分后，那么购物流程的一个单元不能用，整个购物流程就不通了。咱的双活也就失败了。所以我们会选择用户维度的单元化。
前端路由
前端路由的主要目的是解决如何快速的将用户切换到正常服务的机房，传统是通过DNS来切换，但是这个切换受限于DNS缓存的生效周期，并且最多只能做到地区,很难做到细粒度的路由控制。现在常用的有两种方案。一、通过中间件的方式,所有用户进入同一的用户端路由中间件,有中间件去决定用户走什么路由。优点是控制力非常好,缺点是如果用户量和请求量太大,中间件存在性能瓶颈。二、通过APP端路由的方式,下发路由策略到APP端,由APP端完成用户路由，选择正确的机房。
数据路由
虽然我们有一层前端路由,但是由于现在入口非常多,H5,APP,PC,小程序等等。 我们很难将所有的入口都能做到100%走路由,甚至还有一部分路程是在后台或者service层自己发起的。那么问题来了，这部分没有经过前端路由的用户数据是否会出现异常？答案肯定会的。
