转载

服务容错和故障隔离（2.21）

不论是在ESB服务总线还是微服务网关设计过程中，都会涉及到如何提升服务运行高可靠性的问题，对于硬件基础设施架构的HA设计或集群扩展是一方面，更加重要的是服务容错和故障隔离机制设计，其设计的核心目的就是将单个服务或某类服务发生故障或性能问题的时候影响扩展到最小。

先将下故障隔离，顾名思义即当服务发生故障或性能问题的时候其影响是被隔离或在一个受控范围，而不会波及到ESB平台所有正在运行的服务。要达成这个目标，在整体规划和架构设计的时候可以考虑的包括：

1.服务分域进行部署

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

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

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

服务限流和熔断机制是ESB平台进行故障隔离的关键手段之一，即在同一个域需要保障当一个服务发生故障或性能异常调用的时候不影响到其它服务。举例来说，当一个服务调用出现大量超时等待，那么一定会保持相当多的长连接，这些本身就极大消耗JVM内存；或者说某个数据服务出现大并发调用，本身传递的数据量有很大，在这种大并发调用下也将极大消耗JVM内存和总线吞吐能力而影响到其它服务。

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

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

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

要做到如上内容，那我们在设计和实现的时候至少要包括如下内容，1）服务预警策略设置，可以根据错误次数，时间，并发数等多维度设置预警策略。2）实时的服务运行次数和时间监控，健康性能数据采集 3）内存计算，当前的运行数据是否满足服务预警和限流策略启动要求 4）启动实际的服务控制操作。

对于服务容错，可以看到很多都会谈到上面说的故障隔离方面的内容，那么除了故障隔离以外，服务容错是否还有其它方面的一些内容可以考虑？当从字面上理解，服务容错更多应该是单个服务本身的容错性是如何的？对于容错性设计采用了哪些技术手段。那么可以考虑的就有：

3.服务本身的重试机制

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

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

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

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

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

幂等设计：对于正向服务在设计完成后，能够设计一个幂等的反向服务将数据回退到初始状态。

重试设计：服务需要支持重试，比如导入类服务不管同样的数据调用多少次都不会引起垃圾数据的产生。

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

对于有些服务的异常调用，当出现调用异常后是不能简单的靠系统自动进行回退或冲正处理的，即存在某些不能设计为幂等的服务出现调用异常。那么在这种场景下出现服务异常就必须设计完善的异常日志查看和异常通知机制。当出现这种情况时候，能够及时通知系统或业务人员进行手工修正处理。

原文 http://blog.sina.com.cn/s/blog_493a84550102wq6d.html

正文到此结束