xy-github-issue

> 期望instanceId不变的原因是什么？ 首先其实是文档给到我的感觉，所以文档内容需要修正吧。 然后 endpoints 内容相同的情况下，倒底要不要生成相同的 instanceid ，我也有想不清楚的地方。一方面进程挂了，重新起来，换 instanceid 似乎是有一定的合理性的。但是，我明显可能想到的有问题的场景：如果有一个定时任务（作为consumer，一定需要一个instanceid吗？还是只需要一个consumer 的服务id？），每次启动都产生一个新的 instanceid，假设这个业务有问题，繁复地重启，就可能把 instanceid 耗尽。从而一个有问题的业务，可能把整个service-center搞挂。再结合下面的考虑，外部看到一个服务实例，肯定是不关心你的进程是什么(更具体的比如，肯定不关心你的进程id)，我只看到你的endpoint及关联在服务id上的服务信息，从这一点上看，endpoint+serviceid 不变 ==> 相同的 instanceid 是很合理的，对于服务使用方来说，这个实例没有变。关于上面这一点，现在的实现给到我一个感觉比较意外的行为是，查询服务实例时，会得到有重复的endpoint列表(服务实例挂了，重启后注册产生了新的实例，还未过120秒原实例信息未清掉)，但我使用服务的时候，相同的endpoint 就是相同的。当然我是对取到的 endpoint 列表去重了一下啦。 我也想了解下，出于什么考虑，你们需要针对相同的信息每次生成不同的instanceid，你们期待大家以什么样的姿势来使用？

> 比如，基础服务A被部署在业务平面和管理平面，分别被各自不同平面业务依赖消费，当进程重启时候，业务平面某个容器IP被分配到管理平面去了 这个例子，我有点看不懂。这里说的，是否是有一个服务 A，A 同时有 1. 服务实例 1 在**业务平面**上 2. 服务实例 2 在**管理平面**上 首先**平面**这个概念我不是很懂，它是service-center 中的概念？对应什么代码或界面里的什么英文命名？ 看起来，在不同**平面**的实例是不等价的。 如果**平面**不是service-center中的概念，而业务自己的业务概念，那似乎不应该是 service-center 去处理的，service-center 最多只能为业务提供一些 meta-data，业务自己处理好自己的负载均衡规则。或者本来两个不同平面上的实例就应该是两个不同的服务？