超级会员免费看
在前两讲里，分别从微服务的对外接口、消息消费以及微服务自身的相关编码规范上阐述了“防备上游、做好自己”这两个准则如何落地。
在本讲里，将会讲解为什么要“怀疑下游”，以及有哪些手段可以落地此条准则。此外，还会介绍在进行微服务拆分后，调用外部依赖会产生的分布式事务、消息发送等问题的应对方案。
为什么要怀疑下游
首先我们先来回顾一下“第 17 讲”里介绍过的抽象的微服务架构，如下图 1 所示：
图 1：抽象的架构示意图
从图一中可以看到，微服务会依赖很多其他微服务提供的接口、数据库、缓存，以及消息中间件等，这些接口及存储可能会因为代码 Bug、网络、磁盘故障、上线操作失误等因素引发线上问题。此时，由于依赖不可用，就会导致微服务对外提供的服务受到影响，出现接口可用率下降或者直接宕机的情况。
为了防止上述情况的发生，在构建微服务时，就需要预先考虑微服务所依赖的各项“下游”出现故障时的应对方案。假设下游出现故障及预设计对应的方案的过程，便是在实践“怀疑下游”。
如何落地
下面将基于下图 2 所展示的三大类依赖：其他微服务、数据库、消息中间件，逐一介绍可能引发的故障的应对方案和最佳使用准则。
图 2：包含三大类依赖的微服务图
订阅专栏 解锁全文
3957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
