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-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 完全覆盖,因此不再深入