架构模式: 第三方注册
背景
如采用客户端服务发现模式或者服务器端服务发现模式，各服务实例必须在启动时注册至服务注册表，从而保证其能够被获取，并在关闭时进行注销。
问题
如何在服务注册表内注册和注销服务实例？
需求
- 各服务实例必须在启动时被注册至服务注册表，并在关闭时进行注销。
- 崩溃的服务实例必须从服务注册表中注销。
- 在运行但无力处理请求的服务实例必须从服务注册表中注销。
方案
由第三方注册机制负责各项服务实例在服务注册表中的注册与注销。当该服务实例启动时，其将服务实例注册至服务注册表。而在服务实例关闭时，其将该服务实例从服务注册表中注销。
示例
第三方注册模式的示例包括：
- Netflix Prana - 这是一款“边车”类应用，可与非JVM应用共同运行并利用Eureka为该应用注册。
- AWS Autoscaling Groups - 能够自动将EC2实例注册（注销）至Elastic Load Balancer。
- Joyent的Container buddy 运行在Docker容器当中，作为服务的父进程并将其注册至注册表。
- Registrator - 能够将Docker容器注册至多种服务注册表，或者从其注销。
- 以Kubernetes 与 Marathon 为代表的各类集群框架将服务实例注册至内置/隐式的注册表，或者从其注销。
结果
第三方注册模式的优势在于：
- 与自注册模式相比，服务代码复杂程度更低，因为其无需实现自动注册。
- 注册工具可对服务实例执行健康检查，并根据检查结果注册或者注销该实例。
但第三方注册模式也存在着以下弊端：
- 第三方注册模式可能只了解服务实例的一些表层状态，例如其是否正在运行，因此 无法了解其是否能够处理请求。不过，之前提到的Netflix Prana等注册工具能够通过执行健康检查来判断当前服务实例的可用性。
- 除非该注册工具属于基础设施的一部分，否则我们需要对其进行安装、配置与维护。另外，因为它是关键系统组件，因此需要保证其具有高度可用性。
相关模式
- 服务注册表
- 客户端服务发现
- 服务器端服务发现
- 自注册是一个备选方案。