今天谈下服务容错和故障隔离，在谈这个话题的过程中一些实践会围绕我们自己的ESB总线，API网关和MFT传输平台架构设计实践来展开说明。

概述

先来谈下服务容错和故障隔离这两个概念。

服务容错强调的是一个业务系统或中间件产品对外提供的服务能力本身对内部出现故障的一种容忍能力。也就是说当业务系统内部出现故障的时候，是否能够仍然持续对外提供服务，故障并不需要外部最终的客户感知到。在IT基础设施中的高可用，高可靠设计，很多都是基于服务容错的要求。

比如常用的HA，集群架构设计等。

故障隔离简单来说就是业务系统故障错误已经必须对外暴露，对业务造成影响。那么这个时候如何将影响面控制到最小，将故障隔离到一定波及范围内。这个范围可以是业务系统的功能范围，也可以是用户范围。

比如常说的服务限流熔断，分域设计等即是将影响控制到某一个服务。

不论是服务容错还是故障隔离，实际都包括了IT基础设施架构设计和应用架构设计两个方面的内容，比如常说的HA架构属于IT基础设施方面架构内容，但是对于分布式集群架构则属于应用层架构设计方面的内容。

IT基础设施架构设计

先谈下IT基础设施方面相关的服务容错和故障隔离设计。

对于服务容错即常说的高可用和高可靠设计，主要的架构设计方法包括了HA架构，集群架构。在数据库层面又演化了类似主从集群，双主架构等。

不论是哪种设计，要做到的就是在物理设施和虚拟机逻辑设施层面不能存在任何的单点故障。比如常用的演练方法，你将任何一台硬件设备关机都不应该影响到业务系统的正常运行。

在架构设计的时候不仅仅是考虑类似虚拟机这种逻辑设施的冗余，更加需要考虑物理设施之间的冗余。举一个简单的例子，你在同一台x86物理服务器上面虚拟了两台虚拟机来构建一个应用集群。在这种场景下如果物理机故障，那么整个系统就完全宕机。

从容错到故障隔离

在IT基础设施架构层面，当考虑服务容错的时候，还需要考虑是否会引起故障蔓延的问题。比如在一个集群架构里面，当某一个集群节点出现大并发或大数据量访问的时候，一些高可用集群会自动地进行请求漂移，将没有完成的并发请求转移到其它集群节点。结果你会发现其它集群节点也无法承受如此大的数据量访问，因此其它集群节点也出现故障。

这就是典型的为了容错而导致了故障蔓延。

所以服务容错和故障隔离之间需要有一个均衡性的把握。如果从整个IT架构和全应用的视角，保证整个IT基础设施架构的稳定性远远比单个服务请求的高可用更加重要。

应用层的服务容错和故障隔离

在这里我们拿ESB总线或API网关的设计来举例说明。在这种技术中间件的设计过程中，不仅仅是IT基础设施层面的高可用，更加重要的是是服务容错和故障隔离机制设计，其设计的核心目的就是将单个服务或某类服务发生故障或性能问题的时候影响扩展到最小。

a.故障隔离设计

对于应用层的故障隔离，在整体规划和架构设计的时候可以考虑的包括：

1.服务分域进行部署

可以按业务，按系统，按服务类型，按服务SLA等级定义进行分域。比如对于ERP系统提供的服务单独部署一个域，或者对于数据类服务单独部署，或者对2-3个并发量极大的高SLA定义服务分域部署。这些本身都是可行的思路。

每一个域本身又有三个思路，其一是部署独立的应用服务器中间件，比如独立部署两套Weblogic或Tomcat中间件容器，这样做的话基本可以做到类似Docker提供的容器级资源隔离。其二是直接在中间件中进行分域部署，类似Weblogic本身就提供分域部署的能力，这种分域可最大的保护跨域之间相互不影响；最后一种方法是直接在一个Tomcat容器中，部署多个JVM实例，不同的WAR或JAR包运行在不同的JVM实例中，这样可以保障单个JVM内存溢出不会影响到其它JVM进程。

分域的核心目的就是保证资源或进程级别的隔离，这样不同域之间能做到相互不影响，即当服务运行发生故障的时候最多影响到服务当前运行域。

2.服务限流和熔断机制

服务限流和熔断机制是ESB平台进行故障隔离的关键手段之一，即在同一个域需要保障当一个服务发生故障或性能异常调用的时候不影响到其它服务。

举例来说，当一个服务调用出现大量超时等待，那么一定会保持相当多的长连接，这些本身就极大消耗JVM内存；或者说某个数据服务出现大并发调用，本身传递的数据量有很大，在这种大并发调用下也将极大消耗JVM内存和总线吞吐能力而影响到其它服务。

在这种场景下我们做故障隔离一般会分两步进行，即首先进行限流，限流还不行即进行熔断。

比如当出现一个大并发大数据传输的服务接口异常调用的时候，为了同时减轻ESB和下游系统的压力，首先可以考虑进行服务限流，即控制服务消费端服务请求的流入。控制流入本身又可以从两个方面来考虑，一个是对于超出预期数量的调用直接拒绝掉，还有一种即让超过预期数据的调用在外排队等待。

如果限流后仍然存在问题，比如服务调用时间仍然很长很慢，整个ESB总线的堆内存消耗始终降低不下来，那就说明服务本身出现故障，需要考虑对服务进行熔断处理以免故障扩散，即我们可以直接将注册在ESB上的服务禁用掉，这样就禁止了所有的服务调用请求，以保证其它服务的正常调用。

要做到如上内容，那我们在设计和实现的时候至少要包括如下内容。

1. 服务预警策略设置，可以根据错误次数，时间，并发数等多维度设置预警策略。
2. 实时的服务运行次数和时间监控，健康性能数据采集
3. 内存计算，当前的运行数据是否满足服务预警和限流策略启动要求
4. 启动实际的服务控制操作。

具体限流熔断的逻辑可以参考文章：

微服务和API网关限流熔断实现关键逻辑思路

b.服务容错设计

对于服务容错，可以看到很多都会谈到上面说的故障隔离方面的内容，那么除了故障隔离以外，服务容错是否还有其它方面的一些内容可以考虑？

当从字面上理解，服务容错更多的应该是单个服务本身的容错性是如何的？对于容错性设计采用了哪些技术手段。那么可以考虑的就有：

1.DB-引擎-管控三者分离

在进行API网关或MFT产品架构设计的时候，我们始终在强调一点就是应用架构设计里面的数据库，引擎，管控三者之间的解耦和分离。

什么意思？

简单来说就是一个API网关的运行，不会因为DB数据库宕机而导致API接口服务消费失败或无法正常调用。同样，API网关也不会因为管理平台无法正常使用而导致服务运行失败。反之同样，引擎当前不正常，管理平台也可以正常使用，查询和监控历史数据。

如何做到这点？

实际在前面我谈微服务高可用性设计的文章谈到过。即对于写入类操作通过消息中间件来实现异步化处理，而统一查询类操作即对常用元数据和配置进行缓存处理。

当采用消息中间件的时候，你需要考虑消息本身的可持久化问题，也需要考虑异常处理后带来的一致性问题。而采用缓存的时候，需要考虑缓存本身的同步和刷新问题。

2.服务本身的重试机制

在服务设计的时候，服务调用出现异常的时候需要支持服务重试很多时候都是一个标准设计，特别是在异步消息类服务集成过程中更加是必须支持服务重试。在实现过程中核心是消息中间件，即服务调用请求先会进入到JMS或AMQP的消息中间件和消息队列中，那么当服务调用出现错误的时候消息中间件本身很容易启动重试，而不需要服务调用方再次进行服务调用请求。

重试的次数，重试的间隔时间等本身应该可以灵活地进行设置和配置。

3.服务本身的回退或冲正机制

在ESB服务总线实施过程中，冲正这个词用得比较多，其核心的意思就是当服务（特别是组合类服务）调用出现异常的时候，能够通过调用幂等的负操作来讲已做过的操作退回到原始状态。这其实和我们经常谈的在分布式服务调用处理中的，服务补偿和回退操作。

对于分布式事务的处理，要明白BASE原则或者说基于服务幂等的服务补偿才是最靠谱的方式，而不是企业分布式事务控制机制。要支持冲正，则需要服务设计的时候必须能够设计对应的幂等负操作。

• 幂等设计：对于正向服务在设计完成后，能够设计一个幂等的反向服务将数据回退到初始状态。
• 重试设计：服务需要支持重试，比如导入类服务不管同样的数据调用多少次都不会引起垃圾数据的产生。

4.服务异常通知机制设计

对于有些服务的异常调用，当出现调用异常后是不能简单地靠系统自动进行回退或重正处理的，即存在某些不能设计为幂等的服务出现调用异常。

那么在这种场景下出现服务异常就必须设计完善的异常日志查看和异常通知机制。当出现这种情况的时候，能够及时通知系统或业务人员进行手工修正处理。

注：最近几篇文章开始控制在1个小时内写作完成，字数控制到3000字内，并适当减少配图，当前进入一个比较好的节奏。有好的节奏才可持续。另外公众号 人月聊IT 也欢迎关注，后续头条文章出出现过的一些原版材料，PPT我都会在公众号通过消息的方式推送。