meshregistry：nacos/eureka source fetch from registry fails will build delete event

[believening]

          这里可能导致单次请求失败就删除了这个server的所有服务、实例，带来的后果比较严重。

可以考虑：

1. 保留上一次cache，失败时沿用；

2. 单个失败升级为整体失败，跳过本次更新；

这个可以单独建issue来优化

Originally posted by @YonkaFang in https://github.com/slime-io/slime/pull/382#discussion_r1226126068

[believening]

关于对接 source 策略的提议：

• 对接 source 基本的策略：

  1. List services： 1.1 List 失败：重试 1.2 List 成功：基于 services 执行 2 和 3

  2. List instances by service 2.1 List 失败：不更新 se 2.2 List 成功：更新 se

  3. Diff last services and cur services 3.1 Last 中存在 cur 不存在的 service： delete

• 聚合多个同类 source 的基本策略：

  • 由于我们将不同注册中心中同名服务视为同一服务，故在单个注册中心执行 list service 失败时，视为本次任务 list services 失败。
  • 对于单个 source 的 service 的 list instances 失败，视为该 service 失败不更新。

---

上述策略在当前实现中的匹配度较低的地方：

• 注册中心的 service 并不严格对应到一个 se，尤其网格模式下在转换过程中会根据 ep 中的信息决定生成的 se，如何做到 List instances by service 失败不更新 se ？（eureka，nacos）
• 我们支持了instance regroup，在 regroup 过程中同样可能会根据 ep 中的信息决定生成的新 service，此时又如何处理？（nacos）

一个潜在的约束是：一个 se 只会来自于某一个 service。在不考虑 regroup 时，对于 List instances by service 失败时不更新 se 有帮助。

---

当前 meshreg 模块对接多注册中心时，存在两种模式：

• eureka 和 nacos 模式：转换服务模型前获取了注册中心的全量数据，按全量数据执行转换。
• zookeeper(dubbo)模式：转换服务模型前首先只是获取到全量的服务级别的数据，然后按服务执行转换。

zk 模式和对接策略提议更加接近。