If same instance register twice, should different instanceId.

If update instance, the instanceId should be same.

If same instance register twice, should different instanceId.

If update instance, the instanceId should be same.

We can't differ update or twice register. we modify the instance matadata in console, it's update. But in controller, it's will register again.

So I think just judge whether old instance exist, if exist, use old instanceId, instanceId should not be update except deregister then register.

Or we need to discuss whether push down instance generating to client part. I think id generate in server part is not reasonable.

So I think just judge whether old instance exist, if exist, use old instanceId, instanceId should not be update except deregister then register.

Or we need to discuss whether push down instance generating to client part. I think id generate in server part is not reasonable.

If generating in client side, we can't gan guarantee that the instanceId will repeat, so also need judge in server side.
It's not a good idea.

Users to guarantee. the instance definition is controlled by users. We only received and apply it.

The snowflake need add an workId, which need user input. It can make sure instance not duplicate.

Users to guarantee. the instance definition is controlled by users. We only received and apply it.

The snowflake need add an workId, which need user input. It can make sure instance not duplicate.

what's the concept of workId?

this is a concept from snowflake.

this is a concept from snowflake.

good idea, but it will increase the cost of use for user, user need consider the way how to differ workId. It's unfriendly for user.

Even add it in server part, user also need to learn workid and snowflake, otherwise they can't use well because User includes developer and maintainer.

BTW, the instanceId means the identify of instance, not nacos identify. So I think generate by client with app is more reasonable.

Also we can generate the workId in client part, such as use ip or hostname to hash an workId as default if users do not config.

But now we has implemented in server part, so we need to adapt it first in a few time.

Also we can generate the workId in client part, such as use ip or hostname to hash an workId as default if users do not config.

hash conflict need be consider, it also cann't guarantee the unique workId.

workId may not suit our situation, the workId is certain such as 2^n, we know the value of n. But we don't know the number of computer will register instance to server.

I just give an example, when we execute this plan, we need to discuss more details.