3.2 KiB
4、服务发现
本书主要介绍如何使用微服务来构建应用程序，现在是第四章。第一章已经介绍了微服务架构模式，并讨论了使用微服务的优点与缺点。第二章和第三章介绍了微服务间通信，并对不同的通信机制作出对比。在本章中，我们将探讨服务发现相关的内容。
4.1、为何使用服务发现
我们假设您正在编写某些代码，这些代码调用了有 REST API 或 Thrift API 的服务。为了发送一个请求，您的代码需要知道服务实例的网络位置（IP 地址与端口）。在运行于物理硬件上的传统应用中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。
然而，在现代基于云的微服务应用中，这是一个更难解决的问题，如图 4-1 所示。
服务实例具有动态分配的网络位置。此外，由于自动扩展、故障与升级，整组服务实例会动态变更。因此，您的客户端代码需要使用更精确的服务发现机制。
有两种主要的服务发现模式：客户端发现与服务器端发现。让我们先来看看客户端发现。
4.2、客户端发现模式
当使用客户端发现模式时，客户端负责确定可用服务实例的网络位置和请求负载均衡。客户端查询服务注册中心，它是可用服务实例的数据库。之后，客户端利用负载均衡算法选择一个可用的服务实例并发出请求。
图 4-2 展示了该模式的结构
服务实例的网络位置在服务注册中心启动时被注册。当实例终止时，它将从服务注册中心中移除。通常使用心跳机制周期性地刷新服务实例的注册。
Netflix OSS 提供了一个很好的客户端发现模式示例。Netflix Eureka 是一个服务注册中心，它提供了一个用于管理服务实例注册和查询可用实例的 REST API。Netflix Ribbon 是一个 IPC 客户端，可与 Eureka 一起使用，用于在可用服务实例之间使请求负载均衡。本章稍后将讨论 Eureka。
客户端发现模式有各种优点与缺点。该模式相对比较简单，除了服务注册中心，没有其他移动部件。此外，由于客户端能发现可用的服务实例，因此可以实现智能的，特定于应用程序的负载均衡决策，比如使用一致性哈希。该模式的一个重要缺点是它将客户端与服务注册中心耦合在一起。您必须为服务客户端使用的每种编程语言和框架实现客户端服务发现逻辑。
现在我们已经了解了客户端发现，接下来让我们看看服务器端发现。