为了做到微服务的高可用，鬼知道我出了多少张牌( 二 ) _微服务

文章插图

网关不保存任何的 Session 数据，不提供会造成一致性的服务，将不一致的数据进行几种存储，借助更加擅长数据同步的中间件来完成。
这个是目前主流的方案，服务本身尽可能提供逻辑的服务，将数据的一致性保证集中式处理，这样就可以把“状态”抽取出来，让网关保持一个“无状态” 。
这里仅仅是举了网关的例子，在微服务基本所有的服务，都应该按照这种思路去做。
如果服务中有状态，就应该把状态抽取出来，让更加擅长处理数据的组件来处理，而不是在微服务中去兼容有数据的状态。
数据存储高可用

文章插图
【为了做到微服务的高可用，鬼知道我出了多少张牌】
之前上面说的服务冗余，可以简单的理解为计算的高可用，计算高可用只需要做到无状态既可简单的扩容缩容，但是对于需要存储数据的系统来说，数据本身就是有状态。
跟存储与计算相比，有一个本质的差别：将数据从一台机器搬到另一台机器，需要经过线路进行传输。
网络是不稳定的，特别是跨机房的网络，Ping 的延时可能是几十几百毫秒，虽然毫秒对于人来说几乎没有什么感觉，但是对于高可用系统来说，就是本质上的不同，这意味着整个系统在某个时间点上，数据肯定是不一致的。
按照“数据+逻辑=业务”的公式来看，数据不一致，逻辑一致，最后的业务表现也会不一致。
举个例子：

文章插图

无论是正常情况下的传输延时，还是异常情况下的传输中断，都会导致系统的数据在某个时间点出现不一致。
而数据的不一致又会导致业务出现问题，但是如果数据不做冗余，系统的高可用无法保证。
所以，存储高可用的难点不在于怎么备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。
分布式领域中有一个著名的 CAP 定理，从理论上论证了存储高可用的复杂度，也就是说，存储高可用不可能同时满足“一致性，可用性，分区容错性” 。
最多只能满足 2 个，其中分区容错在分布式中是必须的，就意味着，我们在做架构设计时必须结合业务对一致性和可用性进行取舍。
存储高可用方案的本质是将数据复制到多个存储设备中，通过数据冗余的方式来实现高可用，其复杂度主要呈现在数据复制的延迟或中断导致数据的不一致性。
我们在设计存储架构时必须考虑到以下几个方面：

数据怎么进行复制
架构中每个节点的职责是什么
数据复制出现延迟怎么处理
当架构中节点出现错误怎么保证高可用

①数据主从复制
主从复制是最常见的也是最简单的存储高可用方案，例如 MySQL，redis 等等。

文章插图

其架构的优点就是简单，主机复制写和读，而从机只负责读操作，在读并发高时候可用扩张从库的数量减低压力，主机出现故障，读操作也可以保证读业务的顺利进行。
缺点就是客户端必须感知主从关系的存在，将不同的操作发送给不同的机器进行处理。
而且主从复制中，从机器负责读操作，可能因为主从复制时延大，出现数据不一致性的问题。
②数据主从切换
刚说了主从切换存在两个问题：
主机故障写操作无法进行。
需要人工将其中一台从机器升级为主机。
为了解决这个两个问题，我们可以设计一套主从自动切换的方案，其中涉及到对主机的状态检测，切换的决策，数据丢失和冲突的问题。
主机状态检测：需要多个检查点来检测主机的机器是否正常，进程是否存在，是否出现超时，是否写操作不可执行，是否读操作不可执行，将其进行汇总，交给切换决策。
切换决策：确定切换的时间决策，什么情况下从机就应该升级为主机，是进程不存在，是写操作不可行，连续检测多少失败次就进行切换。
应该选择哪一个从节点升级为主节点，一般来说或应该选同步步骤最大的从节点来进行升级。切换是自动切换还是半自动切换，通过报警方式，让人工做一次确认。