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

流量控制

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

静态流控

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

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

  1. 服务实例通常多线程执行，考虑线程安全，可以使用Atomic原子类进行原子操作；
  2. 到达流控阈值后拒绝请求接入，不能拒绝已有请求的服务方返回应答消息。

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

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

  1. 生产环境，节点的配置不同，采用上述总阈值/节点数的平均，导致性能高，处理块的节点，节点的配额很快用完，性能差的总是有剩余，解决方法就是注册中心做配额计算时，考虑服务节点的性能（例如服务调用时延）做加权，性能好的多分配，差的少分配；
  2. 另一种方案就是配额指标返还和重新申请，服务节点根据自身情况预测，对于分配的指标，多的就返还，少的就申请；
  3. 结合负载均衡做静态流控，消费者根据各服务节点的负载情况做加权路由，性能差的节点路由得到的消息更少，由于配额计算也根据负载做了加权调整，最终分配给性能差的接地啊配额指标也较少，这样既保证了系统的负载均衡，又实现了配额的更合理分配。

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

  1. 流控周期T比较大，节点的负载变化比较快，服务节点的负载反馈到注册中心，注册中心计算后再做配额分配，可能误差比较大；
  2. 流控周期T比较小，注册中心需要实时获取节点的性能数据计算负载情况，采集、上报、汇总、计算，会存在一定的时延，导致流控滞后产生误差；
  3. 采用配额返还和重新申请，增加了交互次数，也有有误差；
  4. 扩展性差，主要是所有压力全在注册中心；
     要解决上述问题，可以采用动态配额申请，原理：
  5. 部署时，根据服务节点数和静态流控阈值，拿出一定比例的配额做初始分配，剩余的放在资源池；
  6. 节点使用完初始分配的配额，再次申请配额；
  7. 总的配额使用完则流控。
     优点：
  8. 服务节点负载和性能数据，在节点本身计算，实时性高；
  9. 节点根据自身情况计算申请配额，保证性能好的申请更多的配额，差的申请的就少，可以更合理的调配资源，流控的精确性有保障。

动态流控

• 动态流控因子，主要是引发动态流控的因素，包括系统资源和应用资源；
• 分级流控，不同级别的流控屏蔽多少请求，可以想象闸门关闭情况。

并发控制

并发执行数量控制：
- 服务端全局控制；
- 消费端的流控；

连接控制

服务端消费者之间的链路数量控制：
- 服务端连接数流控；
- 服务消费者连接数流控；

并发和连接控制算法

• 服务端算法：

  1. 获取流控阈值；
  2. 从全局rpc上下文获取并发执行数，对比阈值，小于，则对当前计数器原子自增；
  3. 等于或者大于，抛rpc流控异常；
  4. 服务调用完，并发执行数自减。

• 消费端算法：

  1. 获取流控阈值；
  2. 从全局rpc上下文获取并发执行数，对比阈值，小于，则对当前计数器原子自增；
  3. 等于或者大于，进入wait状态，wait超时时间为服务调用的超时时间；
  4. 其他线程完成服务调用，计数器减小，如并发执行数小于阈值，wait线程被notify，退出wait，继续执行。

熔断

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

熔断可以理解为保险丝。由于提供方故障，导致服务不可用，如果这时候我们还不停的请求，就会导致阻塞，消耗系统资源，如果这种情况发生在调用链中，情况就会更严重。
1. 闭合状态，正常调用，记录调用结果，连续多少次失败，则转换状态为熔断打开；
2. 熔断打开状态，这种状态下，不容许服务调用，返回错误，一般来说，持续多少时间进入半打开状态；
3. 熔断半开状态，这种状态，可以按比例放行部分请求，持续多少时间无调用异常或多少次调用无异常，熔断开关关闭，放行所有请求。

服务降级

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

屏蔽降级

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

• 屏蔽降级的流程
  

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

容错降级

非核心业务不可用时，对故障做业务逻辑放通。不仅仅用于业务放通，也常用于提供方在客户端执行容错逻辑，容错逻辑主要有：
1. Rpc异常：超时异常、解码异常、流控异常、阻塞异常等；
2. Service异常：校验失败异常、数据库操作异常等；

• 容错降级的工作原理
  
  容错降级与屏蔽降级区别：

  1. 触发条件不同，容错是根据调用结果触发，屏蔽通常是人工干预触发；
  2. 作用不同，容错是服务不可用时做放行，屏蔽是将原本要发起远程调用的服务做本地执行或异常等，将原属于降级业务的资源调配出来供核心业务使用；
  3. 调用机制不同，容错是会发起远程调用的，屏蔽不会发起远程，只做本地；
     

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

业务层降级

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

服务优先级调度

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

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

线程调度器方案

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

优先级队列

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

加权优先级队列

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

服务的迁入迁出

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

服务治理

rpc框架迈向分布式服务框架的重要的一步。服务治理包含的东西太多了，常用的：
1. 服务调用统计；
2. top统计；
3. 容量规划；
4. 日志分析；
5. 依赖关系分析；

服务治理技术的历史变迁

• SOA 治理

  1. 服务建模：验证需求，发现和评估当前服务，服务建模和性能需求，开发治理规划；
  2. 服务组装：创建服务更新计划，创建和修改服务满足业务需求；
  3. 服务部署：确保服务的质量，功能测试、性能测试；
  4. 服务管理，生命周期管理和监控。
     缺点：
  5. 缺乏动态服务治理；

• 分布式服务框架服务治理
  

• AWS云端微服务治理
  

服务化后的挑战

• 跨团队协作
• 服务上下线管控
• 服务安全
• SLA保障
• 故障定位

服务治理

目标：
1. 防止服务框架腐化：依赖关系分析，梳理不合理的依赖和调用路径，优化服务化架构，防止代码腐化；
2. 故障定位；
3. 服务管控；

• 架构设计
  

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

  1. 服务列表信息；
  2. 服务消费、提供者信息；
  3. 调用日志；
  4. kpi数据；
  5. 流控等；

• 线下服务治理，
  

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

总结

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

下节继续……