微服务踩坑实录：SpringCloud集群用雷池WAF，解决3个跨服务防护难题
我们团队做SpringCloud微服务转型，6个服务分散在K8s集群，之前防护是“各自为战”——有的服务加拦截器，有的靠Nginx限流，跨服务调用时总出问题。用雷池WAF做统一防护后，不仅解决了跨服务的防护漏洞，还让运维效率提升60%，今天分享微服务场景的实战经验，Java同行能直接参考。
一、SpringCloud集群的跨服务防护坑
我们的微服务架构是“Gateway+6个业务服务+MySQL集群”，之前的痛点集中在跨服务场景：
服务间调用无防护：用户服务调用订单服务时，被异常参数穿透，导致订单服务报错；
规则同步麻烦：改一条防护规则，要在6个服务里分别配置，漏改1个就出问题；
跨服务日志难查：某服务被攻击，要查6个服务的日志，半天找不到源头。
雷池的统一防护+集群同步功能，正好解决这些，不用改微服务代码，统一在WAF层防护。
二、雷池适配SpringCloud的实战方案
1. 架构设计：雷池+Gateway联动
我们把雷池部署在Gateway前端，所有请求先过雷池，再到Gateway，最后分发到业务服务，架构图很简单：
用户请求 → 雷池WAF → SpringCloud Gateway → 各业务服务
这样不管是用户直接请求，还是服务间调用，都经过雷池防护，没有漏洞。
2. 部署雷池集群：3节点同步规则
我们用3台雷池节点（2核4G），1主2从，主节点管规则，从节点分担流量：
步骤1：主节点部署
docker run -d --name leichi-master \ -p 80:80 -p 443:443 -p 9443:9443 \ -v /etc/leichi:/etc/leichi \ -e LEICHI_ROLE=master \ leichi/waf:enterprise
登录主节点控制台，记录主节点IP和同步密钥。
步骤2：从节点部署（2台）
docker run -d --name leichi-slave \ -p 80:80 -p 443:443 \ -v /etc/leichi:/etc/leichi \ -e LEICHI_ROLE=slave \ -e LEICHI_MASTER_IP=主节点IP \ -e LEICHI_SYNC_KEY=同步密钥 \ leichi/waf:enterprise
从节点自动同步主节点规则，不用单独配置，主节点改规则后，从节点1分钟内生效。
3. 跨服务防护配置：3条核心规则
规则1：服务间调用防护
针对服务间调用的接口（比如/api/order/call），在雷池里加规则：
限制调用来源：只允许Gateway的内网IP（[192.168.0.10](192.168.0.10)）访问，其他IP禁止；
参数校验：“orderID必须为纯数字”“amount>0”，不符合拦截。
这样异常参数穿不透Gateway，业务服务更安全。
规则2：统一限流
在雷池“CC防护”里加全局规则：
防护路径：
/api/*；限制维度：“IP+服务Token”；
频次阈值：“每分钟最多50次”。
不管是哪个服务的接口，都按统一标准限流，避免单服务被高频请求搞崩。
规则3：跨服务日志汇总
雷池主节点汇总所有从节点的日志，在控制台能按“请求路径、服务名称、攻击类型”筛选，比如要查订单服务的异常请求，输入/api/order/*就能定位，不用再查6个服务的日志。
三、微服务使用心得：3个提升效率的技巧
和Gateway联动：在Gateway里配置雷池的IP白名单，避免服务间调用被误拦；
按服务分组规则：把6个服务的规则按“用户服务”“订单服务”分组，管理更清晰；
定期同步规则：每周在主节点更新一次规则，从节点自动同步，不用手动操作。
现在我们的SpringCloud集群稳定运行4个月，跨服务调用的异常率从15%降到0.5%，运维不用再挨个服务改配置，省了不少精力。如果你们也是SpringCloud微服务，遇到跨服务防护难题，试试雷池的统一方案，比各自为战高效多了。