架构模式: 服务注册表
背景
一项服务的客户端需要使用客户端服务发现或者服务器端服务发现机制，从而获取给其发送请求的服务实例的位置。
问题
服务的客户端（在客户端服务发现机制中）或者服务路由（在服务器端服务发现机制中）如何获取可用服务实例的信息？
需求
- 每个服务实例都会在特定位置（主机与端口）通过HTTP/REST或者Thrift等方式发布一个远程API。
- 服务实例的数量和位置会发生动态变化。虚拟机与容器通常会被分配给一个动态IP地址。例如，AWS的EC2自动伸缩组会根据负载情况调整实例数量。
方案
建立一套服务注册表，即一个包括服务、服务的实例和其位置信息的数据库。各服务实例需要在启动时注册至该服务注册表，并在关闭时进行注销。该服务的客户端以及/或者路由器通过查询此服务注册表以找到可用的服务实例。
示例
服务注册表的例子（或者经常作为服务注册表使用的技术）包括：
Kubernetes、Marathon 以及 AWS ELB 等系统中存在一套隐式的服务注册表。
结果
服务注册表模式的优势包括：
- 服务的客户端及/或路由器能够获取服务实例的位置。
服务注册表模式的弊端包括：
- 除非此服务注册表被内置于基础设施，否则其必须作为另外的基础设施组件进行安装、配置与管理。另外，服务注册表也是一个很关键的系统组件。尽管客户端应当对服务注册表提供的数据进行缓存，但一旦该服务注册表发生故障那么这些数据就会过期。因此，服务注册表必须有极高的可用性。
开发者需要决定各服务实例如何注册至该服务注册表。有两个选项：
- 自注册模式 - 服务实例自行完成注册。
- 第三方注册模式 - 由第三方注册工具将各服务实例注册至服务注册表。
服务注册表的客户端需要获取服务注册表实例的位置。另外，各服务注册表实例也必须被部署在固定且已知的IP地址上。各客户端则利用这些IP地址进行配置。
举例来说，Netflix Eureka服务实例通常会根据弹性IP地址进行部署。其弹性IP地址可用资源池则利用属性文件或者通过DNS进行配置。当一个Eureka实例开始启动时，它会查询配置，寻找可用的弹性IP地址。Eureka客户端也需要通过该弹性IP地址池进行配置。
相关模式
- 客户端服务发现 和 服务器端服务发现 催生了服务注册表这个模式。
- 自注册 和 第三方注册 是将服务实例注册至服务注册表的两种不同方式。