3分钟彻底弄懂Sentinel集群限流探索 _Sentinel

最近看了下关于分布式限流的部分，看到Sentinel的分布式限流，也就是集群限流的部分，想搭个环境看看，结果发现网上关于这方面的内容基本可以说没有，你甚至很难跑起来他的demo，就算能跑起来，估计也得自己研究半天，麻烦的要死。
我猜测很重要的原因可能就是Sentinel关于这块做的并不完善，而且从官方的Issue中能看出来，其实官方对于这块后续并没有计划去做的更好。
那么废话不多说，在此之前，肯定要先说下关于Sentinel集群限流方面的原理，没有原理一切都是空中楼阁。
集群限流原理原理这方面比较好解释，就是在原本的限流规则中加了一个clusterMode参数，如果是true的话，那么会走集群限流的模式，反之就是单机限流。
如果是集群限流，判断身份是限流客户端还是限流服务端，客户端则和服务端建立通信，所有的限流都通过和服务端的交互来达到效果。
对于Sentinel集群限流，包含两种模式，内嵌式和独立式。
内嵌式什么是内嵌式呢，简单来说，要限流那么必然要有个服务端去处理多个客户端的限流请求，对于内嵌式来说呢，就是整个微服务集群内部选择一台机器节点作为限流服务端（Sentinel把这个叫做token-server），其他的微服务机器节点作为限流的客户端（token-client），这样的做法有缺点也有优点。

文章插图

限流-嵌入式
首先说优点：这种方式部署不需要独立部署限流服务端，节省独立部署服务端产生的额外服务器开支，降低部署和维护复杂度。
再说缺点，缺点的话也可以说是整个Sentinel在集群限流这方面做得不够好的问题。
先说第一个缺点：无自动故障转移机制。
无论是内嵌式还是独立式的部署方案，都无法做到自动的故障转移。
所有的server和client都需要事先知道IP的请求下做出配置，如果server挂了，需要手动的修改配置，否则集群限流会退化成单机限流。
比如你的交易服务有3台机器ABC，其中A被手动设置为server，BC则是作为client，当A服务器宕机之后，需要手动修改BC中一台作为server，否则整个集群的机器都将退化回单机限流的模式。
但是，如果client挂了，则是不会影响到整个集群限流的，比如B挂了，那么A和C将会继续组成集群限流。
如果B再次重启成功，那么又会重新加入到整个集群限流当中来，因为会有一个自动重连的机制，默认的时间是N*2秒，逐渐递增的一个时间。
这是想用Sentinel做集群限流并且使用内嵌式需要考虑的问题，要自己去实现自动故障转移的机制，当然，server节点选举也要自己实现了。
对于这个问题，官方提供了可以修改server/client的API接口，另外一个就是可以基于动态的数据源配置方式，这个我们后面再谈。
第二个缺点：适用于单微服务集群内部限流。
这个其实也是显而易见的道理，都内部选举一台作为server去限流了，如果还跨多个微服务的话，显然是不太合理的行为，现实中这种情况肯定也是非常少见的了，当然你非要想跨多个微服务集群也不是不可以，只要你开心就好。
第三个缺点：server节点的机器性能会受到一定程度的影响。
这个肯定也比较好理解的，作为server去限流，那么其他的客户端肯定要和server去通信才能做到集群限流啊，对不对，所以一定程度上肯定会影响到server节点本身服务的性能，但是我觉得问题不大，就当server节点多了一个流量比较大的接口好了。
具体上会有多大的影响，我没有实际对这块做出实际的测试，如果真的流量非常大，需要实际测试一下这方面的问题。
我认为影响还是可控的，本身server和client基于netty通信，通信的内容其实也非常的小。
独立式说完内嵌式的这些点，然后再说独立式，也非常好理解，就是单独部署一台机器作为限流服务端server，就不在本身微服务集群内部选一台作为server了。