Integration of sentinel series Nacos to realize rule synchronization and persistence

What does the title mean , The reason is that the last chapter ： Use and maintenance in Nacos A current limiting in Json To do it Sentinel Persistence of flow restriction rules , Some students here will ask ： Isn't it already realized ？ Why do you have to say it again , In fact! ,Nacos In the last chapter, we made persistence , So he's talking to Sentinel When doing Integration , Think about it ,Nacos What role do you play ？ We usually develop , When it comes to data persistence , Who will you think of at the first time ？ No accident should be MySQL, therefore , In the above relationship ,Nacos Also acts as a “ database ” Role , But there is a risk , I'll write it alone ：

All current limiting rules are persisted to Nacos, That's fine , But the problem is , We are Nacos The current limit rules are directly modified on the console and synchronized , But there are too many project developers , There will be a problem ： Personnel information is not synchronized , What does that mean , Namely , Some developers may not know that the current limit rules are Nacos On maintenance , Default will go Dashboard Directly operate on the , such , It will lead to problems that are difficult to manage , and Nacos The location of is the registry and configuration center , If you do it directly Nacos To do it Sentinel Persistence of the rules of is more or less inappropriate ！

How to solve the above problems ？ The solution is simple , That's it ： modify Sentinel Source code , stay Dashboard Maintain flow restriction rules on the and call directly at the same time Nacos service , Synchronize to Nacos Just above , No need to maintain two sets ( First maintain Nacos, Maintain it again Sentinel Dashboard)

Synchronous implementation

---

1、 Know the source code first

Sentinel When the console makes flow control rules , Will be called SentinelD