从使用者的视角来感受一个开源专案的成长，是我们推出“开发者说”专栏的初衷，即在开发者进行开源专案选型时，提供更为立体的专案资讯。专栏所有内容均来自作者原创/投稿，本文是“开发者说”的第6篇，作者 Jason Joo，@友乐活（北京），Sentinel Committer.
1st：《深度剖析开源分散式事务方案 Seata 的事务协调器》
2nd：《RocketMQ 讯息传送的高可用设计》
3st：《讯息伫列 Kafka 和 RocketMQ 之我见》
4th：《如何参与定义一款 IDE 外挂》
5th：《基于 Nacos 的闸道器灰度路由和服务权重灰度》
流控在分散式系统中是较为基本的需求，其需要在系统负载、服务质量、流量甄别、安全⻛控等⽅⾯进⾏保障，并根据业务需求，进⾏动态调整或⼈工临时介入，尤其是在⼀些事件性的时期，以实现快速控制和恢复服务的效果。
流控手段一般挂载在流量闸道器和业务内的逻辑。
流量闸道器常见于 Nginx 这类代理层，通过扩充套件外挂、Lua指令码进⾏针对 IP/Path/Query 等形式的流控。业务内则⼤多在区域性或框架层进行讯号量、执行绪池、超时时间或其它逻辑来实现流控。前者主要体现在运维的可操作性，不侵⼊业务线，而后者则针对性更强，但有侵⼊性或修改时需要部署，⾯向业务团队可控。
两种型别的流控往往⽐较割裂（由不同的团队在不共享的空间内进行控制），常出现指标的不协调性。
为了解决这⼀问题，我们开始汇总现有的需求，调研相关的系统，并准备实现⼀套可以同时面向业务和运维，进行应用级隔离和满足基本规则型别需求的流控实现，预期是在 Nginx 端利用LuaJIT实现一套更为强大的流控模组。
调研过程中，适逢 Sentinel 0.1/0.2的释出，⽀持servlet整合（URL限流），带有操作⾯板（Dashboard），支援基本的实时状况检视、实时的修改分发规则、全域性负载和单点熔断，能基于QPS、讯号量等形式进行流控。除了零侵入以外，基本满⾜我们的需求，所以准备基于 Sentinel 进行方案落地尝试。
我们的基本需求如下：
整合适配
基于 Sentinel 所提供的功能、适配方式，需要进行基本的配置和修改。
整合方式
现有项⽬流量⼊口部分⼤多为基于 SpringMVC 的专案，少部分为 SpringBoot 专案，并且从运维部署的角度看，⽬前主要有普通运⾏方式（JVM/Tomcat）和容器化方式。
所以我们根据实际的需求，将 Sentinel 初始化⼯作进⾏了封装，基于 SpringMVC 提供了XML初始化方式，基于 SpringBoot 提供了注解初始化方式，例如：
整合框图
整合要点
主要使⽤了sentinel-web-servlet，采用这个方案，⽆需对Dashboard做任何⼆次开发，可跟随升级，对业务侵入较少
本文作者：
Jason Joo，Sentinel Committer，@友乐活（北京），[email protected]，拥有超过⼗年的软硬件体系技术实践，傍身技能：Java/C/Golang，资料中介软件/分散式系统设计/容器编排排程熟悉TCP/IP协议栈与优化(*nix)，Linux核心⼆次开发。
-----------------------------------
本文作者：中介软件小哥
原文连结：https://yq.aliyun.com/articles/705346?utm_content=g_1000062616
本文为云栖社群原创内容，未经允许不得转载。
