当前位置: 首页> 文旅> 文化 > 线上 | OpenSergo - [规范]

线上 | OpenSergo - [规范]

时间:2025/8/27 2:10:12来源:https://blog.csdn.net/ZEUS00456/article/details/139325242 浏览次数:1次

INDEX

      • §1 参考资料
      • §2 OpenSergo 与 Sentinel 关系
      • §3 规范体系
        • §3.1 服务元数据
          • `ReportMetadataRequest` 信息![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/ffba569841ae4668b4cff74e4d41d21f.png)##### `ReportMetadataReply` 信息![在这里插入图片描述](https://img-blog.csdnimg.cn/direct/0ecfa2bab42f42e8abfd14b9282f5cb4.png)
        • §3.2 服务发现
        • §3.3 流量治理与服务容错
          • 流量治理的整体思路
          • 流量路由
          • 流量防护
          • 流量防护规则
        • §3.4 数据库治理标准
      • §4 项目引用办法

§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-providernamespace: defaultlabels:app: service-provider
spec:hosts:- service-providerhttp:- match:- headers:tag:exact: v2route:- destination:# 服务注册表中的服务名,服务名通过服务注册平台的服务注册表和 ServiceEntry 声明的主机中检查host: service-provider# 服务内部子集的名字,只适用于网格内部的服务,子集必须在合适的 DestinationRule 中定义subset: v2# 指定的作为地址的主机的端口号,如果主机只暴露一个接口,没必要显示指定#port: #当路由结果是空集时,则选中此 fallback(否则就没法处理流量)fallback:host: service-providersubset: v1- route:- destination:host: service-providersubset: 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, 集群总体 GloballimitMode: Globalthreshold: 10# 统计窗口,单位秒,结合 RequestAmount ,即 QPSstatDurationSeconds: 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: ReturnProvidedResponsebehaviorDesc:# 触发策略控制后,HTTP 请求返回 429 状态码,同时携带指定的内容和 headerresponseStatusCode: 429responseContentBody: "Blocked by Sentinel"responseAdditionalHeaders:- key: X-Sentinel-Limitvalue: "foo"

RULE
示例:

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

流量控制(RateLimitStrategy)

  • 说明:控制单位时间内请求量
  • 应用场景:防突发激增流量
  • 配置
spec:# 指标类型,其实只有 RequestAmount,其余的一个不知道 unknow,一个忽略 unrecognizedmetricType: RequestAmount# 控制模式,只有两个模式,Local/Global -> 单机/集群limitMode: Globalthreshold: 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 完全覆盖,因此不再深入

关键字:线上 | OpenSergo - [规范]

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com

责任编辑: