目录
(1).关于saf
(2).前置准备
(3).saf-http-demo简述
(4).saf-http的sentinel流控demo体验
1.demo访问逻辑与sentinel流控规则设计
2.内部集中式网关与sidercar,http与rpc之论
3.明确saf-http-demo的初始流控规则
4.开启访问流量
5.度量体验与验证
5.1.demo-http-receive的度量体验与验证
5.2.demp-http-send的度量体验与验证
6.其他实验
(6).生产需要注意与完善的部分
1.流控规则实时热更新
2.sentinel-dashboard生产慎用
3.报警需要支持
4.saf目前只支持sentinel的流控
(7).相关资料
架构实战交流钉钉群号:23394754
目前寻找合适职位:百人规模创业公司的基础架构负责人,总架,CTO。
注意:
本文主要是陈述sentinel如何使用,以及度量展现(grafana/prometheus),原理与机制并不会过多涉及(以后有时间再开)。
(1).关于saf
项目地址:
https://github.com/saf-group
1.一个微服务框架,完全基于注解的方式开发。
2.适用于云原生(K8S)下的微服务体系搭建,为技术中台提供底层支撑。
3.解放业务,使业务方专注于业务逻辑本身:通过注解以搭积木方式引入各式资源,每个资源都是一行注解,极大提升业务方产出效率。
(2).前置准备
需要完成一个saf-http-demo的容器化部署,要准备很多准备,详情参见:
微服务框架saf-5:saf-http与demo的解析与体验,以及容器化部署
参考下述文章,完成prometheus-saf的部署,这样可以抓取demo的metrics:
grafana&prometheus生产级容器化监控-1:生产级容器化
sentinel-dashboard容器化:
docker镜像制作参见:
docker-2:docker-compose化sentinel-dashboard用于本地开发
K8S容器化yaml文件:
https://github.com/hepyu/k8s-app-config/tree/master/yaml/min-cluster-allinone/sentinel-dashboard
(3).saf-http-demo简述
如下图所示:
显然分两部分,对于web服务来说一方面会接受http,另一方面会发出http。
http-in:通过HttpMetricFilter拦截http请求,进行度量处理。
http-out:封装httpclient,加入度量处理。
使用方法:
这里的注解@EnableSentinel是自定义的,原因在于需要实现在框架中从apollo获取数据,让框架使用者无感知,只加这一行注解就完成了sentinel组件的加载:
再详细原理与机制,本文不涉及。
(4).saf-http的sentinel流控demo体验
1.demo访问逻辑与sentinel流控规则设计
先访问sentinel-dashboard:
http://sentinel-dashboard.future.com:30834/#/dashboard/home
其中的两个demo-http-xxx即是本次的demo。
这两个demo的调用关系如下图:
sentinel的resource体系设计:
对于每个web,http请求分入和出,分别有一个总闸,总闸通过以后,才是具体url的流控规则。
2.内部集中式网关与sidercar,http与rpc之论
实际上,不论是对于http还是rpc的服务,服务开发者都有责任与义务定义并落地服务的接纳能力,包括出和入两个方向。
以http举例:
服务需要定义出处理接收http的最大能力,以及访问外部http的最大能力,并切当超出是可以限流,这就要求必须有全面系统的度量。
这样,才能将全局系统的稳定性降解为各个服务的稳定性,将稳定性从指数复杂度降低为x=1的常量没复杂度。
由此,这里涉及到一个实际生产中网关实现的两种选择:集中式网关与sidercar。本例是sidercar模式(个人推崇模式)。
其优势在于将服务的稳定性交给每个开发负责的服务,而由于存在流控和度量,其单个服务的不稳定又不会扩散到整个系统,只会局限在当前问题服务(这里要注意,实际上如果使用不当比如超时时间设置过长,访问服务还有性能问题,这个属于另外一个问题:服务本身质量不达标)。
关于http与rpc,对于目前态势,对于很多公司尤其是创业公司,在相当时间内http是足够用的,而且http使用简单,代价极低,不能说是为了rpc而rpc,没有意义。
而且http对于异构系统,或者python/php的java/go改造意义重大,改造成本非常低,作为一个过度亦是一个很好的选择,同时可以构造标准化能力,这样以后转rpc也会成本非常低。
sidercar模式还有一个很大好处是,以内部集中式网关举例,不需要留一波人专门维护,也不需要担心集中式网关挂了就全完了。
好处还有很多:
a.也非常有利于普通工程师的快速提升,以及融入。
b.非常有利于开发/框架/中台的标准化,做不到这个标准化,是没有生产力的,这个生产力的提升是巨大的。
c.等等。
3.明确saf-http-demo的初始流控规则
为了简明扼要,只使用Http::In这个资源。
3.1.demo-http-receive的初始流控规则
使用QPS模式,阈值为0,即不处理http入请求,直接触发流控返回。
3.2.demo-http-send的流控规则:
使用QPS模式,阈值为1,也就是意味着,每秒会向demo-http-receive和www.baidu.com各发一次http请求。
4.开启访问流量
开一个任意支持curl的pod,启动访问脚本,给demo服务一定压力好观测数据。
#!/bin/bash
for((i=1;i<=100000000;i++));
do
curl http://saf-sample-http-apache-httpcomponents-web-send-prod/shop/getShop?shopId=1
done
5.度量体验与验证
可以看到均符合流控预期。
5.1.demo-http-receive的度量体验与验证
5.1.1.sentinel-dashboard
5.1.2.grafana/prometheus
5.2.demp-http-send的度量体验与验证
5.2.1.sentinel-dashboard
5.2.2.grafana/prometheus
6.其他实验
可以尝试修改apollo中的流控规则,来观察/验证/学习sentinel。
(6).生产需要注意与完善的部分
1.流控规则实时热更新
saf目前集成了apollo与sentinel-datasource-ext-apollo,所有天然支持。
2.sentinel-dashboard生产慎用
权限控制简单,生产还是使用apollo类似的分布式配置中心。
3.报警需要支持
使用prometheus即可。
4.saf目前只支持sentinel的流控
其余功能如降级等暂未做支持。
(7).相关资料
微服务框架saf:
https://github.com/saf-group/saf
容器化生产实践:
https://github.com/hepyu/k8s-app-config.git
sentinel-dashboard的k8s容器化yaml文件:
https://github.com/hepyu/k8s-app-config/tree/master/yaml/min-cluster-allinone/sentinel-dashboard