限流&熔断的考量

标签：inf   能力   限制   ima   dos攻击   协议   slb   假设   kong   

限流的原则，是尽量在流量源头限，并且是需要依据现有团队所掌握的技能来。

 如上最左侧便是主要流量的来源入口，首先就要限制的地方就是slb节点的income流量

 slb节点的流量特点是啥？加限流怎么加？限流限的是啥？

错了，此处是拦截，不是限流...

流量特点：

• 几乎来自外部的流量都从这个入口过来，无论是带业务属性的还是不带业务属性的、ddos的、正常流量、爬虫等统统从这里来

需要拦截是啥（由于流量过了这个节点就是我们的应用系统了，因此最好是把非业务应用相关的流量挡住，限制住，让它有序进来，不要冲垮系统）：

• ddos攻击流量
• 其他通用级的不安全流量：sql注入、xss注入等

有些许限流的：

• 连接并发限制
• 每ip请求限流控制
• 爬虫流量

上述是slb节点，但是也有团队考虑到本身技能，以及代码git化存储的原则，会把某些配置往后面的nginx/kong移，因为slb的配置是UI界面化的，代码化存储比较不直接；

但是nginx/kong这种就相对容易多了，而且恢复时只要脚本到位，分分钟就恢复一套系统，很方便。

nginx节点的流量特点是啥？加限流怎么加？限流限的是啥？

到了这里，ddos这种攻击流量应该算是过滤掉了，常见的sql注入等攻击也过滤掉了；但是还存在爬虫流量（有时，这种流量是我们需要的，SEO推广等）；也会包含高级攻击流量

因此，nginx节点，需要做的限流是（通用级别的限流）：

• 爬虫限流、并发控制、或者过滤、又或者重定向到蜜罐系统（专门给爬虫做的系统，和主业务系统隔离）
• 每ip请求限流

spring cloud gateway节点的流量特点是啥？加限流怎么加？限流限的是啥？

到了这里，一般普通静态H5资源的访问已经没有了（已经重定向到其他nginx节点分流处理调了）；gateway处理的都是动态编程语言需要处理的流量，这里指java

也就是说，到了这个节点，开始进入java系统领域，流量承受能力比nginx降了1个等级，需要做更多的限制。

需要做的：

• 普通场景下的限流
• 突发流量下的限流，如：秒杀等
• CC攻击+验签的过滤（由于公私钥证书一般加在java节点上，因此此处放java系统范畴，而不是slb之前，或者nginx之前）
• 可以在gateway 动态路由中分别配置各自的限流配置，以及上述自定义的CC+验签配置

 隔离性：

• 由于gateway流量会转发给后端一大堆微服务，假设由于哪个java微服务处理不过来hang住了，又不想影响其他后端为服务的转发，因此需要做隔离性
• 可以：
  • hystrix
  • sentinel
  • guava

 此处的限流和nginx的限流有啥区别？

• nginx的阈值要大，因为nginx覆盖的范围不光是java领域，还有H5等其他范围
• nginx的限流配置维度是通用的，但是spring cloud gateway就变化多了，可以通过自定义KeyResolver来决定所需要的维度来限流，如：用户id维度、ip维度、租户维度等，灵活度大了

java微服务节点的流量特点是啥？加限流怎么加？限流限的是啥？

 到了这里，就是具体的微服务应用了，单个微服务所能承受的流量，做得好的话是能用jmeter测量出来的，可以通过这个值来参考设置

再然后，到了具体服务中了，其实限流的维度就更多了，当然需要考量下是否需要加很多限流，脆弱敏感的服务就加些，比如计费等，或者用其他技术做限流，如：queue，然后固定住consumer数来消费，稳住速率。

所采用技术和gateway一样，也可以自己实现，实现难度都还好。

流量大的系统，最好是用特定技术把income请求根据不同的维度划分好独立的线程池，不要相互影响；由本服务发起的到其他服务的请求调用，也需要单独的线程池来处理。总之目标就是都独立，不互相影响，即便其他服务慢了 ，

自己也不慢。

因此，熔断又出现了：

• 当其他服务很慢，超时了，我方作为服务调用方不能被拖垮啊，这时，就断开吧，用个指定的协议响应暂且认定为服务不可用之类的，等后续再补偿回查。
• 当然关键服务是不能这么处理的，只能是辅助服务。关键服务就必须要jmeter压侧提升性能。
• 依赖：
  • 核心服务的梳理
  • 辅助服务熔断的返回值+应对方式
  • 核心服务的压侧

限流&熔断的考量

标签：inf   能力   限制   ima   dos攻击   协议   slb   假设   kong   

原文地址：https://www.cnblogs.com/aarond/p/ratelimiter.html