线上 | OpenSergo - [规范]

发布于:2024-06-04 ⋅ 阅读:(47) ⋅ 点赞:(0)

§1 参考资料

sentinel-1-8-6-release | Sentinel
OpenSergo 官网
OpenSergo Wiki

OpenSergo 是一套微服务生态下可以泛用的 微服务治理规范,它大约包括如下几个方面

  • 流量治理
    • 流量路由
    • 流量染色
    • 流量防护
  • 服务容错
    • 熔断降级
    • 重试防抖
    • 恢复
  • 服务监控
    • 日志
  • 中间件治理
    • 数据库治理
    • 缓存治理
  • 安全治理

§2 OpenSergo 与 Sentinel 关系

OpenSergo 是一个未完工的成体系的规范,Sentinel 天然完成了此规范的部分实现,并且 Sentinel 2.0 符合 OpenSergo 规范

§3 规范体系

§3.1 服务元数据

OpenSergo 是一套服务治理规范,需要持有服务信息才能对应的进行治理,这些信息由服务方上报,即服务元数据服务元数据通过 io.opensergo.proto.service_contract.v1.MetadataServiceGrpc.MetadataServiceImplBase#reportMetadata 完成上报

ReportMetadataRequest 信息在这里插入图片描述##### ReportMetadataReply 信息在这里插入图片描述
§3.2 服务发现

无资料

§3.3 流量治理与服务容错
流量治理的整体思路

流量治理本质上就是对流量的干预,因此整体思路是:能干预、怎么干预、以什么依据干预

OpenSergo 中的流量治理大体上是如下思路

  • 首先,需要贤能控制流量的走向,即 流量路由
  • 然后,需要能对不符合预期的流量采取特定的干预手段,即 流量防护
  • 再次,需要对流量的具体流转过程制定标准,即 容错标准
流量路由

核心思路:把什么样的流量分流到哪
大约可以看做是将一条请求链路的每个步骤,分别交由那个节点处理计算方法。

流量特征: 流量路由的核心方法就是对所有流量进行归纳拆分,归纳拆分的依据就是流量特征 比较容易理解的流量特征比如
灰度流量、某特定来源的流量(比如特定业务、特定用户群、特定机房)

流量路由由两部分组成:

  • 虚拟工作量(VirtualWorkload):官方定义——将某一组工作负载按照一定的特征进行分类
    • 可以这么理解:划定一组流量会流经的资源,标记他们可以用于处理具有某种特征的流量
    • 基于 Istio DestinationRule 进行扩展
  • 流量标签规则 (TrafficRouter):官方定义——将特定特征的流量映射至特定特征所对应的 VirtualWorkloads 上
    • 流量是具有流量特征的,用于处理流量特征的资源也按流量特征进行分组了,将它们映射起来就是流量标签规则
    • 基于 Istio VirtualService 进行扩展

示例规则

apiVersion: traffic.opensergo.io/v1alpha1
kind: TrafficRouter
metadata:
  name: service-provider
  namespace: default
  labels:
    app: service-provider
spec:
  hosts:
    - service-provider
  http:
    - match:
        - headers:
            tag:
              exact: v2
      route:
        - destination:
            # 服务注册表中的服务名,服务名通过服务注册平台的服务注册表和 ServiceEntry 声明的主机中检查
            host: service-provider
            # 服务内部子集的名字,只适用于网格内部的服务,子集必须在合适的 DestinationRule 中定义
            subset: v2
            # 指定的作为地址的主机的端口号,如果主机只暴露一个接口,没必要显示指定
            #port: 
            #当路由结果是空集时,则选中此 fallback(否则就没法处理流量)
            fallback:
              host: service-provider
              subset: v1
    - route:
        - destination:
            host: service-provider
            subset: v1
流量防护

核心思路:对于什么样的流量,当满足什么条件时,进行什么样的干预

上述思路的实现即流量防护规则,由 3 部分组成:

  • target:被干预的流量
  • strategy:决定是否对 target 执行干预的判断策略
  • fallbackAction:实际进行干预时的行为

Target 用 key 表示,目前可以等同视为 sentinel 的 resource。
在后面的版本中,会发展为 target = protocol + resource
示例:/foo

Strategy 流量防护策略略多,见后面
示例:定义了一个流控规则,集群 QPS < 10

apiVersion: fault-tolerance.opensergo.io/v1alpha1
# 流控规则
kind: RateLimitStrategy
metadata:
  name: rate-limit-foo
spec:
  # 度量类型,请求数
  metricType: RequestAmount
  # 控制模式,单机 Local, 集群总体 Global
  limitMode: Global
  threshold: 10
  # 统计窗口,单位秒,结合 RequestAmount ,即 QPS
  statDurationSeconds: 1

FallbackAction 可以类比 sentinel 的 fallbackMethod,可以指定触发规则的行为,比如返回一个定制的结果
示例:定义了一个降级行为,返回一个服务提供方的响应。响应码 429,响应体内容 Blocked by Sentinel,带着响应头 X-Sentinel-Limit=foo
示例:

apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: HttpRequestFallbackAction
metadata:
  name: fallback-foo
spec:
  behavior: ReturnProvidedResponse
  behaviorDesc:
    # 触发策略控制后,HTTP 请求返回 429 状态码,同时携带指定的内容和 header
    responseStatusCode: 429
    responseContentBody: "Blocked by Sentinel"
    responseAdditionalHeaders:
      - key: X-Sentinel-Limit
        value: "foo"

RULE
示例:

apiVersion: fault-tolerance.opensergo.io/v1alpha1
kind: FaultToleranceRule
metadata:
  name: my-rule
  namespace: prod
  labels:
    app: my-app 
spec:
  selector:
    app: my-app # 规则配置生效的应用名
    # 下面依次指定上述定义内容,串联为一条规则
    targets:
      - targetResourceName: '/foo' 
    strategies: 
      - name: rate-limit-foo
    fallbackAction: fallback-foo 
流量防护规则

流量控制(RateLimitStrategy)

  • 说明:控制单位时间内请求量
  • 应用场景:防突发激增流量
  • 配置
spec:
  # 指标类型,其实只有 RequestAmount,其余的一个不知道 unknow,一个忽略 unrecognized
  metricType: RequestAmount
  # 控制模式,只有两个模式,Local/Global -> 单机/集群
  limitMode: Global
  threshold: 10
  # 统计窗口,单位秒
  statDurationSeconds: 1

流量平滑(ThrottlingStrategy)

  • 说明:使并发请求排队并匀速执行,控制并发请求之间的并发间隔
  • 应用场景:
    • 异步后台任务
    • 延时不敏感
  • 区别:
    • 流量控制,强调限制请求的频率
    • 流量平滑,强调并发请求的间隔时间
  • 配置
spec:
  # 执行间隔
  minIntervalOfRequests: '20ms'
  # 排队超时时间
  queueTimeout: '500ms'

并发控制 (ConcurrencyLimitStrategy)

  • 说明:限制并发数,相当于 sentinel 的舱闭(隔离)
  • 应用场景:防止慢请求占满线程池
  • 配置
spec:
  # 并发数
  maxConcurrency: 8
  # 控制模式,只有两个模式,Local/Global -> 单机/集群
  limitMode: 'Local'

熔断保护 (CircuitBreakerStrategy)

  • 说明:慢调用、异常流量比例过大时熔断(暂停)流量
  • 应用场景:防止关键请求集中失败
  • 配置
spec:
  # SlowRequestRatio 慢调用,ErrorRequestRatio 异常
  strategy: SlowRequestRatio
  # 触发比例
  triggerRatio: '60%'
  # 统计窗口
  statDuration: '30s'
  # 熔断恢复时间,熔断后,经过此时间进入半开状态,通过一个请求进行试触,成功则恢复正常,否则继续熔断
  recoveryTimeout: '5s'
  # 最小请求数,统计窗口中请求数不足此数时,忽略规则
  minRequestAmount: 5
  # 慢调用必填,超出多上时间的调用认为是慢调用
  slowConditions:
    maxAllowedRt: '500ms'
  #异常必填,针对什么异常统计(没找到实际案例)
  errorConditions:
    errorType: 'NullPointorExceptrion'

自适应过载保护 (AdaptiveOverloadProtectionStrategy)

  • 说明:按系统指标与自适应策略提供 pod 维度保护
  • 应用场景:防止流量导致的系统指标超标
  • 配置
spec:
  # 系统指标
  metricType: 'CpuPercentage'
  triggerThreshold: '70%'
  # 目前支持 BBR 拥塞算法
  adaptiveStrategy: 'BBR'
§3.4 数据库治理标准

§4 项目引用办法

目前,openSergo 主要是给 k8s 环境准备的,由如下部分组成

  • opensergo-control-plane:对 k8s 环境的对接,展示 OpenSergo CRD(其实就是 k8s CRD)
  • 项目接入:项目对接 OpenSergo,OpenSergo 的底层还是依赖于 sentinel(或者说是其现有唯一实现)
    • 目前允许通过 sentinel、springcloud alibaba、dubbo 接入,但完成度极低
<dependency>
    <groupId>com.alibaba.csp</groupId>
    <artifactId>sentinel-datasource-opensergo</artifactId>
    <!-- 对应 Sentinel 1.8.6 版本 -->
    <version>0.1.0-beta</version>
</dependency>
  • opensergo-dashboard:类似 sentinel-dashboard

具体步骤参考官网快速开始部分
因为目前规范的细则还有大量空白(更别提实现了),现有功能被 sentinel 完全覆盖,因此不再深入