第3章通用的服务可用性治理手段——3.1 微服务架构与网络调用
当某个业务从单体服务架构转变为微服务架构后，多个服务之间会通过网络调用形式形成错综复杂的依赖关系。以负责展示用户主页的个人页服务为例，为了拼装出完整的用户主页，个人页服务需要对多个其他微服务发起RPC请求，如图3-1所示。
- 从用户信息服务中获取用户昵称、头像、个性签名等用户基础信息。
- 从地理位置服务中获取用户活跃IP地址的归属国家和省市信息。
- 从内容列表服务中获取用户已发布内容的列表。而内容列表服务要进一步从计数服务中获取用户发布的内容数、点赞总数，并从内容服务中获取每条内容的具体信息，如文本、图片、发布时间、点赞数、评论数、转发数等，其中后三者又需要内容服务继续从计数服务中获取。
- 从关系服务中获取用户与请求发起者之间的关系，并进一步从计数服务中获取用户的关注数和粉丝数。
我们可以看到，在微服务架构中，一个微服务正常工作依赖它与其他微服务之间的多级网络调用，这是微服务架构与单体服务架构最典型的区别。
但网络是脆弱的，RPC请求有较大的概率会遇到超时、抖动、断开连接等各种异常情况，这些都会直接影响微服务的可用性。比如个人页服务在调用用户信息服务时发生网络超时，由于无法获取到用户基础信息，所以会使得个人页服务无法正常对外提供服务。
当微服务A是微服务B的调用方时，我们称B是A的下游服务，而A是B的上游服务。比如图3-1中的内容列表服务是个人页服务的下游服务，内容列表服务、内容服务、关系服务是计数服务的上游服务。一个微服务的上游服务和下游服务都会影响它的服务质量。以内容列表服务为例，如果个人页服务（上游服务）向内容列表服务发起大量网络调用，内容列表服务可能会因为承受超过此时处理能力的请求量而被打垮；如果内容服务（下游服务）的服务质量不佳，内容列表服务总是无法获取到用户内容数据，那么服务的可用性也会随之下降。
在微服务架构中，为了解决上述种种影响服务可用性的问题，笔者认为可以从如下两个方面来考虑。
- 容错性设计。要接受网络脆弱与下游服务质量不可靠的事实，并在进行服务设计时充分考虑相应故障产生时的容错方案。
- 流量控制。既要对上游服务调用采取预防性策略，防止打垮我们的服务；也要对下游服务有感知与保护意识，当感知到下游服务的质量下滑甚至服务不可用时，及时通过自身保护下游服务。
接下来依次介绍服务可用性治理的5种通用方案：重试、熔断、隔离、限流、降级。重试与降级是容错性设计的具体表现形式，熔断、隔离与限流则是流量控制的常见实现方式。