微服务平台可靠性设计

微服务平台可靠性设计

目录

1.背景 (5)

1.1.无处不在的故障 (5)

1.1.1.分布式部署和调用 (5)

1.1.2.大型系统微服务进程内合设 (6)

1.1.3.微服务健康度 (7)

1.1.4.同步的I/O操作 (8)

1.1.5.第三方SDK API调用 (9)

1.2.微服务可靠性 (9)

1.2.1.关键的可靠性因素 (10)

2.异步I/O操作 (10)

2.1.网络I/O (10)

2.1.1.使用同步阻塞I/O的问题 (10)

2.1.2.使用非阻塞I/O通信 (11)

2.2.磁盘I/O (12)

2.3.数据库操作 (15)

3.故障隔离 (16)

3.1.通信链路隔离 (16)

3.2.调度资源隔离 (18)

3.2.1.微服务之间隔离 (18)

3.2.2.第三方依赖隔离 (19)

3.3.进程级隔离 (19)

3.3.1.容器隔离 (19)

3.3.2.VM隔离 (20)

4.集群容错 (21)

4.1.路由容错 (21)

4.2.服务降级 (21)

4.2.1.强制降级 (22)

4.2.2.容错降级 (22)

4.2.3.服务降级Portal (23)

4.3.熔断机制 (23)

4.3.1.工作原理 (24)

4.3.2.微服务健康度 (25)

5.流量控制 (25)

5.1.动态流控 (26)

5.2.静态流控 (27)

5.3.用户自定义流控机制 (27)

6.使用Hystrix提升微服务可靠性 (28)

6.1.Hystrix简介 (28)

6.2.Hystrix的核心功能 (28)

6.2.1.依赖隔离 (28)

6.2.2.熔断器 (29)

6.2.3.优雅降级 (30)

6.2.4.Reactive编程 (31)

6.2.5.信号量隔离 (31)

6.3.集成Hystrix (32)

6.3.1.集成架构 (32)

6.3.2.集成Hystrix带来的优点 (33)

7.附录 (33)

7.1.参考文献 (33)

背景

微服务化之后，系统分布式部署，传统单个流程的本地API调用被拆分成多个微服务之间的跨网络调用，由于引入了网络通信、序列化和反序列化等操作，系统发生故障的概率提高了很多。

微服务故障，有些是由于业务自身设计或者编码不当导致，有些是底层的微服务化框架容错能力不足导致。在实际项目中，需要从业务和平台两方面入手，提升微服务的可靠性。无处不在的故障

分布式部署和调用

传统单体架构一个完整的业务流程往往在同一个进程内部完成处理，不需要进行分布式协作，它的工作原理如下所示：

图1-1 传统单体架构本地方法调用

微服务化之后，不同的微服务采用分布式集群部署方式，服务的消费者和提供者通常运行在不同的进程中，需要跨网络做RPC调用，它的工作原理如下所示：

图1-2 微服务分布式RPC调用

分布式调用之后，相比于传统单体架构的本地方法调用，主要引入了如下潜在故障点：?序列化与反序列化：微服务的请求和应答都需要经过序列化和反序列化，做消息的跨网络通信，由于数据结构不一致、不支持的数据类型、对方编解码错误等都会导致序列化和反序列化失败，进而导致微服务调用失败。

?网络问题：常见的包括网络超时、网络闪断、网络单通、网络拥塞等，都可能会导致微服务远程调用的失败。

大型系统微服务进程内合设

理想情况下，每个微服务都独立打包和部署，微服务之间天然就支持进程级隔离，但事实上，对于一个大规模的企业IT系统、或者大型网站，是由成百上千个微服务组成的，在实践中，微服务通常是不可能做到百分之百独立部署的，原因如下：

1.方便开发：通常会按照业务域划分团队，同一个业务域往往包含多个微服务，由一个团

队负责开发。为了方便CI/CD，同一业务域的微服务往往打包和部署在一起，而不是每个微服务独立打包部署。

2.方便运维：海量的微服务进程（以1000个微服务* 10个进程实例为例），会增加部

署、数据采集（性能KPI和日志等）、告警、问题定位等成本，如果运维自动化程度不高，很难支撑大规模的微服务独立部署。

3.提升性能：一些业务对时延非常敏感，如果该业务链上的所有微服务调用都跨网络通信，

时延往往无法满足业务要求。通过将微服务合设在同一个进程之内，利用路由短路，把RPC调用转化成本地方法调用，可以极大的提升性能。

4.简化分布式事务处理：分布式部署之后，会带来分布式事务问题。有时候业务为了简化

分布式事务的处理，将事务相关的微服务部署在同一个进程中，把分布式事务转换成本地事务，简化事务处理。

不同的微服务合设在同一个进程之中，就会引入一系列潜在的故障点，例如：

?处理较慢的微服务会阻塞其它微服务

?某个微服务故障蔓延，可能导致整个进程不可用

?低优先级的微服务，抢占高优先级微服务的资源

微服务健康度

传统情况下，往往使用服务注册中心检测微服务的状态，当检测到服务提供者不可用时，会将故障的服务信息广播到集群所有节点，消费者接收到服务故障通知消息之后，根据故障信息中的服务名称、IP地址等信息，对故障节点进行隔离。它的工作原理如下所示：

图1-3 微服务状态检测

使用基于心跳或者会话的微服务状态检测，可以发现微服务所在进程宕机、网络故障等问题，但在实际业务中，微服务并非“非死即活”，它可能处于“亚健康状态”，服务调用失败率很高，但又不是全部失败。或者微服务已经处于过负荷流控状态，业务质量受损，但是又没有全部中断。

使用简单的微服务状态检测，很难应对上述这些场景。通过对微服务的运行质量建模，利用微服务健康度模型，根据采集的各种指标对微服务健康度实时打分，依据打分结果采取相应的可靠性对策，可以更有针对性的保障系统的可靠性。

同步的I/O操作

在整个微服务调用过程中，主要会涉及到三类I/O操作：

?网络I/O操作，涉及到网络读写

?磁盘I/O操作，主要是记录日志、话单、写本地文件等

?数据库访问，例如Java使用JDBC驱动进行数据库操作

图1-4 微服务涉及的主要I/O操作

凡是涉及到I/O操作的，如果I/O操作是同步阻塞模式，例如Java的BIO、文件File 的读写操作、数据库访问的JDBC接口等，都是同步阻塞的。只要访问的网络、磁盘或者数据库实例比较慢，都会导致调用方线程的阻塞。由于线程是Java虚拟机比较重要的资源，当大量微服务调用线程被阻塞之后，系统的吞吐量将严重下降。

第三方SDK API调用

在微服务中，调用第三方SDK API，也可能会引入新的故障点，例如通过FTP客户端访问远端的FTP服务，或者使用MQ客户端访问MQ服务，如果这些客户端API的容错性设计不好，也会导致调用方的级联故障，这些故障是潜在和隐性的，在设计的时候往往容易被忽视，但它带来的风险和危害是巨大的。

微服务可靠性

软件可靠性是指在给定时间内，特定环境下软件无错运行的概率。软件可靠性包含了以下三个要素：

1)规定的时间：软件可靠性只是体现在其运行阶段，所以将运行时间作为规定的时间的度

量。运行时间包括软件系统运行后工作与挂起(启动但空闲)的累计时间。由于软件运行

的环境与程序路径选取的随机性，软件的失效为随机事件，所以运行时间属于随机变量。

2)规定的环境条件:环境条件指软件的运行环境。它涉及软件系统运行时所需的各种支持

要素，如支持硬件、操作系统、其它支持软件、输入数据格式和范围以及操作规程等。

3)规定的功能:软件可靠性还与规定的任务和功能有关。由于要完成的任务不同，则调用

的子模块就不同(即程序路径选择不同)，其可靠性也就可能不同。所以要准确度量软件系统的可靠性必须首先明确它的任务和功能。

关键的可靠性因素

微服务的运行质量，除了自身的可靠性因素之外，还受到其它因素的影响，包括网络、数据库访问、其它相关联的微服务运行质量等。微服务的可靠性设计，需要考虑上述综合因素，总结如下：

图1-5 微服务可靠性设计模型

异步I/O操作

网络I/O

使用同步阻塞I/O的问题

以Java为例，在JDK 1.4推出JAVA NIO1.0之前，基于JAVA的所有Socket通信都采用了同步阻塞模式（BIO），这种一请求一应答的通信模型简化了上层的应用开发，但是

在可靠性和性能方面存在巨大的弊端：

2-1 传统Java 同步阻塞I/O模型

采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，接收到客户端连接之后为客户端连接创建一个新的线程处理请求消息，处理完成之后，返回应答消息给客户端，线程销毁，这就是典型的一请求一应答模型。该架构最大的问题就是不具备弹性伸缩能力，当并发访问量增加后，服务端的线程个数和并发访问数成线性正比，由于线程是JAVA虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统的性能急剧下降，随着并发量的继续增加，可能会发生句柄溢出、线程堆栈溢出等问题，并导致服务器最终宕机。使用非阻塞I/O通信

微服务进行远程通信时，通过使用非阻塞I/O，可以解决由于网络时延大、高并发接入等导致的服务端线程数膨胀或者线程被阻塞等问题。

以Java为例，从JDK1.4开始，JDK提供了一套专门的类库支持非阻塞I/O，可以在java.nio包及其子包中找到相关的类和接口。JDK1.7之后，又提供了NIO2.0类库，支持异步I/O操作。

利用JDK的异步非阻塞I/O，可以实现一个I/O线程同时处理多个客户端链路，读写操作不会因为网络原因被阻塞，I/O线程可以高效的并发处理多个客户端链路，实现I/O多

路复用，它的工作原理如下所示：

2-2 Java非阻塞I/O模型

使用非阻塞I/O进行通信，以Java语言为例，建议策略如下：

1)TCP私有协议：建议直接基于Netty开发。

2)HTTP/Restful/SOAP等：选择支持非阻塞I/O的Web框架。也可以选择基于Netty

构建的开源应用层协议栈框架，例如支持异步Restful的RestExpress。

磁盘I/O

微服务对磁盘I/O的操作分为两类：

?直接文件操作：例如调用File的open、write、read等接口，进行文件操作。

?间接文件操作：例如调用日志类库写日志，虽然微服务并没有直接操作日志文件，但是日志类库底层还是会进行文件的读写等操作。

在实际项目中，最容易被忽视的就是日志操作。不同的日志类库，写日志的机制不同，以Log4j 1.2.X版本为例，当日志队列满之后，有多种策略：

?同步等待，直到新的日志消息能够入队列，它会阻塞当前业务线程。

?丢弃当前的日志消息，不会阻塞当前业务线程。

?不入队列，由当前调用写日志的业务线程执行日志I/O操作，如果此时磁盘I/O写入

速度慢，则会阻塞当前业务线程。

在实际生产环境中，我们就遇到过类似问题，在某些时段，磁盘WIO达到10+持续几秒钟-10几秒钟，然后又恢复正常。WIO较高的时段，需要写接口日志、话单等，由于系统默认采用的是同步等待策略，结果导致通信I/O线程、微服务调度线程等都被阻塞，最终链路因为心跳超时被强制关闭、微服务被大量阻塞在消息队列中导致内存居高不小、响应超时等。

由于偶现的WIO高导致同步写日志被阻塞，继而引起通信线程、微服务调用线程级联故障，定位起来非常困难，平时Code Review也很难被注意到。所以，隐性的磁盘I/O操作，更需要格外关注。

要解决上面的问题，有三种策略：

?使用非阻塞I/O,对文件进行异步读写操作。

?业务层面封装一个异步的I/O操作，最简单的策略就是由一个独立的线程或者线程池来执行磁盘I/O操作。

?选择支持非阻塞方式调用的I/O类库，例如使用log4j的异步日志API。

以JDK1.7为例，它提供了异步的文件I/O操作类库，基于该类库，就不需要担心磁盘I/O操作被阻塞：

2-3 JDK1.7异步非阻塞文件接口

自己在上层封装异步I/O操作，也比较简单，它的优点是可以实现磁盘I/O操作与微服务之间的线程隔离，但是底层仍然使用的是同步阻塞I/O，如果此时磁盘的I/O比较高，依然会阻塞写磁盘的I/O线程。它的原理如下所示：

2-4 应用层封装的异步文件操作

将文件I/O操作封装成一个Task或者Event，投递到文件I/O线程池的消息队列中，

根据投递结果，构造I/O操作相关联的Future对象给微服务调用线程。通过向Future对象注册Listener并实现callback接口，可以实现异步回调通知，这样微服务和文件I/O操作就实现了线程隔离。文件I/O操作耗时，并不会阻塞微服务调度线程。

当使用第三方文件I/O操作类库时，需要注意下相关API，尽量使用支持异步非阻塞接口的API，如果没有，则需要考虑是否做上层的异步封装。

数据库操作

部分数据库访问支持非阻塞方式，例如Oracle的OCI，它支持non-blocking模式和blocking模式：阻塞方式就是当调用OCI操作时，必须等到此OCI操作完成后服务器才返回客户端相应的信息，不管是成功还是失败。非阻塞方式是当客户端提交OCI操作给服务器后，服务器立即返回OCI_STILL_EXECUTING信息，而并不等待服务端的操作完成。对于non-blocking方式，应用程序若收到一个OCI函数的返回值为OCI_STILL_EXECUTING时必须再次对每一个OCI函数的返回值进行判断，判断其成功与否。可通过设置服务器属性为OCI_ATTR_NONBLOCKING_MODE来实现。

对于Java语言而言，由于JDK本身提供了数据库连接驱动相关的接口定义，JDBC驱动本身就是同步API接口，因此，Java语言的开源ORM框架也都是同步阻塞的，例如MyBatis、Hibernate等。

尽管大部分数据库访问接口是同步阻塞的，但是由于数据库中间件的超时控制机制都比较成熟，因此通过合理设置超时时间，可以避免微服务的数据库访问被长时间挂住。

也可以在应用上层封装异步数据库操作层，实现微服务调度与数据库操作的线程级隔离，原理2.2章节已经介绍过，采用该方式同样存在两点不足：

排队现象：如果某个数据库操作非常耗时，超时时间配置的又比较大（例如30S），会导致后续的数据库操作在队列中排队。

无法充分发挥数据库效能：由于底层数据库访问采用同步阻塞的方式，所以不能高效发挥数据库的效能。

故障隔离

由于大部分微服务采用同步接口调用，而且多个领域相关的微服务会部署在同一个进程中，很容易发生“雪崩效应”，即某个微服务提供者故障，导致调用该微服务的消费者、或者与故障微服务合设在同一个进程中的其它微服务发生级联故障，最终导致系统崩溃。

为了避免“雪崩效应”的发生，需要支持多种维度的依赖和故障隔离，以实现微服务的HA。

通信链路隔离

由于网络通信本身通常不是系统的瓶颈，因此大部分服务框架会采用多线程+单个通信链路的方式进行通信，原理如下所示：

3-1 多线程-单链路P2P通信模式

正如前面章节所述，由于微服务使用异步非阻塞通信，单个I/O线程可以同时并发处理多个链路的消息，而且网络读写都是非阻塞的，因此采用多线程+单链路的方式进行通信

性能本身问题不大。但是从可靠性角度来看，只支持单链路本身又存在一些可靠性隐患，我们从下面的案例中看下问题所在。

某互联网基地微服务架构上线之后，发现在一些时段，经常有业务超时，超时的业务没有固定规律。经定位发现当有较多的批量内容同步、语音和视频类微服务调用时，系统的整体时延就增高了很多，而且存在较突出的时延毛刺。由于这些操作获取的消息码流往往达到数M到数十兆，微服务之间又采用单链路的方式进行P2P通信，导致大码流的传输影响了其它消息的读写效率，增大了微服务的响应时延。

问题定位出来之后，对微服务之间的通信机制做了优化，节点之间支持配置多链路，每个链路之间还可以实现不同策略的隔离，例如根据消息码流大小、根据微服务的优先级等策略，实现链路级的隔离，优化之后的微服务通信机制：

图3-2 支持多链路隔离

调度资源隔离

微服务之间隔离

当多个微服务合设运行在同一个进程内部时，可以利用线程实现不同微服务之间的隔离。

对于核心微服务，发布的时候可以独占一个线程/线程池，对于非核心微服务，则可以共享同一个大的线程池，在实现微服务隔离的同时，避免线程过于膨胀：

图3-3 微服务之间故障隔离

假如非核心服务3发生故障，长时间阻塞线程池1的工作线程，其它与其共用线程池消息队列的非核心服务1和服务2只能在队列中排队等待，当服务3释放线程之后，排队的服务1和服务2可能已经超时，只能被丢弃掉，导致业务处理失败。

采用线程池隔离的核心服务1和服务2，由于各自独占线程池，拥有独立的消息队列，它的执行不受发生故障的非核心服务1影响，因此可以继续正常工作。通过独立线程池部署核心服务，可以防止故障扩散，保障核心服务的正常运行。

第三方依赖隔离

在微服务中通常会调用第三方中间件服务，例如分布式缓存服务、分布式消息队列、NoSQL服务等。只要调用第三方服务，就会涉及跨网络操作，由于客户端SDK API的封装，很多故障都是隐性的，因此，它的可靠性需要额外关注。

整体而言，第三方依赖隔离可以采用线程池+ 响应式编程（例如RxJava）的方式实现，它的原理如下所示：

1)对第三方依赖进行分类，每种依赖对应一个独立的线程/线程池。

2)微服务不直接调用第三方依赖的API，而是使用异步封装之后的API接口。

3)异步调用第三方依赖API之后，获取Future对象。利用响应式编程框架，可以订阅后

续的事件，接收响应，针对响应进行编程。

利用Netflix开源的hystrix + RxJava，可以快速实现第三方依赖的隔离，后续章节我们会详细介绍下如何使用。

进程级隔离

对于核心的微服务，例如商品购买、用户注册、计费等，可以采用独立部署的方式，实现高可用性。

容器隔离

微服务鼓励软件开发者将整个软件解耦为功能单一的服务，并且这些服务能够独立部署、升级和扩容。如果微服务抽象的足够好，那么微服务的这一优点将能够提升应用的敏捷性和自治理能力。

利用Docker容器部署微服务，可以带来如下几个优点：

?高效：Docker容器的启动和停止不需要几分钟，只要几百毫秒就足够了。使用Docker 部署微服务，微服务的启动和销毁速度非常快，在高压力时，可以实现秒级弹性伸缩。?高性能：Docker容器的性能接近裸的物理机，比VM平均高20%+。

?隔离性：利用Docker，可以实现0.1 core的隔离。基于细粒度的资源隔离机制，可以实现高密度的部署微服务，同时实现它们之间的资源层隔离，保障微服务的可靠性。?可移植性：在基于虚拟机的解决方案中，应用的可移植性通常来说会受到云提供商所提供的虚拟机格式限制。如果应用程序需要部署到不同类型的虚拟机中，需要针对特定的虚拟机格式做镜像文件，新增很多额外的开发和测试工作量。Docker容器的设计理念是“一次编写，到处运行”，这可以使开发者避免上面这种限制。

基于Docker容器部署微服务，实现物理资源层隔离示意图如下所示：

图3-4 基于Docker容器的微服务隔离

VM隔离

除了Docker容器隔离，也可以使用VM对微服务进行故障隔离，相比于Docker容器，使用VM进行微服务隔离存在如下优势：

1.微服务的资源隔离性更好，CPU、内存、网络等可以实现完全的资源隔离。

2.对于已经完成硬件虚拟化的遗留系统，可以直接使用已有的VM，而不需要在VM中

重新部署Docker容器。