分布式，微服务，集群和异地多活

​分布式的初衷是为了分隔和拆分子业务，所以分布式指的对象是应用服务器。每个应用服务器都可以部署单独的子业务。

 

一般分析好处，我们可以从下面几点进行考虑：

 

1.可用性。分布式部署，如果一个业务节点出现问题，不会影响其他业务节点， 除非其他业务节点依赖了失败节点。

2.易扩展，客观上便于高性能。因为单独的子业务，更容易扩展部署。

3.易维护，升级部署时，只需要更新子业务本身的代码即可。

 

每个子业务，都可以视作一个子系统进行部署。

 

有分布式部署，就会涉及到另外一个问题，就是业务之间的交互。各子系统，如何知道其他子系统的存在。这就需要注册中心。每个子系统在启动时，把自己的信息注册到注册中心。而访问其他子系统服务时，先从注册中心获取可用子系统的信息，进而进行访问。

 

而微服务可以视作分布式的一个具体实现。

 

分布式的一个目的，就是为了解耦服务。而这些服务之间通信需要的是共享的东西。这些共享的东西，可以是存储（例如，mysql，redis），或者通过消息中间件，例如kafka

 

集群要解决的问题，也是同样的，不过，集群可以看做同一个业务部署多份，而不是一个业务拆分为多个子业务。通过部署多份，再加上负载均衡，提供高可用和高并发。

 

当集群中的一台机器出现问题时，负载均衡器，就可以发现，并将其剔除。从而保证请求正常被响应。

 

这些问题都解决了，貌似没有问题了，但是这些只是业务方面。也就是应用服务器。而应用服务器后面，都会对应着存储服务，就是我们常说的数据库。

 

数据库也会故障，那么为了解决数据库的突发故障导致的服务不可用。就需要也为数据库进行集群部署，而集群部署的主要方式，就是主从方案。

一主一从，或者一主多从的方案，一方面提供备份，另一方面也会为读写分离做基础准备。

 

但是主从方案会有一个问题，数据同步会有延迟，而这种延迟主要来自于部署的位置。所以同城部署主从会是常见方案，但是一旦遇到城市级别断电或者网络故障，仍不能保证高可用。所以，会在异地部署一个备份，但是这个备份平时是不会使用的，也就是冷的。而一个过冷的数据库，是很难作为临时启用的数据库来正常工作的，风险非常大。

因为同城的主从，切换角色的可能性会存在，而且从库平时可以作为读库存在，可以算作是热库。而异地备份，虽然也可以视作从库，但是从未被使用过，因此，紧急启用风险较大。

这就是两地三中心，和两地三中心方案带来的问题。

 

如果本地和异地，一热一冷，有这么大的弊端，那么，异地的数据库也变为热的呢？其实，这就是所谓的异地双活，或者异地多活。而活，就是热，表示数据库为平时的提供服务。

 

异地多活，主要的挑战来自于数据同步。

从宏观上来说，距离带来的传输延迟会比较大。所以，数据一致性会是一个挑战。

从细节上来说，因为部署的异地的多个服务有可能会同时修改同一条数据，而落在两个数据库。这两个数据库中的哪条数据作为最终的数据被认可，就是一个问题了。

另外，对于新增数据，会不会出现主键冲突，也是另外一个需要考虑的问题。

 

对于数据修改问题，可以利用时间戳，后修改的数据，覆盖前面修改的数据。

对于数据新增问题，可以利用全局UUI，或者利用各个机房作为主键前缀的方式来规避主键冲突。

 

而异地多活的数据同步，则需要更多的手段，例如中间件来实现了。

或许，我们可以从消息中间件的发布订阅机制来获得一些解决的思路。

在一主多备的方式下，主从同步，使用拉的方式来实现。也就是主库将自己的redolog写到某个特定的地方，从库主动拉取，因为会有多个从库，不可能采用推的方式。

异地多活中的某个热库，对于其他热库来说，当然就是从库。所以，一个热库，只管将自己的redolog写到某个地方，其他热库需要自行拉取。

 

更多技术交流文章，请关注微信公众号【时代码农】