恶意用户（黑客、爬虫、DDoS攻击者）可能会频繁请求服务器资源，导致资源占用过高，我们可以通过IP封禁拉进黑名单手段阻止恶意或可疑用户，减少攻击风险。
自主实现动态 IP 黑名单的考虑要点
1、IP黑名单存储在哪里？
2、如何便捷地动态修改 IP 黑名单?
3、黑白名单的判断逻辑应在哪里处理?
4、使用何种数据结构保存黑名单？如何快速匹配用户请求的 IP 是否在黑名单中?
1）IP 黑名单存储在哪里?
最简单的方式就是存储在内存中，但一般IP 黑名单是动态增加的、需要持久化保存。常见的持久化方式包括数据库、配置文件或分布式存储系统(如 Redis)，可以根据需要选择。
2）如何便捷地动态修改I 黑名单?
为了方便动态修改 IP 黑名单，通常会提供一个管理页面，供管理员进行增删改查操作。
许多企业会将配置统一放入 配置中心，通过配置中心的管理页面，开发人员可以便捷地动态修改黑名单规则。Java项目中，常用的配置中心是 Nacos。
3）黑白名单的判断逻辑应在哪里处理?
黑白名单逻辑通常部署在高性能的网关或 CDN 上，能够更早地拦截非法请求，减轻后端压力。在小型项目中，也可以直接在应用程序的过滤器中处理。
4）使用何种结构保存黑名单？如何快速匹配?
为了高效判断每个用户请求的IP 是否在黑名单中，首先建议将 IP 黑名单从持久化存储同步到本地缓存中，避免频繁查询远程数据源。对于黑名单数据较小的场景，可以使用简单的 set 数据结构存储。而对于大规模黑名单，推荐使用 布隆过滤器或 DFA 来存储和过滤黑名单，可以节约内存空间、提高检测效率。
总结一下最终方案:
1）使用 Nacos 配置中心存储和管理 IP 黑名单
2）后端服务利用 Web 过滤器判断每个用户请求的 IP
3）后端服务利用布降过滤器过滤 IP 黑名单
布隆过滤器
Bloom Filter 是一种高效的、基于概率的数据结构，用于判断一个元素是否存在于集合中。
原理是利用多个哈希函数将元素映射到固定的点位上(位数组中)，因此面对海量数据它占据的空间也非常小。
例如某个 key 通过 hash-1 和 hash-2 两个哈希函数，定位到数组中的值都为 1，则说明它存在。
如果布隆过滤器判断一个元素不存在集合中，那么这个元素一定不在集合中，如果判断元素存在集合中则不一定是真的，因为哈希可能会存在冲突。因此布降过滤器 有误判的概率。
而且它不好删除元素，只能新增，如果想要删除，只能重建。
它的主要特点包括:
1、空间效率高：相比于传统的数据结构(如哈希表)，Bloom Filter 能用较少的空间存储大量的数据。
2、时间复杂度低：查询操作非常快速，通常是常数时间复杂度 0(1)。
3、允许误判：Bloom Filter 允许假阳性，即有时候会错误地判断某个元素在集合中，而实际该元素并不在集合中。不过，它不允许假阴性，也就是说，如果 Bloom Filter 判断某个元素不存在，那么它一定是不存在的。比如对于我们的需求，Bloom Filter 可能错误地判断一个不在黑名单中的元素为在黑名单中，导致误封。
Bloom Filter 的误判率与以下因素有关:
位数组的大小:位数组越大，误判率越低，但空间开销会增大。(值会更离散)。
哈希函数的个数:哈希函数越多，误判率越低，但计算成本会增加。(Hash 一次冲突，那我就多 Hash 几次，减少冲突概率)
元素数量:存入的元素越多，误判率会增加。
通过 合理设计位数组的大小和哈希函数的个数，可以控制 Bloom Filter 的误判率在一个可接受的范围内。例如，在很多实际场景中，可以将误判率控制在 1%或更低。
假设场景 1:存储 1000 个元素，位数组大小为 10000 位，哈希函数数量为 7。误判率大约为 0.8%。
假设场景 2:存储 100000 个元素，位数组大小为 1,000,000 位，哈希函数数量为 7。误判率大约为 1%。
如果误判的代价较高，但仍想使用 Bloom Filter，可以采取一些补救措施：
1、双层验证:在 Bloom filter 判断元素在黑名单中后，进一步查验实际的黑名单(例如，查数据库中的黑名单详细记录)。
2、结合其他数据结构:可以使用 Bloom filter 进行初步筛选，如果 Bloom filter 判断为在黑名单中，再用哈希表等精确的数据结构进行最终确认。
但这两种方式都无法处理攻击 IP 的大量请求，个人也不建议采用。
因此，布降过滤器适用于对准确性要求不高的、大规模数据量匹配的场景，比如垃圾邮件过滤、爬虫 URL 去重。
缓存穿透防护等。
配置中心
为什么需要配置中心？
在分布式系统中，应用的配置管理变得越来越复杂，特别是当系统规模和组件数量增加时。传统的手动配置(写固定配置文件)往往难以应对这些复杂的需求。
而配置中心的出现就是为了实现分布式系统中配置的 **集中化管理，**还提供动态更新、配置分组、版本控制、灰度发布、安全管理，简化了多环境和多实例的配置运维，确保系统的灵活性和稳定性。
一句话，专业的技术做专业的事。
配置中心支持的功能
1）集中化配置管理:所有服务的配置可以在一个地方集中管理，运维人员和开发人员可以通过统一的接口修改和获取配置，避免了在每个实例中重复配置。
2）动态配置:配置中心允许在不重启应用的情况下动态更新配置，应用可以实时收到配置的修改，进行运行时的调整。
3）多环境配置管理:配置中心，可以为不同的环境配置不同的配置集，按需加载相应的环境配置文件，避免了环境间配置的混淆和出错。
4）配置的版本控制:配置中心一般都会提供版本管理功能，可以查看和回滚到之前的配置版本，这提高了系统的容错性和可恢复性。
5）配置的安全管理:配置中心一般会提供加密存储和权限控制功能，可以对敏感信息(如数据库密码、API密钥等)进行加密处理，并限制访问权限，确保敏感配置信息的安全性。
常见的配置中心：
1）Spring Cloud Config：spring Cloud 提供的配置中心解决方案，支持 Git 等版本管理系统存储配置，适合与 Spring Cloud 系统集成使用。
2）Nacos：阿里巴巴开源的服务注册中心和配置中心，支持动态配置、服务治理，适合微服务架构和 Dubbo、Spring Cloud 的深度集成。
3）Apollo：由携程开源的配置中心，支持多环境、多集群的配置管理，配置实时生效且具有权限控制，适合大规模分布式系统。
4）Consul：由 Hashicorp 提供的服务注册与配置中心，具有强一致性和健康检查功能，适用于服务网格和容器化应用。
一般业务上，我们会选择使用 Nacos 或 Apolo 来作为配置中心，因为这两个提供了比较丰富的控制台管理页面便于我们修改维护配置。
本项目采用Nacos作为配置中心的实现。
什么是Nacos？
Nacos 是 Dynamic Naming and Configuration Service 的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。它提供了一组简单易用的特性集，帮助我们快速实现动态服务发现、服务配置、服务元数据及流量管理。实际上，Nacos 不仅支持配置管理，它还支持服务发现(作为注册中心)。
Nacos 配置管理的核心概念
1、Namespace(命名空间)
命名空间用于隔离不同的配置集。它允许在同一个 Nacos 集群中将不同的环境(如开发、测试、生产)或者不同的业务线的配置进行隔离。(默认提供了一个 public 命名空间)使用场景:在多租户系统中，或者需要区分不同的环境时，可以使用命名空间。例如，开发环境的配置和生产环境的配置完全隔离，可以通过不同的命名空间来管理。
2、Group(组)
配置组是用于将多个相关的配置项进行分类管理的逻辑分组机制。每个配置项可以属于不同的组，以便于配置管理。
使用场景:当一个应用有多个模块，且不同模块之间共享部分配置时，可以用组来对这些模块的配置进行分类和管理。例如，一个系统中的"支付服务"和"订单服务"可能需要用不同的组来存储各自的配置。
3、Data lD
Data ID 是一个唯一的配置标识符，通常与具体的应用程序相关。通过 DataID，Nacos 知道如何获取特定应用的
某个具体配置。使用场景:每个应用的配置都会有一个独特的 DataID。例如，一个支付系统可能有一个配置文件叫 com.payment.pay-service.yaml ，这就是它的 Data lD。
4、Config Listener(配置监听器)
配置监听器用于让客户端实时监听 Nacos 配置中心中的配置变化，可以自动感知配置的更新并做出相应的处理。使用场景:在需要动态调整配置的场景下使用，例如调整缓存大小、切换不同的服务端点等，应用可以通过监听器及时感知这些变化并应用新的配置。
后端开发（基于Nacos实现动态IP黑名单过滤）
在官方中下载Nacos Server，对应版本的应用包，此处使用和Sentinel兼容的2.2.0版本，不要用别的版本不然出现不兼容不好解决。
下载压缩包后进行解压，然后在解压后的文件的bin目录下cmd输入startup.cmd -m standalone命令来启动Nacos Server，standalone代表单机模式运行，非集群模式。如果报找不到Java那就去配jdk8环境变量、JAVA_HOME。
启动后就可以去访问nacos控制台了http://127.0.0.1:8848/nacos，默认用户名和密码都是nacos。
我们可以通过控制台创建配置，填写Ddata ID：zhimianguan，Group有默认的，也可以自行修改，配置格式推荐YAML格式，配置内容填写黑名单如下：
blackIpList:
-
"1.1.1.1"
-
"2.2.2.2"
然后点击发布即可。
接着给我们的项目引入Nacos依赖：
<dependency>
<groupId>com.alibaba.boot</groupId>
<artifactId>nacos-config-spring-boot-starter</artifactId>
<version>0.2.12</version>
</dependency>在application.yml文件中添加nacos server地址等配置：
# nacos配置中心
nacos:
config:
server-addr: 127.0.0.1:8848 # nacos 地址
bootstrap:
enable: true # 预加载
data-id: zhimianguan # 控制台填写的 Data ID
group: DEFAULT_GROUP # 控制台填写的 group
type: yaml # 选择的文件格式
auto-refresh: true # 开启自动刷新可以用 Hutool 或 Guava 库自带的 bloomfilter，参考文章，如果是分布式，还可以考虑 Redisson。
此处由于项目已经使用了 Hutool 工具库，就用其自带的 BitMapBloomfilter 即可。
下面我们来在项目中创建黑名单过滤的工具类，首先新建一个blackfilter包，然后在包下创建一个BlackIpUtils类，代码如下：
/**
* 黑名单过滤工具类
*/
@Slf4j
public class BlackIpUtils {
private static BitMapBloomFilter bloomFilter;
// 判断 ip 是否在黑名单内
public static boolean isBlackIp(String ip) {
return bloomFilter.contains(ip);
}
// 重建 ip 黑名单
public static void rebuildBlackIp(String configInfo) {
if (StrUtil.isBlank(configInfo)) {
configInfo = "{}";
}
// 解析 yaml 文件
Yaml yaml = new Yaml();
Map map = yaml.loadAs(configInfo, Map.class);
// 获取 ip 黑名单
List<String> blackIpList = (List<String>) map.get("blackIpList");
// 加锁防止并发
synchronized (BlackIpUtils.class) {
if (CollectionUtil.isNotEmpty(blackIpList)) {
// 注意构造参数的设置
BitMapBloomFilter bitMapBloomFilter = new BitMapBloomFilter(958506);
for (String ip : blackIpList) {
bitMapBloomFilter.add(ip);
}
bloomFilter = bitMapBloomFilter;
} else {
bloomFilter = new BitMapBloomFilter(100);
}
}
}
}注意，因为 Nacos 配置文件的监听的粒度比较粗，只能知晓配置有变更，无法知晓是新增、删除还是修改，因此不论是选择布降过滤器还是 Hashset 最方便的处理逻辑就是重建。
接着来写一个Nacos监听类，在blackfilter包下新建一个NacosListener类，代码如下：
/**
* nacos 监听器
*/
@Slf4j
@Component
public class NacosListener implements InitializingBean {
@NacosInjected
private ConfigService configService;
@Value("${nacos.config.data-id}")
private String dataId;
@Value("${nacos.config.group}")
private String group;
@Override
public void afterPropertiesSet() throws Exception {
log.info("nacos 监听器启动");
String config = configService.getConfigAndSignListener(dataId, group, 3000L, new Listener() {
final ThreadFactory threadFactory = new ThreadFactory() {
private final AtomicInteger poolNumber = new AtomicInteger(1);
@Override
public Thread newThread(@NotNull Runnable r) {
Thread thread = new Thread(r);
thread.setName("refresh-ThreadPool" + poolNumber.getAndIncrement());
return thread;
}
};
final ExecutorService executorService = Executors.newFixedThreadPool(1, threadFactory);
// 通过线程池异步处理黑名单变化的逻辑
@Override
public Executor getExecutor() {
return executorService;
}
// 监听后续黑名单变化
@Override
public void receiveConfigInfo(String configInfo) {
log.info("监听到配置信息变化：{}", configInfo);
BlackIpUtils.rebuildBlackIp(configInfo);
}
});
// 初始化黑名单
BlackIpUtils.rebuildBlackIp(config);
}
}然后在blackfilter包下新建一个黑名单过滤过滤器BlackIpFilter类，代码如下：
/**
* 黑名单过滤器
*/
@WebFilter(urlPatterns = "/*", filterName = "blackIpFilter")
public class BlackIpFilter implements Filter {
@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
String ipAddress = NetUtils.getIpAddress((HttpServletRequest) servletRequest);
if (BlackIpUtils.isBlackIp(ipAddress)) {
servletResponse.setContentType("text/json;charset=UTF-8");
servletResponse.getWriter().write("{\"errorCode\":\"-1\",\"errorMsg\":\"黑名单IP，禁止访问\"}");
return;
}
filterChain.doFilter(servletRequest, servletResponse);
}
}黑名单应该对所有请求生效(不止是Controller 的接口)，所以基于 Webfilter 实现而不是 AOP 切面。Webfilter的优先级高于 @Aspect 切面，因为它在整个 Web 请求生命周期中更早进行处理。
请求进入时的顺序
WebFilter：首先，WebFilter 拦截 HTTP 请求，并可以根据逻辑决定是否继续执行请求。
Spring AOP 切面(@Aspect):如果请求经过过滤器并进入 Spring 管理的 Bean(例如 Controller 层)，此时切面生效，对匹配的 Bean 方法进行拦截。
Controller 层:如果 @Aspect 没有阻止执行，最终请求到达 @Controller 或 @RestController 的方法。
然后我们需要在启动类上添加@ServletComponentScan注解才能让过滤器被扫描到。
最后我们启动项目后可以进行测试，在nacos控制台修改ip配置，本地测试的话加入本机的ip后如下：
blackIpList:
-
"1.1.1.1"
-
"2.2.2.2"
-
"0:0:0:0:0:0:0:1"
然后我们通过swagger接口文档随便发个请求都会显示黑名单IP，禁止访问。
**注意：**如果你关机了，每次本地启动项目前都要先通过命令启动nacos（在nacos的bin目录下输入startup.cmd -m standalone来启动）。