限流的原则，是尽量在流量源头限，并且是需要依据现有团队所掌握的技能来。
如上最左侧便是主要流量的来源入口，首先就要限制的地方就是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压侧提升性能。
- 依赖：
- 核心服务的梳理
- 辅助服务熔断的返回值+应对方式
- 核心服务的压侧