服务与发现

假设你正在编写一些调用具有 REST API 的服务的代码，为了发出请求，你的代码需要知道服务实例的网络位置（IP 地址和端口），在物理硬件上运行的传统应用程序中，服务实例的网络位置通常是静态的。例如，你的代码可以从偶尔更新的配置文件中读取网络位置，但在现代的基于云的微服务应用程序中，通常不那么简单，如下图所示，现代应用程序更具动态性。
云服务

服务实例具有动态分配的网络位置，此外，由于自动扩展、故障和升级，服务实例集会动态更改。因此，你的客户端代码必须使用服务发现。

什么是服务发现

正如刚才所见，你无法使用服务的 IP 地址静态配置客户端，相反，应用程序必须使用动态服务发现机制。服务发现在概念上非常简单：其关键组件是服务注册表，它是包含服务实例网络位置信息的一个数据库。

服务实例启动和停止时，服务发现机制会更新服务注册表。
当客户端调用服务时，服务发现机制会查询服务注册表以获取可用服务实例的列表，并将请求路由到其中一个服务实例。

实现服务发现有以下两种主要方式：

服务及其客户直接与服务注册表交互。
通过部署基础设施来处理服务发现。

来逐一进行分析。

应用层服务发现模式

实现服务发现的一种方法是应用程序的服务及客户端与服务注册表进行交互，服务实例使用服务注册表注册其网络位置，客户端首先通过查询服务注册表获取服务实例列表来调用服务，然后它向其中一个实例发送请求。如下图显示了它的工作原理：
应用层服务发现
这种服务发现方法是两种模式的组合。

第一种模式是自注册模式。服务实例调用服务注册表的注册 API 来注册其网络位置，它还可以提供运行状况检查 URL。运行状况检查 URL 是一个 API 端点，服务注册表会定期调用该端点来验证服务实例是否正常且可用于处理请求，服务注册表还可能要求服务实例定期调用“心跳” API 以防止其注册过期。

模式：自注册
服务实例向服务注册表注册自己。

第二种模式是客户端发现模式。当客户端想要调用服务时，它会查询服务注册表以获取服务实例的列表。为了提高性能，客户端可能会缓存服务实例，然后，服客户端使用负载平衡算法（例如循环或随机）来选择服务实例，然后它向选择的服务实例发出请求。

模式：客户端发现
客户端从服务注册表检索可用服务实例的列表，并在它们之间进行负载平衡。

应用层服务发现的一个好处是它可以处理多平台部署的问题（服务发现机制与具体的部署平台无关）。例如，想象一下，你在 k8s 上只部署了一些服务，其余服务在遗留环境中运行，在这种情况下，使用 Eureka（高可用的服务注册表）的应用层服务发现同时适用于两种环境，而基于 k8s 的服务发现仅能用于部署在 k8s 平台之上的部分服务。

应用层服务发现弊端是：

你需要为你使用的每种编程语言（可能还有框架）提供服务发现库。SpringCloud 只能帮助 Spring 开发人员，如果你正在使用其他 Java 框架或非 JVM 语言（如 Nodejs 或 GoLang），则必须找到其他一些服务发现框架。
应用层服务发现的另一个弊端是开发者需要负责设置和管理服务注册表，这会分散一定的精力。因此，最好使用部署基础设施提供的服务发现机制。

平台层服务发现模式

你将了解许多现代部署平台（如 Docker 和 k8s）都具有内置的服务注册表和服务发现机制。部署平台为每个服务提供 DNS 名称、虚拟 IP 地址和解析为 VIP 地址的 DNS 名称。客户端向 DNS 名称和 VIP 发出请求，部署平台自动将请求路由到其中一个可用服务实例。因此，服务注册、服务发现和请求路由完全由部署平台处理。如下图显示了它的工作原理：
平台层服务发现
部署平台包括一个服务注册表，用于跟踪已部署服务的 IP 地址。在此示例中，客户端使用 DNS 名称 order-service 访问 OrderService，该服务解析为虚拟IP地址 10.1.3.4。部署平台会自动在 OrderService 的三个实例之间对请求进行负载均衡。