注册发现说明

采用网络接口进行通信，并且支持多实例弹性扩缩容是微服务一个重要的特征。 一个微服务 A 需要和另外一个微服务 B 进行 通信，首先需要知道微服务 B 的网络地址信息， 这个过程一般是通过注册发现实现的。

最常见的服务发现机制是引入一个中间件服务， 微服务 B 启动的过程中，向中间件服务注册自己的网络地址信息，微服务 A 访问 B 的时候， 首先从中间件服务查询微服务 B 的网络地址信息。

对于规模较小的系统，也可以不使用中间件服务，而是通过配置文件的方式，在微服务 A 中指定微服务 B 的地址。这种方式 适合组网情况固定，不会弹性扩缩容的场景。

在局域网环境下，还可以通过组播协议，比如 mDNS 发现其他的服务，这种方式不需要做额外的配置。

注册发现信息

  • 微服务信息

    servicecomb 的微服务信息在类 Microservice 中定义。 它主要包含应用 ID (appId)， 微服务名称 (serviceName), 微服务版本(version)，环境(environment) 等信息， 还包括契约。 契约是 servicecomb 治理管控的基础。

  • 实例信息

    servicecomb 的实例信息在类 MicroserviceInstance 中定义。 它主要包含网络地址(endpoints) 信息。

不同的注册发现机制，可能注册的信息和发现的信息不包括上述信息的全集，可以通过组合不同的注册发现机制，提供完整的信息。 比如，可以通过 mDNS 的方式发现网络地址(endpoints)信息， 可以通过配置文件的方式，发现契约信息。

使用服务中心

服务中心(servicecomb-service-center) 提供了完备的注册发现机制， 实现了所有 Microservice 和 MicroserviceInstance 信息的注册和发现， 是 servicecomb 缺省使用的注册发现机制。

服务中心支持使用 PULL 和 PUSH 两种模式通知实例变化， 开发者可以配置服务中心集群地址、连接参数以及心跳管理等。

  • 表1-1 访问服务中心常用的配置项
配置项默认值是否必选含义
servicecomb.service.registry.addresshttp://127.0.0.1:30100是服务中心的地址信息，可以配置多个，用逗号分隔。
servicecomb.service.registry.instance.watchtrue否是否采用PUSH模式监听实例变化。为false的时候表示使用PULL模式。
servicecomb.service.registry.autodiscoveryfalse否是否自动发现服务中心的地址。当需要配置部分地址，其他地址由配置的服务中心实例发现的时候，开启这个配置。
servicecomb.service.registry.instance.healthCheck.interval30否心跳间隔。
servicecomb.service.registry.instance.healthCheck.times3否允许的心跳失败次数。当连续第times+1次心跳仍然失败时则实例被sc下线。即interval * (times + 1)决定了实例被自动注销的时间。如果服务中心等待这么长的时间没有收取到心跳，会注销实例。
servicecomb.service.registry.instance.empty.protectiontrue否当从服务中心查询到的地址为空的时候，是否覆盖本地缓存。这个是一种可靠性保护机制，避免实例异常批量下线导致的请求失败。

servicecomb 与服务中心采用 HTTP 进行交互， HTTP client 相关配置可以参 考 Service Center Client 配置项

同时使用多个注册发现

从 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 的错误。

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

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

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