客户端使用没有在服务端创建的namespace Id,可以正常注册发现,但是控制台看不到
最近遇到一个问题,有部分业务正常在运行,注册发现都在nacos上,但是之前一直都没注意到,从控制台看不到。 后来发现是使用了一个没有在服务端创建的namespaceid,在控制台看不到,但是注册发现能正常通。这是比较具有迷惑性的。
是不是考虑做阻止注册,或者自动创建namespaceid等特性,来保持这部分的感知一致性?
Here is the English translation:
Recently, I encountered an issue where some services were running normally, and their registration and discovery were done through Nacos, but I hadn't noticed it before, and they were not visible in the console. Later, I found out that an uncreated namespace ID was used on the server side, so it was not visible in the console, but registration and discovery were still working normally. This situation was quite confusing.
Should we consider implementing features like preventing registration or automatically creating namespace IDs to maintain consistency in this aspect?
确实能复现~.~ @KomachiSion 是不是应该阻止注册?我可以来实现。
注册中心不强制依赖数据库, 不主动拦截。
命名空间数据需要依赖数据库
The scene, We only use naming mode.
If i do not create namespace , naming register or naming list instance is good.
But there is no api that can get all namespace, So that is not easy to moniter the namespace and service by openapi
是的,如果有一些机制,能读取内存的命名空间清单(naming的)就好了。 那就可以和数据库的命名空间清单做一个对比,这样至少能检测到这种场景。
same as #11274
可以先将命名空间存在的校验通过数据库依赖先实现, 因为现在命名空间模块已经下沉到core模块了, 所以依赖数据库是暂时无法去除的问题。
之后在对数据存储做大修改的时候再进行处理吧。
- 客户端注册之前,先请求服务端,获取服务端所有可用namespace_id。
- 客户端判断当前配置的namespace_id是否含括在服务端返回的id中。
这个思路是否可行?🤔
修改这个问题我有以下几个疑问:
- 当注册时,如果没有namespace,那么此时是要拦截注册吗,或者添加一个参数开关来控制是否自动创建一个namespace,默认为拦截。
- 添加配置时也需要对命名空间做一个校验,逻辑我认为和注册校验逻辑保持一致即可
- 注册这个动作当前都是一些内存操作,如果添加了namespace的校验,此时需要访问一次数据库,这个开销对注册的性能可能会有影响,是否需要在查询namespace这里添加一个缓存呢。
- 当删除命名空间时,需要考虑当前这个命名空间是否被某些配置和注册实例所使用,如果当前命名空间被使用应该禁止删除。