上文给大家介绍的内容是微服务容错与隔离：隔离机制，那么本文就给大家来介绍微服务容错与隔离：微服务的风险；
微服务的风险
在微服务架构下，传统的单体应用被拆分为多个服务后，服务的数量变多了，同时之前单体架构下进程内部的方法调用转变为分布式网络环境下的远程调用，因此构建分布式微服务系统带来了额外的开销。
● 性能：分布式系统是跨进程、跨网络的调用，受网络延迟和带宽的影响。
● 可靠性：由于高度依赖于网络状况，任何一次的远程调用都有可能失败，随着服务的增多还会出现更多的潜在故障点。因此，如何提高系统的可靠性、降低因网络导致的故障率是系统构建的一大挑战。
● 异步：异步通信大大增加了功能实现的复杂度，并且有定位难、调试难等问题。
● 数据一致性：要保证分布式系统的数据强一致性成本是非常高的，需要在C（一致性）、A（可用性）、P（分区容错性）三者之间做出权衡。
下面是微服务场景下我们会面临的常见风险。
分布式固有的复杂性
分 布 式 系 统 的 CAP 理 论 告 诉 我 们 分 区 容 错 （ PartitionTolerance）是不可避免的。如下图所示，G1和G2是两台分布式跨网络的服务器，G1向G2发送一条信息，G2可能无法收到。所以，对于分布式系统，只要具有大于零的概率，根据墨菲定律你就不能避免它发生。
分布式系统中多个计算机在进行通信过程中，由于网络的不可靠性，每次网络通信都会伴随网络不可用的风险。即便网络通信正常，服务的延迟也会远远大于单机下的调用延迟。所以消息丢失或者延迟是非常普遍的情况。
基于上述分析，我们在进行微服务系统架构设计的时候，就必须考虑当网络分区出现时，分布式系统就会出现局部服务失效问题，我们需要做出相应的服务容错处理。
服务的依赖性
在微服务架构场景下，除了微服务自身缺陷造成的服务不可用，对基础设施的依赖、对上下游微服务的依赖都可能造成依赖错误的发生。相比服务自身失败而言，服务对外部平台的依赖往往更加难以发现和处理，服务依赖失败也是在设计微服务时需要重点考虑的失败因素。同时，细粒度的服务也增加了不同服务之间的依赖和级联影响，因为服务依赖失败而造成的失败扩散，或者核心服务对非核心业务的依赖，都会造成依赖风险。
雪崩效应
我们常把“基础服务故障”导致“级联故障”的现象称为雪崩效应。雪崩效应描述的是服务生产者不可用导致消费者不可用，并将不可用逐渐放大的过程。
软件系统会发生各种错误，如硬件设施的损坏、软件系统内存溢出和资源的OOM等问题，在微服务架构下，我们可能还会遇到的问题就是雪崩效应。微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此微服务之间难免存在依赖关系。在公司内部的网络拓扑中，我们会发现一个HTTP服务的请求往往会经历很多个服务节点，例如，一个电商平台的下单场景往往会经过如下链路：App客户端→API网关→账单服务→支付服务→库存服务。但是，在错综复杂的网络中各式各样的问题（硬件原因、软件原因）都会造成系统异常，难免有些请求会失败，雪崩效应就此产生。
● 硬件故障：比如宕机、机房断电、光纤被挖断等。
● 流量激增：比如异常流量或者用户重试导致的系统负载升高。
● 程序Bug：比如代码循环调用的逻辑问题、资源未释放引起的内存泄漏问题等。
● 线程同步等待：系统间经常采用同步服务调用模式，核心服务和非核心服务共用一个线程池和消息队列，如果一个核心业务线程调用非核心线程，这个非核心线程交由第三方系统完成，当第三方系统本身出现问题时，导致核心线程阻塞，一直处于等待状态，而进程间的调用是有超时限制的，最终这条线程将断掉，引发雪崩效应。
总之，面对微服务架构场景下的风险，我们需要一定的应对措施和容错策略，下面是我们总结的容错管理的主要原则：
● 按照进程或者线程进行软件的划分和隔离。
● 将错误限制在可以快速失败（fail-fast）的软件模块中，避免错误模块对整体系统造成影响。
● 使用备份机制或者集群方式应对硬件或者软件的故障。
本文给大家讲解的内容是微服务容错与隔离：微服务的风险
下篇文章给大家讲解的内容是微服务容错与隔离：降级保护
觉得文章不错的朋友可以转发此文关注小编；
感谢大家的支持！
