注册发现说明
采用网络接口进行通信，并且支持多实例弹性扩缩容是微服务一个重要的特征。 一个微服务 A 需要和另外一个微服务 B 进行 通信，首先需要知道微服务 B 的网络地址信息， 这个过程一般是通过注册发现实现的。
最常见的服务发现机制是引入一个中间件服务， 微服务 B 启动的过程中，向中间件服务注册自己的网络地址信息，微服务 A 访问 B 的时候， 首先从中间件服务查询微服务 B 的网络地址信息。
对于规模较小的系统，也可以不使用中间件服务，而是通过配置文件的方式，在微服务 A 中指定微服务 B 的地址。这种方式 适合组网情况固定，不会弹性扩缩容的场景。
在局域网环境下，还可以通过组播协议，比如 mDNS 发现其他的服务，这种方式不需要做额外的配置。
注册发现信息
- 微服务信息
servicecomb 的微服务信息在类 Microservice 中定义。 它主要包含应用 ID (appId)， 微服务名称 (serviceName),
微服务版本(version)，环境(environment) 等信息， 还包括契约。 契约是 servicecomb 治理管控的基础。
- 实例信息
servicecomb 的实例信息在类 MicroserviceInstance 中定义。 它主要包含网络地址(endpoints) 信息。
不同的注册发现机制，可能注册的信息和发现的信息不包括上述信息的全集，可以通过组合不同的注册发现机制，提供完整的信息。 比如，可以通过 mDNS 的方式发现网络地址(endpoints)信息， 可以通过配置文件的方式，发现契约信息。
同时使用多个注册发现
从 2.1.0 版本开始，可以同时使用多个注册发现的实现。组合不同的注册发现的实现，能够满足一些非常重要场景的需求。
使用多个服务中心的约束和行为
- 服务注册
使用多个服务中心，同时往多个服务中心注册。 当需要获取本服务 Microservice 和 MicroserviceInstance
信息的时候，不同的注册中心的 Microservice ID 和 MicroserviceInstance ID 是不同的。
RegistrationManager 接口返回的实例是优先级最高的 Registration 实现的实例。
- 服务发现
如果多个注册中心都存在同一个微服务信息， 这些微服务信息必须满足 java chassis 的接口兼容性策略。 比如微服务 A 存在 v1, v2, v3 三个版本， 在不同的注册中心注册的同一个版本 v3， 必须契约一样；v1， v2，v3 并存的情况下， v2 的接口需要兼容 v1， v3 的接口需要兼容 v2 （接口可以多，不能少， 要求开发的时候， 只增加接口，不删除接口）。
如果不能满足上述约束， 请求过程中可能出现 404 找不到接口的错误。 这种错误在使用单个注册发现的情况下极少
出现，参考微服务接口兼容常见问题。 在多个
注册中心的情况下，使用不恰当就容易出现，比如通过 本地服务注册发现 定义了微服务 A 的信息， 只包含 2 个
schema， 同时往 服务中心 注册了全量的 5 个 schema ， 并且本地服务注册发现的版本 v3 高于 服务中心
的 v1 版本， 那么这种情况就可能出现调用接口提示 404 的错误。
因此建议在使用多个注册中心的时候， 满足下面的约束：
- 一个微服务只在一个注册中心有信息，比如 本地注册中心只定义三方服务，服务中心用于 java chassis 服务注册发现。 或者，
- 一个微服务在多个注册中心的信息是一样的，比如 使用多个 region 的服务中心，他们注册发现流程一样，可以保证信息一样。
这样能够避免违背接口兼容性策略。