经成为一个独立的顶级项目。
另外，如之前所述，部分系统，如 Kubernetes、Marathon 和 AWS，没有明确的服务注册中心。相反，服务注册中心只是基础设施的一个内置部分。
现在我们已经了解服务注册中心的概念，接下来让我们看看服务实例是如何被注册到服务注册中心。
4.5、服务注册方式
如之前所述，服务实例必须在服务注册中心中注册与注销。有几种不同的方式来处理注册和注销。一是服务实例自我注册，即自注册模式。另一个是使用其他系统组件来管理服务实例的注册，即第三方注册模式。我们先来了解自注册模式。
4.6、自注册模式
当使用自注册模式时，服务实例负责在服务注册中心注册和注销自己。此外，如果有必要，服务实例将通过发送心跳请求来防止其注册信息过期。
图 4-4 展示了该模式的结构。
该方式的一个很好的范例就是 Netflix OSS Eureka 客户端。Eureka 客户端负责处理服务实例注册与注销的所有方面。实现了包括服务发现在内的多种模式的 Spring Cloud 项目可以轻松地使用 Eureka 自动注册服务实例。您只需在Java Configuration类应用 @EnableEurekaClient 注解即可。
自注册模式有好有坏。一个好处是它相对简单，不需要任何其他系统组件。然而，主要缺点是它将服务实例与服务注册中心耦合。您必须为服务使用的每种编程语言和框架都实现注册代码。
将服务与服务注册中心分离的替代方法是第三方注册模式。
4.7、第三方注册模式
当使用第三方注册模式时，服务实例不再负责向服务注册中心注册自己。相反，该工作将由被称为服务注册器（service registrar）的另一系统组件负责。服务注册器通过轮询部署环境或订阅事件来跟踪运行实例集的变更情况。当它检测到一个新的可用服务实例时，它会将该实例注册到服务注册中心。此外，服务注册器可以注销终止的服务实例。
图 4-5 展示了该模式的结构：
服务注册器的一个例子是开源的 Registrator 项目。它可以自动注册和注销作为 Docker 容器部署的服务实例。注册器支持多个服务注册中心，包括 etcd 和 Consul。
服务注册器的另一个例子是 NetflixOSS Prana。其主要用于非 JVM 语言编写的服务，它是一个与服务实例并行运行的侧中应用。Prana 使用了 Netflix Eureka 来注册和注销服务实例。
服务注册器在部分部署环境中是一个内置组件。Autoscaling Group 创建的 EC2 实例可以自动注册到 ELB。Kubernetes 服务将自动注册并提供发现。
第三方注册模式同样有好有坏。一个主要的好处是服务与服务注册中心之间解耦。您不需要为开发人员使用的每种编程语言和框架都实现服务注册逻辑。相反，仅需要在专用服务中以集中的方式处理服务实例注册。
该模式的一个缺点是，除非部署环境内置，否则您同样需要引入这样的一个高可用的系统组件，并进行设置和管理。
4.8、总结
在微服务应用程序中，运行的服务实例集会动态变更。实例具有动态分配的网络位置。因此，为了让客户端向服务发出请求，它必须使用服务发现机制。
服务发现的一个关键部分是服务注册中心。服务注册中心是一个可用服务实例的数据库。服务注册中心提供了管理 API 和查询 API 的功能。服务实例通过使用管理 API 从服务注册中心注册或者注销。系统组件使用查询 API 来发现可用的服务实例。
有两种主要的服务发现模式：客户端发现与服务端发现。在使用了客户端服务发现的系统中，客户端查询服务注册中心，选择一个可用实例并发出请求。在使用了服务端发现的系统中，客户端通过路由器进行请求，路由器将查询服务注册中心，并将请求转发到可用实例。
服务实例在服务注册中心中注册与注销有两种主要方式。一个是服务实例向服务注中心自我注册，即自注册模式。另一个是使用他系统组件代表服务完成注册与注销，即第三方注册模式。
在某些部署环境中，您需要使用如 Netflix Eureka 或 Apache ZooKeeper 等服务注册中心来设置您自己的服务发现基础设施。在其他部署环境中，服务发现是内置的，例如，Kubernetes 和 Marathon，可以处理服务实例的注册与注销。他们还在每一个扮演服务端发现路由器角色的集群主机上运行一个代理。
一个 HTTP 反向代理和负载均衡器（如 NGINX）也可以用作服务端发现负载均衡器。服务注册中心可以将路由信息推送给 NGINX，并调用一个正常的配置更新；例如，您可以使用 Consul Template。NGINX Plus 支持额外的动态重新配置机制 - 它可以使用 DNS 从注册中心中提取有关服务实例的信息，并为远程重新配置提供一个 API。
微服务实战：NGINX 的灵活性
by Floyd Smith
在微服务环境中，由于自动扩展、故障和升级，您的后端基础设施可能会不断变化，这些包括了服务的创建，部署和扩展。如本章所述，在动态重新分配服务位置的环境中需要服务发现机制。
将 NGINX 应用于微服务的一部分好处是，您可以轻松地将其配置为自动响应后端基础设施作出的变更。NGINX 配置不仅简单灵活，而且兼容 Amazon Web Services 使用的模板，可以更轻松地管理特定的服务变更与受负载均衡的变更服务组。
NGINX Plus 具有即时重新配置 API，无需重新启动 NGINX Plus 或手动重新加载配置就能感知受负载均衡服务组的变更。在 NGINX Plus Release 8 及更高版本中，您可以将对 API 所做的更改配置为在重新启动和配置重新加载时保持不变。（重新加载不需要重新启动，不要断开连接）NGINX Plus Release 9 及更高版本支持使用 DNS SRV 记录进行服务发现，可与现有服务器发现平台（如 Consul 和 etcd）进行更紧密地集成。
我们在 NGINX 创建了一个用于管理服务发现的模型：
- 为几个应用程序单独运行的Docker容器，包括如 etcd 的服务发现应用程序、服务注册工具、一个或多个后端服务器以及用于负载均衡其他容器的 NGINX Plus 本身。
- 注册工具监控 Docker 的新容器，并使用服务发现工具注册新服务，此外，还可以删除消失的容器。
- 容器及其运行的服务将自动添加到负载均衡上游服务器中或从其中删除。
此 Demo 应用程序可用于多个服务发现应用程序：Consul API、来自 Consul 的 DNS SRV 记录、etcd 以及 ZooKeeper 等。
本系列全部译文
相关链接