编者按：在『应用架构一团糟?如何将单体应用改造为微服务』一文中，介绍了如何逐步地将单体应用改造为一系列的微服务。本文是系列文章的第四篇，将为大家讲述如何在微服务架构实现服务发现。作者首先介绍了服务发现的两种实现模式，接下来介绍了服务发现中最重要的服务注册如何实现。

　　作者简介：Chris Richardson是Cloudfoundry.com的创始人，现在为提供开发和部署应用的咨询服务。

　　以下为译文：

为什么使用服务发现?

　　想象一下，如果你在写代码调用一个有REST API或Thrift API的服务，你的代码需要知道一个服务实例的网络地址(IP地址和端口)。运行在物理硬件上的传统应用中，服务实例的网络地址是相对静态的，你的代码可以从一个很少更新的配置文件中读取网络地址。

　　在一个现代的，基于云的微服务应用中，这个问题就变得复杂多了，如下图所示：

　　服务实例的网络地址是动态分配的。而且，由于自动扩展，失败和更新，服务实例的配置也经常变化。这样一来，你的客户端代码需要一套更精细的服务发现机制。

　　有两种主要的服务发现模式：客户端服务发现(client-side discovery)和服务器端服务发现(server-side discovery)。我们首先来看下客户端服务发现。

客户端服务发现模式

　　当使用客户端服务发现的时候，客户端负责决定可用的服务实例的网络地址，以及围绕他们的负载均衡。客户端向服务注册表(service registry)发送一个请求，服务注册表是一个可用服务实例的数据库。客户端使用一个负载均衡算法，去选择一个可用的服务实例，来响应这个请求，下图展示了这种模式的架构：

　　一个服务实例被启动时，它的网络地址会被写到注册表上;当服务实例终止时，再从注册表中删除。这个服务实例的注册表通过心跳机制动态刷新。

　　Netflix OSS提供了一个客户端服务发现的好例子。Netflix Eureka是一个服务注册表，提供了REST API用来管理服务实例的注册和查询可用的实例。Netflix Ribbon是一个IPC客户端，和Eureka一起处理可用服务实例的负载均衡。下面会深入讨论Eureka。