上一篇文章我们讲了 Sentinel 的入门知识，相信大家已经能跑起来一个简单的 demo 了。但是在实际的生产环境中，光会配置基本的流控和降级规则是远远不够的。
今天我们就来聊聊 Sentinel 的进阶实战，解决三个最核心的问题：
-
怎么和 Feign 整合，实现远程调用的熔断降级？
-
怎么自定义全局异常处理，返回统一的 JSON 格式？
-
怎么解决规则持久化的问题，避免重启服务后规则丢失？
这三个问题解决了，你的 Sentinel 就能直接上生产了！
一、Sentinel 整合 Feign：远程调用的熔断降级
在微服务架构中，我们几乎都是通过 Feign 来调用远程服务的。所以，我们的熔断降级逻辑也应该写在 Feign 接口上，这样当远程调用失败时，就能直接触发降级。
1. 开启 Feign 对 Sentinel 的支持
在 application.yml 中添加配置：
feign: sentinel: enabled: true # 开启Feign对Sentinel的支持
2. 编写降级逻辑类
我们需要实现FallbackFactory接口，在里面编写降级逻辑。这样不仅能返回默认结果，还能获取到异常信息，方便我们排查问题。
3. 在 Feign 接口上指定降级逻辑
在@FeignClient注解中添加fallbackFactory属性，指定我们刚才编写的降级逻辑类。
4. 测试
现在我们启动服务，然后把 user-service 停掉，再调用getUserById接口，就会看到返回了我们在降级逻辑中定义的结果：
{ "id": 1, "name": "用户服务暂时不可用", "age": 0 }
完美！这样当下游服务不可用时，我们的服务不会被拖垮，还能给用户一个友好的提示。
二、全局异常处理：告别丑陋的默认页面
上一篇文章中我们看到，当触发限流或降级时，Sentinel 会返回一个默认的页面：
Blocked by Sentinel (flow limiting)
这个页面不仅丑陋，而且不符合我们前后端分离的架构。我们需要自定义全局异常处理，让 Sentinel 返回统一的 JSON 格式。
1. 实现 BlockExceptionHandler 接口
Sentinel 提供了BlockExceptionHandler接口，我们只需要实现这个接口，就能自定义异常处理逻辑。
2. 统一返回结果类
这里的Result是我们项目中统一的返回结果类，大家可以根据自己的项目进行调整：
3. 测试
现在我们再次触发限流，就会看到返回了统一的 JSON 格式：
{ "code": 500, "message": "系统繁忙，请稍后再试", "data": null }
是不是舒服多了？前端也能统一处理这些异常了。
三、Nacos 持久化：解决规则丢失的痛点
Sentinel 有一个最大的痛点：规则默认是存在内存中的。当我们重启 Sentinel 控制台或者重启微服务时，所有的规则都会丢失。这在生产环境中是绝对不能接受的。
解决这个问题的方案就是将规则持久化到 Nacos 中。这样，我们在 Sentinel 控制台配置的规则会自动同步到 Nacos，微服务启动时会从 Nacos 拉取规则，重启也不会丢失。
方案说明
我们采用的是Sentinel 控制台 → Nacos → 微服务的双向同步方案：
-
在 Sentinel 控制台新建或修改规则，会自动同步到 Nacos
-
微服务从 Nacos 拉取规则并应用
-
直接在 Nacos 中修改规则，也会实时同步到微服务
1. 改造 Sentinel 控制台
首先，我们需要改造 Sentinel 控制台，让它支持将规则同步到 Nacos。
步骤 1：下载改造好的 Sentinel 控制台
官方的 Sentinel 控制台默认不支持 Nacos 持久化，我们需要自己改造。不过已经有很多大佬帮我们改造好了，我们直接下载使用即可。
-
下载地址：https://github.com/alibaba/Sentinel/releases/download/1.8.6/sentinel-dashboard-1.8.6.jar
-
或者你也可以自己下载源码进行改造，过程也很简单。
步骤 2：修改配置文件
用压缩工具打开sentinel-dashboard-1.8.6.jar，找到BOOT-INF/classes/application.properties文件，添加 Nacos 的配置：
步骤 3：启动改造后的 Sentinel 控制台
java -jar sentinel-dashboard-1.8.6.jar
2. 微服务端配置
接下来，我们需要在微服务中添加依赖，让它能从 Nacos 拉取 Sentinel 规则。
步骤 1：引入 Nacos 数据源依赖
步骤 2：配置 Nacos 数据源
在 application.yml 中添加 Sentinel 的 Nacos 数据源配置：
3. 测试
现在我们在 Sentinel 控制台新建一个流控规则，然后打开 Nacos 控制台，就能看到对应的配置文件已经自动生成了。 接着我们重启微服务，再去 Sentinel 控制台查看，规则依然存在。完美！规则持久化的问题解决了！
四、生产环境踩坑总结
最后，给大家分享几个我在生产环境中使用 Sentinel 踩过的坑，避免大家再走弯路：
-
降级逻辑一定要轻量：降级逻辑本身不能再调用远程服务，否则可能会引发新的问题。最好是直接返回缓存数据或者默认值。
-
合理设置熔断时长：熔断时长不能太短也不能太长。太短的话，下游服务还没恢复就又开始调用，会导致频繁熔断；太长的话，会影响用户体验。一般设置 5-30 秒比较合适。
-
监控告警不能少：Sentinel 提供了丰富的监控指标，我们一定要对接监控系统（比如 Prometheus+Grafana），设置告警规则。当触发限流或降级时，及时收到通知。
-
规则要逐步调整：不要一开始就把阈值设置得太低或太高。可以先根据压测结果设置一个初始值，然后根据线上的实际运行情况逐步调整。
五、总结
今天我们学习了 Sentinel 的三个核心进阶功能：
-
整合 Feign，实现远程调用的熔断降级
-
自定义全局异常处理，返回统一的 JSON 格式
-
基于 Nacos 实现规则持久化，解决规则丢失的问题
到这里，Sentinel 的核心知识我们就全部讲完了。从入门到进阶，从理论到实战，相信大家看完这两篇文章，已经能在自己的项目中熟练使用 Sentinel 了。
服务保护是微服务架构中不可或缺的一环，而 Sentinel 无疑是目前最好用的服务保护框架之一。希望这两篇文章能帮助大家少踩坑，让自己的服务更加稳定可靠。
如果这篇文章对你有帮助，别忘了点赞、收藏、关注三连！有任何问题，欢迎在评论区留言交流～