读-李林峰-分布式服务框架和原理14-17

流量控制

通过合理设置流控配置，避免消费方的并发请求数超出服务提供方的承受能力，导致服务不可用。

静态流控

静态流控主要是针对客户端的并发请求进行控制，根据SLA的约定的QPS做全局流量控制。

传统静态流控设置，根据集群服务节点数量和流控阈值，计算各个节点的阈值，运行时，各个节点按照已分配的阈值进行流控（还有一种设计就是配置的流控阈值其实是节点的阈值，不是整个集群的全局数量）；



2点需要注意：

服务实例通常多线程执行，考虑线程安全，可以使用Atomic原子类进行原子操作；

到达流控阈值后拒绝请求接入，不能拒绝已有请求的服务方返回应答消息。

传统方案的缺点，新服务节点的加入，已有节点的宕机，云端部署服务的弹性伸缩，导致服务实例的动态变化，预分配的方案会发生变化，重新计算；

动态配额分配制，为解决静态流控的缺点，采用动态分配，原理：注册中心以流控周期T为单位，动态推送每个节点的流控阈值，节点变化时，注册中心重新计算节点阈值推送；



生产环境，节点的配置不同，采用上述总阈值/节点数的平均，导致性能高，处理块的节点，节点的配额很快用完，性能差的总是有剩余，解决方法就是注册中心做配额计算时，考虑服务节点的性能（例如服务调用时延）做加权，性能好的多分配，差的少分配；

另一种方案就是配额指标返还和重新申请，服务节点根据自身情况预测，对于分配的指标，多的就返还，少的就申请；

结合负载均衡做静态流控，消费者根据各服务节点的负载情况做加权路由，性能差的节点路由得到的消息更少，由于配额计算也根据负载做了加权调整，最终分配给性能差的接地啊配额指标也较少，这样既保证了系统的负载均衡，又实现了配额的更合理分配。

动态配额申请制，配额分配解决了服务节点变化的问题，也能够改善平均主义的分配，但是还有缺点：

流控周期T比较大，节点的负载变化比较快，服务节点的负载反馈到注册中心，注册中心计算后再做配额分配，可能误差比较大；

流控周期T比较小，注册中心需要实时获取节点的性能数据计算负载情况，采集、上报、汇总、计算，会存在一定的时延，导致流控滞后产生误差；

采用配额返还和重新申请，增加了交互次数，也有有误差；

扩展性差，主要是所有压力全在注册中心；

要解决上述问题，可以采用动态配额申请，原理：

部署时，根据服务节点数和静态流控阈值，拿出一定比例的配额做初始分配，剩余的放在资源池；

节点使用完初始分配的配额，再次申请配额；

总的配额使用完则流控。

优点：

服务节点负载和性能数据，在节点本身计算，实时性高；

节点根据自身情况计算申请配额，保证性能好的申请更多的配额，差的申请的就少，可以更合理的调配资源，流控的精确性有保障。

动态流控

动态流控因子，主要是引发动态流控的因素，包括系统资源和应用资源；

分级流控，不同级别的流控屏蔽多少请求，可以想象闸门关闭情况。

并发控制

并发执行数量控制：

- 服务端全局控制；

- 消费端的流控；

连接控制

服务端消费者之间的链路数量控制：

- 服务端连接数流控；

- 服务消费者连接数流控；

并发和连接控制算法

服务端算法：

获取流控阈值；

从全局rpc上下文获取并发执行数，对比阈值，小于，则对当前计数器原子自增；

等于或者大于，抛rpc流控异常；

服务调用完，并发执行数自减。

消费端算法：

获取流控阈值；

从全局rpc上下文获取并发执行数，对比阈值，小于，则对当前计数器原子自增；

等于或者大于，进入wait状态，wait超时时间为服务调用的超时时间；

其他线程完成服务调用，计数器减小，如并发执行数小于阈值，wait线程被notify，退出wait，继续执行。

熔断

不知道作者在流控这里没加熔断机制，通常情况下都是，流控配合熔断一起使用。

熔断可以理解为保险丝。由于提供方故障，导致服务不可用，如果这时候我们还不停的请求，就会导致阻塞，消耗系统资源，如果这种情况发生在调用链中，情况就会更严重。

1. 闭合状态，正常调用，记录调用结果，连续多少次失败，则转换状态为熔断打开；

2. 熔断打开状态，这种状态下，不容许服务调用，返回错误，一般来说，持续多少时间进入半打开状态；

3. 熔断半开状态，这种状态，可以按比例放行部分请求，持续多少时间无调用异常或多少次调用无异常，熔断开关关闭，放行所有请求。

服务降级

大促期间，会针对核心业务做流控和熔断，而对于非核心业务，通常的处理方式则是服务降级。

屏蔽降级

大促期间的，为保证核心业务的稳定性，对非核心业务做屏蔽降级，服务放通，当服务调用时，不发起远程调用，直接返回空，异常或执行本地逻辑。

屏蔽降级的流程



屏蔽降级的设计实现，配置平台人工设置降级策略，配置操作可逆：

容错降级

非核心业务不可用时，对故障做业务逻辑放通。不仅仅用于业务放通，也常用于提供方在客户端执行容错逻辑，容错逻辑主要有：

1. Rpc异常：超时异常、解码异常、流控异常、阻塞异常等；

2. Service异常：校验失败异常、数据库操作异常等；

容错降级的工作原理



容错降级与屏蔽降级区别：

触发条件不同，容错是根据调用结果触发，屏蔽通常是人工干预触发；

作用不同，容错是服务不可用时做放行，屏蔽是将原本要发起远程调用的服务做本地执行或异常等，将原属于降级业务的资源调配出来供核心业务使用；

调用机制不同，容错是会发起远程调用的，屏蔽不会发起远程，只做本地；



运行时容错降级，支持运行时，动态配置容错降级

业务层降级

业务层的处理通常包含一定业务逻辑和服务条用，在服务调用做降级后，业务层逻辑要支持服务降级后处理，做到业务层整体逻辑放行。

服务优先级调度

在系统资源有限的情况下，包含核心业务或高优先级的业务优先运行调度，降低低优先级服务的调度频次。

服务发布的时候支持优先级的设置。

线程调度器方案

线程调度的时候通过设置线程的优先级，理论上，高优先级的线程会优先调度，但是这种依赖底层，不一定精确。

优先级队列

基于优先级队列时，入队列，比较优先级，这样高优先的消息会先处理，但是如果持续有高优先级的消息到来，这样会导致低优先的消息得不到处理机会，一直积压。

加权优先级队列

按照不同的优先级设置不同的队列，服务请求消息按优先级入不同的队列，工作现场按照加权值从不同队列取消息处理。需要设置合理的队列数量，防止膨胀。

服务的迁入迁出

服务治理平台，支持服务动态的迁入迁出，这样就可以实现资源紧张时将低优先级的服务迁出，优先保证核心业务和高优先级的服务。

服务治理

rpc框架迈向分布式服务框架的重要的一步。服务治理包含的东西太多了，常用的：

1. 服务调用统计；

2. top统计；

3. 容量规划；

4. 日志分析；

5. 依赖关系分析；

服务治理技术的历史变迁

SOA 治理

服务建模：验证需求，发现和评估当前服务，服务建模和性能需求，开发治理规划；

服务组装：创建服务更新计划，创建和修改服务满足业务需求；

服务部署：确保服务的质量，功能测试、性能测试；

服务管理，生命周期管理和监控。

缺点：

缺乏动态服务治理；

分布式服务框架服务治理



AWS云端微服务治理

服务化后的挑战

跨团队协作

服务上下线管控

服务安全

SLA保障

故障定位

服务治理

目标：

1. 防止服务框架腐化：依赖关系分析，梳理不合理的依赖和调用路径，优化服务化架构，防止代码腐化；

2. 故障定位；

3. 服务管控；

架构设计



运行态服务治理功能设计，作者以Dubbo为案例，介绍了服务治理的一些东西：

服务列表信息；

服务消费、提供者信息；

调用日志；

kpi数据；

流控等；

线下服务治理，





安全和权限管理，服务的调用权限，管理普通的各种功能菜单的权限

总结

一定要明白为什么需要服务治理，以及服务治理的功能内容。服务治理除了各种管控外，最重要的是通用调用日志进行调用分析，依赖关系分析，kpi性能等。

下节继续……