整体架构， 需要先装slime-boot(helm operator), 然后通过提交SlimeBoot资源的方式安装不同的slime模块， 如Limiter和lazyload等
可以解决的问题
- 动态的自适应限流（基于连接数、cpu、内存等指标）、简化EnvoyFilter配置
- sidecar配置的按需加载，解决全量推送的性能和官方SidecarScope的易用性问题
自适应限流实现
- 通过提交CR，即比较语义化的SmartLimiter，简化istio官方的EnvoyFilter配置
- 拉取promethus的负载(cpu/mem)， 作为限流生效的条件
condition: '>100' 如果服务的所有负载大于100，则执行该限流
sidecar配置按需加载实现
本质上类似惰性删除/更新， 即请求时更新对应的调用相关配置信息， 且引入global-sidecar加入了兜底逻辑
- Global-sidecar-pilot从原有的pilot获取节点的全量配置信息， 推送给global-sidecar，如此global-sidecar 拥有全量的配置信息
- A请求B时， A的sidecar发现没有B的路由信息，请求兜底流程，即到global-sidecar，由global-sidecar将请求转发给B
- Global-sidecar上报A到B的调用关系， 进而由lazycontroller更新A的sidecar，添加B的调用关系
- 后续A到B的请求，可在自己的sidecar完成转发
实践
自适应限流
- Slime-boot安装
- limiter模块安装：
cat <<EOF | k apply -f -
---
apiVersion: config.netease.com/v1alpha1
kind: SlimeBoot
metadata:
name: smartlimiter
namespace: mesh-operator
spec:
image:
pullPolicy: Always
repository: docker.io/slimeio/slime-limiter
tag: v0.2.3-d808438 # 这里版本有个坑，若使用最新版的smartlimiter会报找不到对应版本的资源
module:
- limiter:
backend: 1
enable: true
metric:
prometheus:
address: http://prometheus-k8s.kubesphere-monitoring-system:9090
handlers:
cpu.sum:
query: |
sum(container_cpu_usage_seconds_total{namespace="$namespace",pod=~"$pod_name",image=""})
cpu.max:
query: |
max(container_cpu_usage_seconds_total{namespace="$namespace",pod=~"$pod_name",image=""})
rt99:
query: |
histogram_quantile(0.99, sum(rate(istio_request_duration_milliseconds_bucket{kubernetes_pod_name=~"$pod_name"}[2m]))by(le))
k8s:
handlers:
- pod # inline
name: limiter
EOF
- 限流配置：一分钟内，均分有两个请求数，则限制
cat <<EOF | k apply -f -
---
apiVersion: microservice.slime.io/v1alpha1
kind: SmartLimiter
metadata:
name: appauth-rpc
namespace: sdk
spec:
sets:
_base:
descriptor:
- action:
fill_interval:
seconds: 60
quota: '2/'
strategy: 'average'
condition: 'true'
target:
port: 8090
EOF
- 效果。 请求第三次时， 触发限流
sidecar配置按需加载
略
