9分布式微服务架构

分布式微服务架构不光需要从架构上的设计优化系统，还要在编码上优化达到最好的效果

中心化的设计

中心化的设计比较简单，分布式集群中的角色分为两种，管理者和被管理者。

在一个分布式或者集群中，管理者角色管理着其他处理实际业务的程序执行

中心化设计的有两个比较重要的问题1.管理者是否是高可用的 2.管理者是否能管理那么多处理业务的机器

关于第一个问题，现在很多新系统都开始使用自动选举的方式切换管理者，以提升系统的可用性

去中心化的设计

去中心化的设计，不是没有中心化的节点，而是中心化的节点是由集群的的节点进行选举出来的。

去中心化最大的一个问题是脑裂的问题。脑裂的问题一般是由于网络的问题造成两个集群不能通信，造成2个独立的集群。这个场景虽然发生的可能性很小，但是一旦发生会发生很多严重的后果。

集群和分布式的区别

集群部署的方式同一个业务或者存储以同样的方式部署多台，比如nginx代理多台应用服务时，每台应用服务按照nginx的配置方式去执行的情况。
分布式部署的方式是一个业务被拆分成多个子业务部署在不同的服务器上。

总结
判断中心化和去中心化区分的关键点是分布式系统中的管理节点是由管理节点控制的还是由集群中的节点选举控制的。集群和分布式的部署方式区分的关键是业务节点的业务是否一致。
这些只是概念上的区分，我们不用过于细究。很多实际的架构设计中很难有明显的区分，我们要去研究一个成熟的架构时还是需要去了解实际的架构和部署方式。概念性的东西了解即可。

如何防止脑裂的问题

1.仲裁的方式
如果在网络不可达的情况下，选举出2个leader，这个时候系统就会出问题，如果在leader选举出来时，我们加一把锁，锁定该leader已经被选举出来时的状态，其他leader再次被选举出来时候发现已经有leader时，则不能再成为leader.
2.fencing
当不能确定某个节点的状态时，通过fencing把对方干掉，确保共享资源被完全释放，前提是必须要有可靠的fence设备。但是fencing设备的安全本来就很难保证。

mysql的HA的问题

为什么要把这个问题拿出来聊呢？因为我们从上面的概念上来讲，脑裂问题是在分布式环境下leader选举时候会出现多个leader的问题，而很多大咖说mysql的HA属于脑裂的问题，会给很多人造成误导。
我在这里再想重申下，我们去看问题的时候要看问题的本质，具体造成的原因，不要人云亦云。很多所谓的大咖只不过是为了流量从网上生搬硬套的东西拿出来讲。我们去面对一个问题的时候还是需要具体去面对。

我们回到mysql 双主双从部署的问题上来。

mysql数据库通过binlog的方式互相同步两台数据库实例的数据，以达到高可用的服务。然后我们在部署在不同机器的ip通过keepalive做出来一个虚拟的ip，当一台机器由于网络原因或者机器的原因不可达时，我们的keeplive写入数据库的时候会把虚拟的ip切到另外一台数据中执行。

我们知道bonlog在同步的时候是有延时的，当切到另外一台机器时，上一台机器的binlog还未同步过来，我们往数据库中插入一条自增主键的数据时候，我们生成的id就会重复，这个时候就会造成很严重的问题。

我们分析mysql HA出现的具体问题，我们如何解决呢？

我们可以通过主键在代码中生成的策略就可以解决上面遇到的问题。这些都是实战中遇到问题并解决问题