注册发现说明

采用网络接口进行通信,并且支持多实例弹性扩缩容是微服务一个重要的特征。 一个微服务 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 版本开始,可以同时使用多个注册发现的实现。组合不同的注册发现的实现,能够满足一些非常重要场景的需求。

使用多个服务中心的约束和行为

  • 服务注册

使用多个服务中心,同时往多个服务中心注册。 当需要获取本服务 MicroserviceMicroserviceInstance 信息的时候,不同的注册中心的 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 的错误。

因此建议在使用多个注册中心的时候, 满足下面的约束:

  1. 一个微服务只在一个注册中心有信息,比如 本地注册中心只定义三方服务,服务中心用于 java chassis 服务注册发现。 或者,
  2. 一个微服务在多个注册中心的信息是一样的,比如 使用多个 region 的服务中心,他们注册发现流程一样,可以保证信息一样。

这样能够避免违背接口兼容性策略。