分布式-单元化架构1

一 两地三中心

1.1 两地三中心*

两地指的是两个城市：同城，异地。三中心指的是三个数据中心：生产中心、同城容灾中心、异地容灾中心。

在同一个城市或者临近的城市建设两个相同的系统，双中心具备相当的业务处理能力，机房之间通过高速网络实时同步数据。

在异地建设灾备中心，通过异步传输的方式，将双机房的数据备份至异地灾备中心，以应对城市级别的灾难。

其中两地三中心是同城双活加一个冷备。

1.2 两地三中心-冷备模式

这种模式下，多个中心是主备关系，即只有生产中心对外提供服务，同城容灾中心是生产中心的备份，当生产中心无法提供服务时，将流量切换至同城容灾中心。当同城双机房都发生故障时，启用异地灾备中心。

缺点：

1.通过资源的堆砌与冗余来应对不确定事件的发生。

2.对灾难的响应和机房的切换周期非常长，无法实现业务的零中断，对设备资源的利用率低下。

1.3 两地三中心-双活模式

双活模式：使同城双中心同时对外提供服务，节约成本，同时继续保留异地容灾中心。双活不仅仅是将流量切分至两个机房这么简单，更多的是要考虑如何能让用户的请求在一个机房中就能完成，避免跨机房调用带来的延时增加，从而影响客户体验。

对于双活架构，要考虑以下几个方面的因素：

1.业务能否在一个机房内完成整个交易链路上所有处理；

以购买理财为例，请求链条为：互联网网关->理财渠道服务->理财系统->账务系统。如果这些服务部署在不同的机房，则每次请求都要进行跨机房的访问，必然会增加性能损耗，造成资源浪费。

2.应用程序如何进行双活；

通常会在互联网网关（或者nginx）上，进行流量的分发，根据相应的规则，将请求分发到指定的机房处理。如下图：

3.中间件如何进行双活；

若要实现redis的主主同步，需自己研发相应的插件，例如可以通过订阅mysql的binlog日志来做缓存数据的同步。通过实现同步组件，监听mysql的binlog日志并解析，将数据同步到两个机房的redis集群中。如下图：

4.数据库能否双活，如何同步。

应用的双活和中间件的双活，最终都依赖于数据如何存放。如果两个机房中各部署一个数据库，那么机房间的数据如何同步呢。

以mysql为例，业界最常用的做法就是利用binlog做数据同步，最具代表性的就是阿里开源的Canal+Otter数据同步方案。Canal可以伪装成一个Mysql Slave，接收binlog文件，获取到Mysql Master的数据变更，如图：

Otter可以将Canal获取的数据，同步到目标数据库，Canal+Otter不仅可以实现同构数据的同步，还能实现异构数据的同步，同时会简化压缩要传输的binlog，减少网络压力，传输速度更快。如图：

1.4 总结

两地三中心的备份模式与双活模式，可以看到，这两种模式下，每个机房的数据量都是全量的，在某个机房故障时，另外一个机房会接管全部的流量。

一个好的RPC框架追求的是让远程服务调用像调本地方法一样简单。