微服务框架saf-7：saf-http的sentinel流控demo体验和一些深入思考
微服务框架saf-7：saf-http的sentinel流控demo体验和一些深入思考
目录
(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
done5.度量体验与验证
可以看到均符合流控预期。
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