白话说一下服务治理
有了微服务就有了东西、南北流量的治理需求
- 东西流量表示集群内微服务间的调用流量，一般解决方案-sentinel/envoy
- 南北流量表示从外部到微服务内的流量，一般解决方案-apisix/kong/zuul
这里主要思考下东西流量微服务间的调用的管理-sentinel 抓大放小，忽略细节
他就是做限流、降级、熔断等调用管理的功能 https://github.com/alibaba/Sentinel，引一张官图可以看到，它的生态还比较完善，可以支持接入左侧的若干中框架及网格，可以支持对接多种配置组件进行规则配置，还具备完整的控制台和实时监控，有了以上这些基础，再来看最核心的规则部分，通过不同的规则模型，定义了资源访问的限制，若干个规则模块通过责任链组合起来，实现了各类治理功能
接地气儿的一看就懂使用细节博文推荐： https://blog.csdn.net/A_art_xiang/article/details/123313317
那么这些组件是如何流转的呢？ 比如规则如何动态实时生效、实时报表如何动态生成、配了的规则如何在服务端作用、流控规则是如何统计计算的？
sentinel细节不难搞懂，可以参考这位的博文或自行研究代码 https://www.cnblogs.com/luozhiyun/p/11601129.html
之前的最简应用 https://www.cnblogs.com/it-worker365/p/12349681.html
那为什么企业要二次开发？
按照现在行业现状，一半都要先去看一下大佬是什么做的，比如阿里云的AHAS，肯定要先看下，而且人家都做好对比了https://help.aliyun.com/document_detail/167568.html
可以看到，跟开源版本的不同主要体现在三个方面：接入方式扩展、核心功能扩展、监控运维排障功能增强
接入方式扩展：
当下流行的接入方式：注解（侵入业务）；AOP（侵入业务）；字节码增强（无感接入）； 是不是字节码看起来可以压倒一切，似乎是的，不过研发成本相对较高，写一个好的增强框架不是很容易，不过这是个趋势，越来越多的企业从AOP往字节码过渡
既然需要自定义增强，那么要增强的内容是什么？
了解字节码增强的都知道，字节码框架就是针对操作核心类进行拦截，在切面做各种事情，具体到服务治理，首先需要初始化客户端环境，初始化规则获取，动态规则接收，请求tokenserver等，其次是增强具体的框架，比如web框架，在http请求入口处应用管理规则；在feign等http客户端处通过拦截出请求应用管理规则；类似还有很多，比如请求redis、mq、mysql等，自由发挥；资源定义和服务来源定义通过字节码也可以很好的解决规范化问题，提供统一的获取逻辑
核心功能扩展：
sentinel原型本身只维护基础模型，但资源、规则、限制等没有跟业务强绑定，没有规范很难统一，无法达到全局管理的目的；在基础模型之上，定义更多的资源类型、更多的防护规则、更智能的控制手段等也就十分有必要了，比如上面提到的慢SQL识别与熔断，配置对象是啥、需要的输入参数哪些、规则的执行逻辑是啥等等，都需要二次开发
监控运维排障功能增强：
原功能只支持临时监控展示，数据不持久化，看看就罢了，没法追溯，没配合监控告警，无法与企业其他数据配合产生更高价值，于是就可以理解这个方向了，这个比较好理解，对于系统的任何指标，都不能是孤岛，需要跟整体联动才能发挥最大的价值，比如接入现有的监控体系，配置智能告警规则，监听告警事件进行自动降级或熔断等规则的变更等
Mesh
sentinel基于envoy的组件，实现就是通过一层java代理将规则转化envoy的规则，这种方式好处是什么？通过envoy规则实现东西流量管控，看起来没什么缺陷，好像很好的样子，但通过grpc控制面规则管理可能导致集群控制面数据过大，尤其是单控制面多集群的场景，任何变动会导致全量数据广播到集群每个pod，流量问题不容小视
https://github.com/alibaba/Sentinel/tree/master/sentinel-cluster/sentinel-cluster-server-envoy-rls
https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/network_filters/rate_limit_filter#config-network-filters-rate-limit
标签：字节,envoy,宏观,sentinel,治理,https,规则,角度看,com From： https://www.cnblogs.com/it-worker365/p/17043344.html