使用服务隔离方法提高系统可行性.docVIP

使用服务隔离方法提高系统可行性 　　1引言 　　大型网站及软件系统，其高可用性直接影响客户体验，这是大型网站都需要面对的基础性课题。高可用性涉及到IT基础设施、软硬件架构、开发测试、运维等各个方面。目前，大型网站通常是领域业务多元化，面临高并发、高流量的挑战。为了获得更好的性能和可扩展性，按照服务组件化设计思想，以领域业务为功能单元做垂直切分，各模块之间提供服务接口关联起来，这样可以提高整个系统的可用性。然后随着应用规模的扩大，服务之间的依赖关系更为复杂，如何在系统出现故障或异常时，避免由”点故障”到“面故障”的扩散，避免不同领域业务相互影响，避免非核心影响核心，是开发者在做应用架构设计与物理部署架构设计时必须要考虑的问题。本文结合日常项目中的实践经验，提出在服务组件化的过程中，如何做服务级故障隔离的原则和方法，提升网站可用性这一需求。1 服务级隔离基本思想形式上，系统与系统之间，服务与服务之间(无论是两个服务是否为同一业务组件)存在以下两种依赖关系。⑴ 强依赖。所谓A系统强依赖于B系统是指，A系统必须依赖B系统的处理结果，才能正常的完成逻辑;简单的来说，如果B不能提供服务，A也无法正常工作。从高可用性设计的角度出发，在这种依赖关系下，A与B系统需要达到如下几点目标：对于B系统，A直接RPC调用，B在承诺的SLA基础上，做好自我保护;B系统宕机时，A尽管不能使用，但要保证机器不挂掉;B系统故障恢复时，A可以自动快速恢复;B故障时，A可以自动检测，自动降低或关闭对B的访问，防止情况恶化。⑵ 弱依赖。所谓A系统弱依赖于B系统，是指B系统如果发生了故障，A系统可以继续提供正常的服务。弱依赖通常有这些特点：可以不等待B结果的返回(比如发送消息、ajax区域加载);B是非核心功能，结果不返回不影响A的关键流程(合理超时时间的控制)，A、B的调用可以是异步(队列、线程的FutureTask、协程akka);对B的服务调用可通过功能开关实现降级。针对强依赖与弱依赖的不同特点，在架构和设计时，为避免故障或异常时由“点故障”到“面故障”的扩散，我们考虑在区分核心与非核心(服务、组件、产品重要度分级)、按功能组与后台依赖隔离、同一容器内服务间隔离、按客户群体DNS层隔离、引入异步模式隔离服务调用者与提供者等层面和场景下提供服务故障隔离策略和方法。 　　2 具体隔离策略与方法的设计 　　本节根据服务之间的依赖关系以及物理部署结构等特点，总结服务间如何做隔离和解耦的策略和方法。2.1 服务间依赖隔离与解耦在服务A与B存在强依赖的情况下(如图1所示)，描述RPC与基于Queue两种方式的区别。图1 RPC方式的强依赖关系通常系统TPS(每秒事务处理量)、RT(响应时间以毫秒计算)、CurrentNum(并发数)有如下关系：tps=(1000/responseTime)lowast;currentNum) (公式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调用，超时控制在异常时刻是决定性问题。在强依赖的情况下，除了需要在采用RPC调用的时候合理的设置超时外，在架构时可用采用基于消息队列的方式，来达到服务间由于容量不匹配导致的强耦合(如图2所示)。图2中，如果调用者不需要服务方返回结果，则椭圆框的部分是不需要的。图2 基于Queue的依赖关系与基于RPC的方式相比，队列模式有如下特点。⑴ 为服务调用者与服务提供者解耦，队列模式尤其适合弱依赖情况下的异步单相消息模式。⑵ 引入队列中间层可以对任务做优先级、丢弃策略、持久化等，同时由于中间节点的存在，也引入了复杂性，从响应时间来看，与RPC方式相比会有所增加。⑶ 在应对突发尖峰流量时，服务端可以实现压力逐步释放的目标，保持稳定吞吐率，达到“稳定消化能够处理的量，快速丢掉不能消化的量”，客观上达到了服务组件间解耦的目的。2.2 同一容器内服务间线程隔离在系统服务化的切分过程中，通常是以业务领域的切分为依据，属于同一业务领域的服务在部署时基本部署在同一个容器中。由于各个服务对于资源的消耗不同，响应时间与关联组件也不相同，导致在容器线程总数固定情况下，其中一个服务突然变慢会占用大量线程，导致线程耗尽。同时线程数飙升