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

数据丢失和数据冲突：数据写到主机，还没有复制到从机，主机就挂了，这个时候怎么处理，这个也得考虑业务的方式，是要确保 CP 或 AP 。

文章插图

还要考虑一个数据冲突的问题，这个问题在 MySQL 中大部分是由自增主键引起。
就算不考虑自增主键会引起数据冲突的问题，其实自增主键还要引起很多的问题，这里不细说，避免使用自增主键。
③数据分片
上述的数据冗余可以通过数据的复制来进行解决，但是数据的扩张需要通过数据的分片来进行解决(如果在关系型数据库是分表) 。

文章插图

何为数据分片(Segment，Fragment，Shard，Partition)，就是按照一定的规则，将数据集划分成相互独立、正交的数据子集，然后将数据子集分布到不同的节点上。
HDFS，MongoDB 的 Sharding 模式也基本是基于这种分片的模式去实现。
我们在设计分片主要考虑到的点是：

做数据分片，如何将数据映射到节点。
数据分片的特征值，即按照数据中的哪一个属性(字段)来分片。
数据分片的元数据的管理，如何保证元数据服务器的高性能、高可用，如果是一组服务器，如何保证强一致性。

柔性化/异步化

文章插图

①异步化
在每一次调用，时间越长存在超时的风险就越大，逻辑越复杂执行的步骤越多，存在失败的风险也就越大。
如果在业务允许的情况下，用户调用只给用户必须要的结果，而不是需要同步的结果可以放在另外的地方异步去操作，这就减少了超时的风险也把复杂业务进行拆分减低复杂度。
当然异步化的好处是非常多，例如削峰解耦等等，这里只是从可用的角度出发。
异步化大致有这三种的实现方式：

服务端接收到请求后，创建新的线程处理业务逻辑，服务端先回应答给客户端。

文章插图

服务端接收到请求后，服务端先回应答给客户端，再继续处理业务逻辑。

文章插图

服务端接收到请求后，服务端把信息保存在消息队列或者数据库，回应答给客户端，服务端业务处理进程再从消息队列或者数据库上读取信息处理业务逻辑。

文章插图

②柔性化
什么是柔性化?想象一个场景，我们的系统会给每个下单的用户增加他们下单金额对应的积分，当一个用户下单完毕后，我们给他增加积分的服务出现了问题。
这个时候，我们是要取消掉这个订单还是先让订单通过，积分的问题通过重新或者报警来处理呢?
所谓的柔性化，就是在我们业务中允许的情况下，做不到给予用户百分百可用的，通过降级的手段给到用户尽可能多的服务，而不是非得每次都交出去要么 100 分或 0 分的答卷。
怎么去做柔性化，更多其实是对业务的理解和判断，柔性化更多是一种思维，需要对业务场景有深入的了解。
在电商订单的场景中，下单，扣库存，支付是一定要执行的步骤，如果失败则订单失败。

文章插图

但是加积分，发货，售后是可以柔性处理，就算出错也可以通过日志报警让人工去检查，没必要为加积分损失整个下单的可用性。
兜底/容错

文章插图

兜底可能是我们经常谈论的一种降级的方案，方案是用来实施，但是这里兜底可能更多是一种思想，更多的是一种预案，每个操作都可以犯错，我们也可以接受犯错。
但是每个犯错我们都必须有一个兜底的预案，这个兜底的预案其实就是我们的容错或者说最大程度避免更大伤害的措施，实际上也是一个不断降级的过程。
举个例子：