polaris原地替换eureka server节点

[MI-cool]

What is the feature you want to add?
支持在eureka server节点原地部署polaris来完成eureka的替代

Why do you want to add this feature?
降低eureka迁移到polaris的业务成本

Additional context
eureka server节点原地部署polaris
——————
这一步验证下来发现有几个解决成本很高的问题
1.polaris节点启动时不会从eureka节点拉已注册服务，会使调用过来的eureka client丢服务信息，还无法处理自己没有的实例的心跳
2.polaris不会向eureka节点同步数据
3.polaris没有peerreplication/batch/接口，不能处理eureka server同步的数据

How to implement this feature?
问题1和2可以考虑添加eureka-sync plugin，可以通过配置文件配置是否启用plugin、eureka peer节点列表。
最好的是plugin带节点探测功能，能够识别peer节点是否已完成polaris的替代，已完成替代的自动停止同步

[andrewshan]

建议方案：polaris的eureka插件，实现eureka的peerreplication能力，支持服务数据的集群同步能力，支持用户将polaris-server加入到eureka集群中

[andrewshan]

升级阶段：

阶段一：相互独立阶段

北极星和eureka集群相互独立，注册在eureka服务无法发现注册在北极星的服务。

阶段二：将1个eureka实例升级成北极星实例

将其中一个eurekaserver原地升级成polaris，polaris会接收并处理其他eureka server的replicate请求，并且会将自身的数据也replicate到其他eurekaserver，实现两边服务的互通

阶段三：将eureka完成替换成polaris

[andrewshan]

拆分任务

1. 实现eureka batch接口，支持接收其他eureka server的同步请求
2. 实现replicate逻辑，支持将create, delete, hearbeat, update请求同步到其他eureka server

[andrewshan]

多种注册中心迁移场景的梳理

1. 原地升级：新注册中心加入存量注册中心集群，原地逐步替换老注册中心。好处：迁移周期短，无缝迁移；缺点：新老注册中心所有的接口和API都必须一致，可以互加集群，一般用于同类型注册中心

适用场景：同类型注册中心之间的迁移，比如北极星到北极星，eureka到北极星之间的迁移

2. java-agent辅助迁移：新业务加入java-agent，实现往存量注册中心的双注册双发现，迁移完成后去掉java-agent。好处：可以实现异构注册中心的迁移；坏处：只能在java应用使用，迁移周期比较长，迁移完毕后，新业务需要逐步下掉java-agent

适合场景：适合java应用，完成nacos/zk/consul等异步注册中心到北极星的迁移，

3. 同步工具辅助迁移：通过同步服务实现新老注册中心的数据同步。好处：支持多语言应用，客户端不感知，迁移完成后新业务无需再调整。坏处：迁移周期较长，且同步工具会是一个故障风险点（同步工具的故障可能会导致同步的服务下线等问题）

适合场景：适合多语言应用，异构注册中心的迁移

[andrewshan]

接纳，多实现一种数据同步的方式