探讨使用服务隔离方法提高系统可用性

1、讨论使用效劳隔离方法进步系统可用性0 引言大型网站及软件系统，其高可用性直接影响客户体验，这是大型网站都需要面对的根底性课题。高可用性涉及到IT 根底设施、软硬件架构、开发测试、运维等各个方面。目前，大型网站通常是领域业务多元化，面临高并发、高流量的挑战。为了获得更好的性能和可扩展性，按照效劳组件化设计思想，以领域业务为功能单元做垂直切分，各模块之间提供效劳接口关联起来，这样可以进步整个系统的可用性。然后随着应用规模的扩大，效劳之间的依赖关系更为复杂，如何在系统出现故障或异常时，防止由点故障到面故障的扩散，防止不同领域业务互相影响，防止非核心影响核心，是开发者在做应用架构设计与物理部署架构设计

2、时必需要考虑的问题。本文结合日常工程中的理论经历，提出在效劳组件化的过程中，如何做效劳级故障隔离的原那么和方法，提升网站可用性这一需求。1 效劳级隔离根本思想形式上，系统与系统之间，效劳与效劳之间(无论是两个效劳是否为同一业务组件)存在以下两种依赖关系。 强依赖。所谓A 系统强依赖于B 系统是指，A 系统必须依赖B 系统的处理结果，才能正常的完成逻辑;简单的来说，假设B 不能提供效劳，A 也无法正常工作。从高可用性设计的角度出发，在这种依赖关系下，A 与B 系统需要到达如下几点目的：对于B 系统，A 直接RPC 调用，B 在承诺的SLA 根底上，做好自我保护;B 系统宕机时，A 尽管不能使用，

3、但要保证机器不挂掉;B 系统故障恢复时，A 可以自动快速恢复;B 故障时，A 可以自动检测，自动降低或关闭对B 的访问，防止情况恶化。 弱依赖。所谓A系统弱依赖于B 系统，是指B 系统假设发生了故障，A 系统可以继续提供正常的效劳。弱依赖通常有这些特点：可以不等待B 结果的返回(比方发送消息、ajax 区域加载);B 是非核心功能，结果不返回不影响A 的关键流程(合理超时时间的控制)，A、B 的调用可以是异步(队列、线程的FutureTask、协程akka);对B 的效劳调用可通过功能开关实现降级。针对强依赖与弱依赖的不同特点，在架构和设计时，为防止故障或异常时由点故障到面故障的扩散，我们考虑

4、在区分核心与非核心(效劳、组件、产品重要度分级)、按功能组与后台依赖隔离、同一容器内效劳间隔离、按客户群体DNS 层隔离、引入异步形式隔离效劳调用者与提供者等层面和场景下提供效劳故障隔离策略和方法。2 详细隔离策略与方法的设计本节根据效劳之间的依赖关系以及物理部署构造等特点，总结效劳间如何做隔离和解耦的策略和方法。2.1 效劳间依赖隔离与解耦在效劳A 与B 存在强依赖的情况下，描绘RPC与基于Queue 两种方式的区别。通常系统TPS(每秒事务处理量)、RT(响应时间以毫秒计算)、CurrentNum(并发数)有如下关系：tps=(1000/responseTime)currentNum) (

5、公式1)根据公式1，按B 系统正常情况与异常情况，分别计算对A系统的影响。正常情况：A 系统对外承诺500 的TPS，系统的平均响应时间为100ms，这时候只需要50 个线程并行即可支撑。故障情况：B 系统变慢，导致A 的平均响应时间变为1000ms，如今A系统的线程数是500。B 系统的异常，在直接RPC 的调用情况会导致A 系统宕机，同时B 系统由于A 系统的并发访问数由50 变为500，B 系统进一步恶化。由此可见，在RPC 的调用方式下，无论是同步调用还是异步调用，对于效劳器端都是直接压力传导，在A 与B是强依赖的情况下，假设是同步RPC 调用，超时控制在异常时刻是决定性问题。在强依赖

6、的情况下，除了需要在采用RPC 调用的时候合理的设置超时外，在架构时可用采用基于消息队列的方式，来到达效劳间由于容量不匹配导致的强耦合。假设调用者不需要效劳方返回结果，那么椭圆框的部分是不需要的。基于Queue的依赖关系与基于RPC的方式相比，队列形式有如下特点。 为效劳调用者与效劳提供者解耦，队列形式尤其适宜弱依赖情况下的异步单相消息形式。 引入队列中间层可以对任务做优先级、丢弃策略、持久化等，同时由于中间节点的存在，也引入了复杂性，从响应时间来看，与RPC方式相比会有所增加。 在应对突发尖峰流量时，效劳端可以实现压力逐步释放的目的，保持稳定吞吐率，到达稳定消化可以处理的量，快速丢掉不能消化

7、的量，客观上到达了效劳组件间解耦的目的。2.2 同一容器内效劳间线程隔离在系统效劳化的切分过程中，通常是以业务领域的切分为根据，属于同一业务领域的效劳在部署时根本部署在同一个容器中。由于各个效劳对于资源的消耗不同，响应时间与关联组件也不一样，导致在容器线程总数固定情况下，其中一个效劳突然变慢会占用大量线程，导致线程耗尽。同时线程数飙升，引起Context Switch1加剧，在JAVA 平台下，还会引起对象生命周期变长，Full GC频繁，CPU Load Average和Usage高企，最终容器整体宕机。为解决容器内的效劳线程隔离问题，在理论中首先需要根据历史访问数据及系统容量规划的数据，计

8、算出每个效劳的峰值与均值并发数、响应时间、交易吞吐率等，详细的数据采集与分析过程在本文中不作详述。对于效劳隔离策略的设计可以采用定额与弹性资源配置两种方式。 悲观策略：对于每个效劳设定固定的最大资源量，任何一种效劳当访问量到达最大时，即使总资源存在充裕也不能使用。 乐观策略：在保证每种效劳预留最低资源的情况下，允许任务根据一个弹性配额去争抢线程资源，到达线程利用率的最大化。2.3 核心与非核心效劳隔离组件A 与组件B 都强依赖于组件C，同时组件C 强依赖于组件D。其中组件A 属于非核心业务组件，B 属于核心业务组件。由于C 组件总体处理才能是固定有限的(假定平均响应时间100ms,最大TPS

9、为3000/s)，当A 组件由于突发流量的影响，对C 组件访问量变大，或者A 组件的某些恳求会消耗C 组件较多的资源时，导致C 组件不能处理B 组件的恳求，级联导致B 系统出现故障的情况发生。在这个场景下，虽然A 与B 在物理部署上已经做了隔离，但是复杂的关联组件依赖关系，间接导致因为非核心业务组件影响核心业务组件的事例。为防止上述问题的发生，可以考虑以下两种隔离策略。 假设C 组件及其关联组件程度伸缩后，可以支持更高的性能，推荐采用路由隔离方式进展，即A 组件与B 组件分别访问不同C 组件效劳群组。 C 系统不具备进一步程度扩展的才能(比方瓶颈点不在C，而在于C 所依赖的系统D);这个时候可

10、以在C 系统上设置流量控制和功能开关标志位，在异常情况下可以限制或关闭非核心系统对C 的访问。2.4 效劳功能开关与降级的设计在各种效劳隔离策略中，当异常流量发生时，在理解全局效劳依赖关系和效劳重要度排列的根底上，架构设计中通常使用功能开关和效劳降级的策略来分解流量，到达丢卒保车的目的来应对突发状况。在详细的理论中主要考虑三个方面。 管理全局性效劳组件的依赖关系，识别各效劳调用链中的关键途径。在大型网站中，通常存在上千级别的组件，效劳之间的依赖关系异常复杂，大部分网站都实现了基于Google的Dapper系统的分布式系统监控与依赖分析系统。 功能开关的设计。在设计实现时，存在单机与集群的区别。

11、单机实现时，对于JAVA 平台建议使用JMX 标准实现，这样做的好处是可以纳入统一的监控体系，使用JConsole 等通用JMX Client 可以处理;集群实现时，由于需要对大量节点统一管控，建议使用Zookeeper 之类的配置管理系统来实现。 自动降级与手动降级的设计与运用。自动功能开关的设计主要是首先确定判断异常情况的阈值，比方单位时间内效劳调用超时或失败比例超过70%，或者连续失败或超时到达20。此时系统可以把访问窗口按指数降低，直到降为1;效劳恢复类似于TCP 的慢启动，窗口逐渐翻开。对于封闭点，应该尽可能提早;对于一些关键系统，如支付类系统，最好防止使用自动开关，在接到监控系统报警后，人工介入决定是否需要降级和关闭。3 完毕语目前新华网要求整体可用性到达99.99%级别，这意味着全年方案停机时间加上非方案停机时间不到53 分钟。系统的高可用性是一