架构高可用演化

MySQL（从库）

应用层

应用3

应用2

读

Nginx

应用1

MySQL（主库）

机房A

两地三中心

存储层

同城灾备

keepalived

跨城专线

异地多活在异地双活的基础上进一步改善，每个城市的机房之间并不是直接两两复制数据，而是选择一个机房作为中心节点，其他机房向中心机房同步数据，再由中心机房统一向其他机房同步其他机房的数据，当中心机房不可用时，可以提升其他机房为中心节点机房，多活的优势在于，可以任意扩展机房就近部署。任意机房发生故障，可以完成快速切换，大大提高了系统的可用性。

专线

复制

接入层

MySQL

城市A

云机房

城市B机房

应用

主备

机房C

主从架构通常是在同一个机房下通过服务器集群进行冗余部署，从而达到高可用的效果，但从部署区域粒度来看，如果机房断点，那么即使采用主从架构，系统对外仍然是不可用。同城灾备方案是在不同的机房（机房B）再部署一套系统，而这套系统正常情况下不对外提供服务，只有当机房A出现故障时，才切换到机房B，同城灾备最大的缺点就是大材小用，因此机房A出现故障不可用的概率还是非常低的，那么绝大部分时间机房B可能处于空闲状态，从而导致资源浪费。

DNS

同城双活架构是在同城灾备的方案基础上进行优化，充分利用备用机房（机房B）的资源，对外提供服务，同城双活需要把两个机房（机房A和机房B）的入口IP配置到DNS上，那么用户接入时，通过DNS解析到任意机房，同城双活需要控制存储层的写入，通常只在机房A写入数据，机房B只提供读数据权限。但同城双活也是有缺点的，由于同城，也就是两个机房在同一个城市，当发生自然灾害，比如地震、水灾时，也会导致系统不可用。

读、写

异地双活

主从架构

写

主主复制

城市A机房

异地多活

华丽的分割线

城市B（中心节点）

同城双活

机房B

路由层（地理位置路由）

同步

城市B

单机架构是最简单的一种架构方式，接入层、应用层和存储层都只有一个节点，实际部署可以部署在同一个服务器上，但是缺点也比较突出，其中一个节点宕机，整个系统不可用。

单机架构

两地三中心跟同城灾备有一个类似的地方，就是备用机房没有业务接入，只有出现灾难时才会切入，但是这个概率又极低，因此通常处于空闲状态而导致资源浪费。由于异地双活方案两个机房的距离通常在1000公里以上，因此机房之间数据同步往往延迟比较高，网络传输成为了性能瓶颈，因此只在一个机房写入，另外一个机房读取，这种方式是不可取的，所以需要增加路由层，可以根据用户请求IP判断地理位置，然后进行路由到最近机房，每个机房的存储层都是可以写入和读取的，数据通过主主复制的方式同步，所以业务应用在设计主键ID时需要采用分布式ID（雪花ID）的方式，保证数据同步时不会出现主键冲突。

由于同城双活方案当城市发生自然灾害时导致系统不可能，因此有些银行、政企等公司产品会采用两地三中心方案进行部署，该方案是在同城双活的基础上进行改进，通常会选择距离1000公里以上的城市部署备份机房，比如主机房在上海，则备份机房通常选择北京等，备用机房通常不对外提供服务，只是用于备份数据，防止主机房所在城市出现灾难而导致系统不可用。

主从架构除了数据库MySQL有状态外，其他都是无状态的节点（应用节点的状态数据可以存放在Redis等缓存上），其中Nginx和MySQL可以通过虚拟IP的方式对外提供服务，当Nginx和MySQL对外服务的节点宕机时，keepalived自动把VIP切换到另外一个节点，继续对外提供服务，从而达到高可用的效果。

城市C