服务治理设计

阿拉斯加大闸蟹
172 阅读10分钟

概念

备注: 本文的服务治理专注于服务与服务之间的请求治理, 以及一条请求链路上的服务治理。更高维度的系统稳定性请参考稳定性容灾方案

服务治理专注于服务运行时的稳定性，服务根据协议类型可以分为HTTP服务、RPC服务、SaaS服务(mysql, redis, tmq等)， 下面描述的所有策略对所有协议保持一致

服务治理的一般策略是: 上游保护下游，下游不信任上游，上下游协同保护。分别通过出流量治理和入流量治理，结合服务治理基础设施，来实现具体策略。

基本的分层结构如下图所示

服务治理平台层

通用服务治理开放平台

核心目标: 以统一接入的方式开放功能层提供的服务治理能力，并可扩展至多种场景

基本功能

  1. 原生支持RPC, HTTP, MYSQL等服务的治理操作界面
  2. 提供服务治理策略配置的展示、修改和历史记录查询
  3. 提供基本的服务监控能力，包括metrics, 日志，告警

高级功能

  1. 服务故障快速定位
  2. 配置推荐
  3. 服务稳定性预案, 描述在各个场景下服务稳定性的处理方法及关键指标
  4. 为TLB, Redis等服务提供服务治理操作界面，并保持近似统一的操作模式

服务分级系统

根据产品线、服务、请求类型对请求进行优先级设置，用于优化在过载、限流、熔断等场景下的请求处理

染色系统

  1. 根据请求的各个维度的信息，对请求进行标记, 该标记将通过请求标记机制在调用链上传递
  2. 对标记设置不同的服务治理策略

服务治理基础设施

配置中心

请求标记传递机制

与框架配合，将请求的标记在调用链上传递

强弱依赖系统

辛苦@秦磊 帮补充下设计文档

维护服务之前的强弱依赖关系

服务状态实时统计系统

  1. 实时统计单实例、集群、IDC、服务等各种维度的服务实时状态，包括平均耗时, pct99耗时，错误率，qps/连接数等
  2. 提供统一的查询接口

Mesh

  1. mesh proxy提供策略执行
  2. mesh cp负责策略的存储以及定制

服务出流量治理

超时配置

基本功能

  1. 调用下游时通过服务治理平台动态指定连接超时和请求超时时间，请求超时时间包含连接超时时间
  2. 以统一的配置支持HTTP、RPC、mysql、redis等不同协议
  3. 支持按主调服务+主调集群+被调服务+被调集群+被调方法名维度进行配置

高级功能

  1. 超时配置自动推荐

根据业务的请求连接和耗时统计, 结合经验公式给出超时的默认配置和推荐配置

  1. 请求调用链截止时间

在请求入口层(TLB, http mesh), 为每个请求增加整体超时时间，然后在请求链路上传递，每个访问下游的请求根据这个时间来设置最大超时时间

动态负载均衡

动态负载均衡系统方案设计 (与IES业务架构合作共建)

基本功能

  1. 基于下游静态权重和业务代码选择的负载均衡策略，选择下游进行调用

高级功能

  1. 基于服务实时状态统计系统，获取单接口、单实例、集群、整体服务的实时状态(平均耗时，pct99, 错误率), 动态调整下游的请求量，实现动态负载均衡

动态路由

提供通过平台配置来动态调整访问下游的集群或者具体地址

基本功能

  1. 基于上游psm+cluster+idc, 动态调整访问下游的psm+cluster+idc。接口的兼容性需要业务方自行保证
  2. 在功能(1)的基础上，提供按比例分配流量的能力

高级功能

  1. 基于染色，对具体的请求，路由到指定的psm或ip:port列表, ip是从线上机器可访问到的地址(线上或其他环节)

限流

限流提供了一种主动控制的方式去保护下游，这个策略侧重于主动配置、主动调整, 提供了一种面对下游故障时的应对策略

基本功能

  1. 根据服务治理平台的配置，将一定百分比的下游请求进行丢弃
  2. 根据服务治理平台的配置，将超过qps限制的请求进行丢弃(等价与现在MS平台的降级功能)

高级功能

  1. 请求丢弃时，应当按照请求的优先级，从低到高依次处理，尽量减少丢弃请求对整体服务质量的影响
  2. 可与降级功能结合，一起对下游提供保护能力

熔断

熔断提供了在下游服务/机器故障时快速剔除故障节点的能力，侧重于被动反馈

基本功能

  1. 根据服务治理平台的配置，在某一下游节点的错误数/错误率超过熔断阈值时，对该节点进行暂时屏蔽
  2. 结合恢复探测算法，逐步恢复或继续禁止对该下游节点的调用

高级功能

  1. 结合降级、限流策略。熔断策略应属于兜底策略
  2. 下游错误率统计区分框架侧和业务侧，对于框架侧，主要关心网络状态统计，对于业务侧，可以引入更多业务属性来判断下游服务健康状况
  3. 对于业务侧，通过SDK的方式来获得熔断能力(类似Hystrix)

降级

降级提供了一种在异常情况下的有损服务的能力

基本功能

  1. 根据在服务治理平台的配置，对访问下游的请求注入降级信息
  2. 下游服务响应降级信息，进行业务侧降级

高级功能

  1. 结合强弱依赖系统，首先降级弱依赖服务
  2. 结合请求分级系统，首先降级低优先级服务

请求录制和重放

基本功能

  1. 录制指定服务、指定接口或指定tag的流量
  2. 支持以请求为单位,
  3. 可录制请求和响应
  4. 将录制的流量保存在本地或转发至远端服务

高级功能

  1. 请求重放

响应(错误)注入

基本功能

  1. 针对特定服务、特定接口或特定请求，返回指定的响应内容或错误码

服务入流量治理

服务端限流

服务端限流主要通过预先配置的方式来保护自己

基本功能

  1. 根据服务治理平台配置，限制单个服务或接口的qps/最大连接数

高级功能

  1. 限制整体服务的qps，类似服务qps quota的概念。但该功能受制于对整体服务节点数的精确统计跟踪能力，存在较大风险
  2. 通过mesh, 对python等服务限制单服务最大连接数
  3. 支持主调服务+主调集群+被调服务+被调集群+被调方法维度的限流

动态过载保护

服务分级&过载保护 (与IES业务架构合作共建)

通过实时计算评估当前服务的处理能力，动态判断服务请求是否可以正常访问

基本功能

  1. 根据请求的排队时间等指标，实时评估当前的服务处理能力
  2. 对超出服务能力的请求进行降级或丢弃
  3. 反馈过载结果至上游，由上游进行动态调整

高级功能

  1. 结合请求分级对过载的请求按优先级进行丢弃
  2. 结合强弱依赖对过载的请求按强弱依赖顺序进行丢弃

请求安全校验

服务访问控制(ACL)用户文档

通过安全校验来保障服务的安全性

基本功能

  1. 身份校验: 通过psm(弱)或gdpr token(强)来确认请求者的真实身份
  2. 访问控制: 根据服务治理平台的配置，以白名单或黑名单的方式判断访问者是否有权限进行访问
  3. (HTTP服务)请求校验: 防止重放攻击。具体方案可参看: 请求验证重构

上游调度统一管理

从服务提供方的角度出发，统一管理来自上游的流量

基本功能

  1. 根据上游的psm+cluster, 调整访问当前服务的集群，达到统一管理的目标

服务组治理

服务set化(泳道)

主要目标

  1. 提供服务内多实例之间的强隔离，每个set内的代码、配置、数据及更新均可保持独立
  2. 提供服务间的强制调用关系，控制故障的影响范围
  3. 强隔离: 不提供任何形式的fallback到泳道外的机制，避免TCE cluster悲剧重演

什么是set?

  1. 一种服务划分机制，保证各个子块的完全独立，严格控制故障的范围
  2. 固定的服务能力
  3. 固定的成本

常见问题

  1. 上游没分set, 下游分set，如何调用?

上游可随机调用或就近调用下游各个set

  1. 上游分set, 下游没分set, 如何调用?

直接调用下游

  1. 上下游set如何确定调用关系?

set名称完全一致

  1. 上下游均set化，但上游set无法找到对应的下游set, 如何处理?

直接失败，set属于部署阶段的概念，此类问题在上线阶段即可发现，没必要引入额外的复杂度

  1. 对于redis/mysql等无法分set的场景如何处理? (需要数据共享)

尽量避免数据共享，如确实需要，那么去除set

  1. 与现在TCE cluster的关系?

    1. 当前TCE cluster上下游之间的调用非强制关系，即上游clusterA可通过代码指定调用下游clusterB, 失去了故障隔离的意义。TCE cluster可以认为是一个弱化的set机制

    2. 尝试基于cluster去实现set

      1. cluster支持代码的单独发布，符合set的需求
      2. 符合大部分场景下对set的认知，但不包括代码内的强行指定
      3. TCE提供将cluster转化为set的能力(概念上，即支持强隔离)
      4. 推动业务符合该规范，移除不规范调用

  2. 实现set化有和收益?

    1. 服务变更带来的影响完全可预知、可控
    2. 服务调用关系更加清晰，不必考虑代码hardcode等外部因素
    3. 准确评估一个set的服务能力和成本，从而指导服务扩容/缩容
    4. 故障隔离
avatar
文章
阅读
粉丝