如果让你设计一个动态配置的功能,你会怎么做?注意是动态配置,不是配置中心。
先在大脑里面考虑3分钟,也许你有答案了。
对的,你肯定想的和下面一样:
上图是需要人工发起通知的动态配置架构,实现很简单。
但我们为什么要人工操作两次呢,可不可以简化到一次?
对于上图只需要稍作调整,就能达到只需要一次修改配置文件操作。
这样看起来简单多了。
采用定时任务,可以减少人工操作次数,但同时带来了一定的性能损耗。
回到nacos,它多采用的模型是定时任务来获取配置文件。
如果是一台机器,一个配置文件,上面的架构似乎完美胜任,如果将应用变成n个,机器n台,配置文件n个,
此时就会存在问题,人工操作不可能完成上面的工作,也容易出错。必须要自动化才能既保证效率提高,还
能保证不出错。
对此,只需要将上面的架构稍微改一改,就能满足需求。
nacos就是以上架构,十分的简单。
现在来看下他是如何集成到Sp