上一期我们谈到了阿里巴巴早期是通过通过在 Nginx 上实现的扩展组件TMD（taobao missile defense淘宝导弹防御系统）实现了接入层限流的主要工作，TMD系统可通过域名类限流、cookie限流、黑名单以及一些安全策略等很好的实现了在接入层的限流措施。
但对于服务层，TMD就无能为力了。对于实现服务的限流控制，传统的实现方式通常用spring的AOP机制，对需要限流的接口定义一个advice拦截器，但这套方案在实际应用场景中还是会发现不少问题。详细问题可通过以下的传送门，进行了解。
一、Sentinel 简介
第二期我们将分享到阿里巴巴是如何解决服务层限流时遇到的问题的。在今年7月底的Aliware Open Sourec深圳站的活动上，阿里巴巴宣布开源面向分布式服务架构的轻量级限流降级框架 Sentinel。Sentinel正如它英文的意思“哨兵”一样，为整个服务化体系的稳定运行行使着警戒任务，是对资源调用的控制平台，主要涵盖了授权、限流、降级、调用统计监控四大功能。
- 授权：通过配置白名单和黑名单的方式分布式系统的接口和方法进行调用权限的控制；
- 限流：对特定资源进行调用的保护，防止资源的过度使用；
- 降级：判断依赖的资源的响应情况，但依赖的资源响应时间过长时进行自动降级，并且在指定的时间后自动恢复调用；
- 监控：提供了全面的运行状态监控，实时监控资源的调用情况，如QPS、响应时间、限流降级等信息；
Sentinel 平台有两个基础概念，资源和策略，对特定的资源采取不同的控制策略，起到保障应用稳定性的作用。Sentinel 提供了多个默认切入点，比如服务调用时，数据库、缓存等资源访问时，覆盖了大部分应用场景，保证对应用的低侵入性，同时也支持硬编码或者自定义AOP的方式来支持特定的使用需求。
二、Sentinel 限流的实现原理
Sentinel 平台架构图如下，需要通过Sentinel 实现限流功能的应用中都嵌入Sentinel 客户端，通过Sentinel 客户端中提供对服务调用和各资源访问缺省实现的切入点，使得应用完全不需要对实现限流的服务或资源进行单独的AOP配置和实现，同时不仅可以限制自己的应用调用别的应用，也可以限制别的应用调用我的应用。通过这些资源埋点实时计算当前服务的QPS，也可通过现有的监控系统获取到应用所在服务器的相关系统监控指标，用于限流规则配置中的阀值比对。
▵Sentinel 平台架构示意图
Sentinel控制台会从客户端拉取资源实时的运行监控数据如QPS、响应时间等，并展示在控制台的监控面板上。控制台给运维人员提供了针对服务、缓存、数据库等资源访问设置各种限流规则，并将设置好的规则发送到规则配置中心后，再有服务器将规则推送到相关的Sentinel客户端，让设置的规则最终在应用运行状态是时快速生效。
三、Sentinel 降级的实现原理
Sentinel平台除了限流的核心功能外，还提供了降级的功能。我们知道，在服务调用链上，存在服务间的强弱依赖，即有些业务请求处理过程中，有些服务是否正常被调研或成功处理了服务请求，对于整个业务请求不会产生决定性的影响，比如交易链路中快递优惠这个服务，这类服务调用链中就会标记为弱依赖的服务。
设想一下，如果在双11活动启动后，大量的用户订单请求涌入平台，此时发现平台的整体水位已经像平台最大处理能力的水位逼近时，除了限流可以起到第一层的保护作用外，我们还可以将那些之前标记为弱依赖的服务平滑下线，也就是让订单创建的处理流程中去掉那些弱依赖的服务调用，达到将节省出的系统资源更好地服务于核心服务的运行；又或者在大促时，某核心服务依赖某一个非核心的服务，但发现因为这个非核心服务的处理性能和服务响应时间较长，导致了当前核心服务的处理出现了瓶颈，这时为了保证核心服务的正常处理，就需要在核心服务业务逻辑中对于那个非核心服务的调用暂时停止。这样类似的场景就称为服务降级，即从服务调用者的角度，对所依赖的下游服务采取停止调用的措施，以保证当前服务的处理效率。
要实现服务降级，需要在应用或服务实现中，首先留下可供服务降级进行服务是否调用切换的逻辑。一般在代码中采用static值的方式，作为业务逻辑分支的判断条件，通过对这些static值的修改，实现服务调用逻辑的变化。同样可以通过Sentinel控制台提供的降级规则的配置功能，当对某个服务的方法响应时间一旦超过阀值后，就意味着调用的这个服务已经出现了处理性能的问题，则会自动切换到降级模式，降级持续的时间可自定义设置。
四、Sentinel 限流的实现原理
总结来说，Sentinel平台所提供的限流和降级功能，是今天阿里巴巴集团如此庞大、复杂的服务化平台稳定运行的关键，不管是在双11这样的大促活动中，还是几乎每天都有基于服务化体系构建起来的新兴业务上线，整个服务化平台能够稳定运行直观重要。从技术角度来说，企业如果要构建自身的服务化平台，如何保障平台稳定性运行的重要能力是服务化平台建设中一定要考虑的问题。
限流和降级是从服务自身做好保护的角度来避免平台级的故障。在分布式服务环境下， 我们不可忽略的一个问题是最大程度的增加机器的利用率，通常会采用超配的方式，但这个过程中往往会出现超配服务器上的应用对资源进行争抢，使得个别或局部应用出现服务响应慢甚至挂起，从而给整个业务链路带来更大的风险的情况。此时，流量调度的角色是至关重要的。下一期我们将从流量调度的角度看看如何提升平台的稳定性。
