开发者学堂课程【2022阿里云云原生中间件开发者大会集锦：如何基于 AppActive 设计一套多数据中心应用多活方案】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1053/detail/15295
如何基于 AppActive 设计一套多数据中心应用多活方案
内容介绍：
一、背景
二、如何缓解
三、容灾架构选型
四、AppActive 异地多活方案
五、核心理念
六、分层讲解
七、方案收益
八、AppActive 规划
一、背景
首先来看下背景。系统在运行过程中，总是会遇到各种各样的问题。
1. 硬件故障
比如第一类是硬件故障，磁盘损坏了，内存短路了，智能系统损坏了等等。
2. 软件故障
第二类是软件故障，容量不足，健康检查失效等等。
3. 人为故障
第三类，是人为故障，比如做了一个错误的配置，或者是错误的发布，甚至是删库跑路等等。
4. 不可抗力
最后一类是不可抗力，比如地震活山雷电，断电断网等等。
在面对这些故障的时候，不能够报以一种侥幸的心态，因为一个系统它只要规模足够大，或者运营时间足够长，那么只要有可能出错的地方那就一定会出错，所以需要一些手段来对这些故障来进行应对和缓解。
二、如何缓解
回到刚刚的几类故障，一个硬件故障，它有一个大概率的是一个小规模的问题，比如状态组集失效了，但是如果它产生了极点效应，就会变成一个大规模的问题，但是这个概率应该是比较小。
那么一个不可抗力，它大概会引起一个大的问题，但是也有极小的概率，它会是一个小的问题，比如这个机房里，不是高峰期，或者业务不是很重要等等，总而言之，一个核心的思想就是，不同规模不同影响面的故障，有不同的手段去避免和缓解。
1. 硬件故障
比如主机级的故障，一般可以通过集群的手段去提高它的可能性，或者避免故障，比如无状态的应用，一般集群化部署潜能加负载就可以，对有状态的应用，还需要通过副本以及共识算法来解决。
2. 软件故障
那么，对于软件故障，还有热点隔离，限流降级，熔断，弹性伸缩等等手段来进行故障避免和缓解。
3. 人为故障
对于人为故障，可以通过信息安全，变更管控，这样保证等手段来进行避免和缓解。
4. 不可抗力
那对于不可抗力也就是本课要讲的的容灾架构才能够进行避免缓解。
不论是小规模还是大规模的问题都需要监控和告警，来进行辅助。
三、容灾架构选型
接下来介绍一下容灾架构，容灾架构其实有很多，要做一个选型，大致分为这几个类型。
1.类型
首先来看数据备份，它的核心要点就是数据备份的，应用是没有备份的，故障发生的时候，只能靠天吃饭，等待故障恢复，才能够继续服务。
冷备，它应用也没有备份，但是它基础设施存在，所以需要的时候可以手工或者自动拉起这个应用，所以当故障发生的时候就可以拉起这个应用，对外进行服务。
第三个是温备，温备它的特点，就是应用备份以最小集部署并运行，但是不对外提供服务，所以当故障发生的时候，备份应用只需要scale out然后就可以对外服务。
热备，热备比温备多走了一步，那就是它是对等部署的，所以在故障发生的时候，备份应用是可以直接对外服务的。
然后多活，它就比热备更近了一步，它多个站点是对等部署的，并且是同时对外提供服务的，所以在故障发生的时候，只需要将故障站点的流量进行清理操作就可以了。
2. 容灾架构对比选型
那么，面对这么多的架构，该怎么选型？核心的一个考虑，就是不同的rpo，rto，成本及性能要求，决定了使用不同的架构。所以看看每种价格，它有哪些指标？
（1）、RPO
首先看rpo，数据备份来说，它的rpo是取决于备份周期的，后面这种架构，因为它都是一个实时异步的复制。所以rpo可以做到约等于0，虽然是大于0的，但是可以做到约等于零，因为它是实时复制，所以这个是一个核心的要点。
（2）、RTO
然后看RTO，RTO对于数据备份来说，因为故障发生时，它是靠天吃饭的，所以它只能做到一个小时级集，甚至是天级。
那对于冷备来说，其实也差不多，因为从零拉起一个应用并不是那么容易。
但对于温备来说，让它只需要做一个scale out，所以它大概率是可以做到一个小时级，甚至是分钟级的，
这么对于热备来说，它连scale out都省略了，所以大概率可以做到一个分钟级，如果复杂的情况，它可能一个小时级。
那对于多活来说，它大概率是可以做到一个分钟级的rto，甚至是可以做到秒级的rto。
（3）、资源价格
然后第三个资源价格，数据备份来说，因为它的冗余量，就是很低，它只做了一个数据的备份，所以它的资源价格是较低的。
那冷备相对要高一点，因为它很冗余的一个基础设施。
那温备就更高一点，因为它还有冗余的应用。
那么对于热备和多活来说，因为它的应用是对等部署冗余的，所以它是自然价格是最高的。
（4）、资源利用率
那么接下来看一下资源利用率，但对于数据备份来因为它是应该很低，所以它的资源利用率是最高的，冷备来就相当于低一点。温备和热备，其实温倍的资源利用率要高一点，因为它的冗余量低一点。热备，它的资源利用率是最低的，因为它对等部署，但是却没有利用起来，然后多活，它比热备要好一点，因为它的资源虽然是对等部署的，但它是利用起来的。
（5）、复杂度
看一下复杂度，数据备份的复杂度很低了，只要做数据备份。那冷备，其实也差不多。那温备，它比热备的复杂度还高，因为它在故障发生时还要做一个scale out操作，那么热备一个操作直接就可以服务了。多活的复杂度是最高的，因为它要达到多站点同时对服务，它需要流量调度，数据冲突解决等等一系列的操做。
（6）、容量
那对于容量，数据备份，那它当然就是单机房的容量。冷备，温备，热备，其实它的容量都已经被单机房或者单定域局限。那对于多活来说，它理论上是可以做到机房水平扩展，所以它的容量是最高的。
（7）、切流信心
那切流信心也就是故障发生的时候，恢复的一个信心，那对数据备份来说，它没有这个操作，所以它就是not number，那对于冷备来说，因为平时备用应用根本就没有跑起来，所以切流信心非常低。
那温备，就稍微好一点，因为它有一个一直跑着的，虽然没有流量，但它好歹是跑，那对于热备来，那就切流信心就更高一点因为它毕竟是全量的，它不需要额外的操作。那对于多活来说，它切流信心就最大，因为多个站点都是对外同时部署的，只需要做一个流量调度。
所以选型的核心考虑就是，如果需要分钟级的rto，那么只能选择热备和多活，然后多活架构下，它多个站点是同时对外服务的，所以它资源利用率更高，那么关键时候切流信心更足，而且它的一个潜在的容量是更大的，所以就是要选多活的话就有这些考虑因素。
异地多活VS同城多活
然后看一下多活，多活它又分为异地多活和同城多活。
1. 同城多活
同城多活，它机房间rt较小，所以数据库一般用主备，这样避免数据的一致性问题，然后应用的它是多活的，那么本机房是优先调用的，当然可能存在跨机房调用。比如们机房的provide就是占健康的比例值是非常低，这时调对面的，可能成功的概率更大一些，然后故障的时候只需要做机房切零，机房流量切零，和数据库主备切换，然后主备切换也不一定要做，因为数据库可能没问题。
2. 异地多活
然后异地多活，它机房rt较大，所以是不宜单写的，尽量要走本地数据库，但由于多点写，所以就需要解决数据冲突，然后应用也是多活的，所以尽量要本机房封闭调用，虽然也可能存在跨机房调用，这个取决于具体的方案，那么故障时只需要做一个机房切零，这个过程中也需要解决数据冲突的问题。
这两个架构的选型，核心的一点是是否需要应对城市级的故障，这是一个关键的考虑点。
四、AppActive 异地多活方案
那么接下来看看AppActive还提供了什么样的异地多活方案，那一个整体思路就是对业务进行类型划分，然后据此对数据中心进行的计划。
1. 业务划分
可以看看下边这张图，对业务进行了分类分为三类。第一类是全局业务，一般就是强一致业务，这样的业务在中心单元，然后核心业务，就是做了单元化拆分的业务，那么就是部分特定的流量，在特定单元写。第三类是共享业务，这一类业务，就是被核心业务高频依赖的，全局业务的读服务，那么这部分业务，它是在中心单元写，在普通单元读。
2.单元
那么有了这个义务定义，可以看到单元定义，中心单元，它就是需要承载业务的单元，其他单元那就是普通单元。
五、核心理念
有了这么一个整体思路之后，再来看一看核心的理念，总结起来就是基于隔离的冗余。
1. 冗余
首先看一看冗余，就是数据它在多个机房之间是做了一个实时的一个复制的，这是rto约等于零的一个核心要点。
2. 隔离
那么什么叫隔离，可以看看图中，流量再从中端到达网络网关之前都是乱的，可以看到，有灰色的，有橙色的，那么到了网关过后，对流量进行一个分配，比如橙色的流量就打到左边的机房，灰色的流量就打到右边的机房，然后再从网关。到服务。到数据库。那么都符合这一个分片规则。就是特定的流量一定是在特定机房内完成它的一个整个流量的请求的一个生命周期。
3.优点
这么做有什么好处，第一个，首先就是请求的生命周期在一个情况内完成，就是这个业务，它这个机房内是独立的，这样就不必依赖另一个机房，那么这样当另一个机房挂掉过后，这个机房还是能够独立对外服务，这是第一个。
第二个，就是不存在跨机房的请求，所以这个整个请求它的链路是的缩短的，所以它的性能更好，对于用户体验来也是更好的，所以这次基于格力的这么一个核心思想。
当然每一层对，它做这个基于隔离的冗余，它需要依赖图左边这个多活规则，那么这个多和规则是一系列的定义，比如这个机房属于哪一个单元，然后流量怎么染色，然后哪些流量属于哪些单元，还有服务的类型定义，数据库定义，那么这些多活规则，是通过多活channel到每个机房里的应用去。
六、分层讲解
好讲完整体过后，来进行一个分层的讲解。
1.网关——支持Nginx 和Tengine
请求进入机房过后，第一条就是网关，当前网关支持Nginx 和Tengine。
（1）、改造要点
那么它的一个改造要点就是，网关引入AppActive插件，然后进行多单元的部署，然后同一个业务在不同的单元的地址，放入不同的upstream中，然后，第三个就是网关推送多活规则，第二个怎么解释，一般会把一个应用放在一个upstream里，但是因为是多机房部署的，所以要做一个区分，这样流量就可以达到不同的地方去。
（2）、改造效果
它的一个改造效果，日常态，不同标记或者分片，还记得继续隔离的冗余吗，就对流量的数据都进行的分片，所以日常态，不同分片的流量会分流到不同的单元。然后故障态，只需要把切零的多活规则推送给网关，然后网关就会把所有的流量打不到非故障的单元实现这边一个philo的效果。
2.微服务——支持Dubbo 和 Spring Cloud
那第二条就到了微服务，当前微服务，它支持的是Dubbo 和 Spring Cloud。
（1）、改造要点
微服务的一个改造要点就是首先要引入AppActive应用的sdk，后对应用进行一个多单元的部署。
第二个关键要点，就是对各类型的服务进行打标，分为中心服务和普通服务和单元服务，那么对应于刚刚的中心服务对应全局业务，普通那就对应共享业务，单元对应是核心业务，当然具体的打标方式取决于微服务框架，比如Dubbo 和 Spring Cloud打标方式有些区别的。
第三个，就是在单元间进行服务同步，当然这个仅当在跨单元调用的时候需要，比如存在全局业务，那么就可能会存在跨单元的调用，这个时候就要在单元间进行服务同步。
第四个，就是像应用推送这个多活规则。
（2）、改造效果
那完成改造过后的效果，日常态，不同分片的流量，那可以按照多活规则分类到不同的单元。那么如果没有规则，就认为是普通服务，就按照单元优先的这么一个规则发起调用。
故障态会切零多活规则推送给应用，这样consumer在接收到流量过后，就会把请求全部打到非故障单元的provider。同样的实现了这样一个philo的效果。
3. 数据层——支持MySQL
然后是流量到了最下面就是数据层了，数据层大概支持MySQL。
（1）、改造要点
核心要点就是要引用AppActive应用的sdk，然后应用要使用提供的driver。然后把应用进行多单元部署，然后将不同类型的数据库进行达标，分为普通数据库和单元数据库。第三个，是在单元间进行数据同步。第四个就是向应用推送多活规则。
（2）、改造效果
这样完成了一个改造效果，就是日常态，单元数据库仅接受多活规则中属于本单元的流量与请求，也就是说，还记得那个基于隔离的冗余吗，其实就是流量和数据进行分片，属于这个单元分片的流量，才允许使用，单元数据库有这么一个作用。然后普通数据库，它接受所有的请求。
当在故障态的时候，切流过程中，数据可能它同步还有一些延迟，如果直接把流量切过去就可能造成双协，那么就数据就脏了，所以切流过程中，数据库的静止读写，直到数据同步追评过后才放开，这样避免数据脏，这就是一个改造完成的一个效果。
那么每一层做完过后，就是这个方案基本上就实施完毕。
七、方案收益
所以来看看这个方案是工作完毕它的一个收益是什么。
1.容灾
那这个方案它是为了容灾做的，所以首先看看容灾，那么这个方案，它可以应对多种故障的场景比如，机房前面的网络故障，网络故障，机房内部的网关故障，业务故障，中间件故障，还有多个机房网络之间网络的故障，还有机房整体的故障，对于这些故障都可以做到一个分钟级的rto。业务恢复时间和具体故障恢复时间结果怎么理解，比如ab两个地方同时对外服务，一机房挂了，这个时候先把流量切走，其实业务基本上就可以已经恢复了。虽然你的地方可能还没有恢复，但是我的业务以及先恢复了，所以这两个做了一个结论，这样来实现一个分钟级的rto。
2.容量
那第二个收益，其实除了容灾，那它还有两个额外的收益，那么第二个就是容量，就是基于多活路由策略，那么机房就是它伸缩起来更简单，它不会有就是，就是机房之间它没有那种乱成一团线的一个就是那样的一个依赖关系所以机房要水平扩展，相对来是比较容易的，所以能解决单机容量不足的问题，具体的容量，比如机器数量，带宽容量，还有连接数，这些容量问题。
3. 创新试验田
第三个就是一个创新试验田，就是，第一首先继续做多活路由规则，可以实现一个完整的灰度策略，怎么理解？就是从接口，从网关到理的服务接口到最后数据库表结构，都可以做灰度，所以这个灰度室可以做得非常彻底。
第二个就是爆炸半径可控，因为始终只影响，就是说因为一个单元机房服务一部分用户，所以这个爆炸半径是可控，可以做一个完整的故障演练来提高整个系统的可能性。不是提高性，就是度量，先度量再提高。
然后第三点，就是对于某些重点业务，可以就是比如临时开出来一个机房来进行独立的成长，这样就实现了这么一个业务的重保，所以这就是这套方案的一个收益。
八、AppActive 规划
然后来看一下AppActive的规划，就是因为AppActive其实也刚上市没有多久，规划其实是从网关到应用到数据，就是这么一个规划，就是要对市面上主流的这些框架都进行一个支持，可以看到网关是Nginx 和Tengine，ingress这些都希望做一个支持，然后应用层，其实它就是一个更丰富的，比如具体的框架来做Dubbo 和 Spring Cloud，sofa。
还有消息，还有数据，然后无论是sdk或者agent的或者甚至是以mage形态来支持，这都在规划范围内。
然后数据同步的话需要和比如注册中心，就是主要就是服务的一些同步，还数据同步比如具体的数据库，甚至是消息这样一些同步，所以都要和这些市面上主流的这些框架来进行一个结合，这是一个规划。
那么当然也欢迎大家加入AppActive，一起把这个多活容量的产品，做得更好，更大，更完整。
