- 前言 -
限流的原则，是尽量在流量源头限，并且是需要依据现有团队所掌握的技能来。
如上最左侧便是主要流量的来源入口，首先就要限制的地方就是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压测提升性能。
依赖：
核心服务的梳理
辅助服务熔断的返回值+应对方式
核心服务的压侧
来源：
https://www.cnblogs.com/aarond/p/ratelimiter.html
扫一扫
7648
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
