第四篇：服务发现机制

本文出自Service Discovery in a Microservices Architecture，作者 Chris Richardson， 写于2015年5月19日

这是本系列文章的第四篇。

• 第一篇文章：介绍微服务架构并讨论了微服务架构的优点和缺点；
• 第二篇文章和第三篇文章：描述微服务之间的通信的不同方面；

本文我们继续探索与服务发现紧密联系的有关问题。

一、为什么使用服务发现？

想象一下编写代码调用REST或者Thrift API的服务，为了实现这个调用，你的代码需要知道服务实例的网络位置（IP 地址和端口）。在运行在物理硬件的传统应用中，服务实例的网络位置是相对静止的。例如，代码可以从配置文件中读取网络位置，这个配置文件偶尔会更新。

但是，在现代基于云的微服务应用中，这是非常难以解决的问题，正如图4-1显示的一样：

服务实例被动态地赋予网路位置。另外，由于自动伸缩、故障和升级，服务实例集合经常会动态改变。所以客户端代码需要使用详细设计的服务发现机制。

​ 图4-1 客户端或者API网关需要帮助发现服务

有两种主要的服务发现机制：客户端发现机制和服务端发现机制。首先来看一下客户端发现机制。

二、客户端发现模式

当使用客户端发现模式时，客户端负责确定可用服务实例的网络位置并且对通过它们的请求进行负载均衡。客户端查询服务注册中心，服务注册中心是一个可用服务实例的数据库。客户端接着使用负载均衡算法选择可用的服务实例中的一个并把这个请求路由到该实例。

图4-2显示这个模式的结构：

​ 图4-2 客户端执行服务发现的任务

当服务实例启动的时候，它的网络地址被注册到服务注册中心。当该实例终止的时候，该地址从服务注册中心移除。服务实例的注册通常使用心跳机制定期刷新。

Netflix OSS 为客户端发现模式提供了很好的例证。Netflix Eureka 是一个服务注册中心，它提