在我们服务使用 REST API 调用服务时，是需要知道服务实例的网络位置（IP 地址和端口）。
在服务器上运行的传统应用程序中服务实例的api通常是静态的。在现在基于云的微服务应用程序中，api通常不是那么简单设置。由于自动缩放、故障和升级，服务实例会动态变化。因此，我们必须在客户端代码中使用服务发现。
1、服务发现
服务的IP地址不能在客户端静态配置。需要使用动态服务发现。从概念上讲，服务发现非常简单，它的主要组件是一个服务注册表，它包含一个应用程序服务实例的网络位置列表。
当服务实例启动和停止时，服务注册表会更新。服务发现机制通过查询服务注册表以获取可用服务实例的列表，并在客户端调用服务时将请求路由到其中一个。
2、应用程序级服务发现模式
应用程序的服务及其客户端可以与服务注册中心交互以实现服务发现。每个服务实例向服务注册表注册其网络位置，在调用服务之前从服务注册中心请求服务实例列表。然后，客户端向其中一个实例发送请求。
Netflix 和 Pivotal 已经普及了企业级服务发现。例如，Netflix 的 Eureka 是一个高可用的服务注册中心。Netflix 组件可以很容易地与 Spring Cloud 一起使用，这是一个由 Pivotal 开发的基于 Spring 的框架。基于 Spring Cloud 的服务向 Eureka 注册，基于 Spring Cloud 的客户端使用 Eureka 发现服务。
3、应用层服务发现的缺点
4、平台提供的服务发现模式
许多部署平台例如 Docker 和 Kubernetes，都内置了服务注册表和服务发现机制。每个服务都分配有一个 DNS 名称、一个虚拟 IP (VIP) 地址和一个解析为 VIP 地址的 DNS 名称。
服务客户端请求 DNS 名称/VIP，部署平台自动将请求路由到可用服务实例。这样服务注册、服务发现、请求路由等全部由部署平台处理。服务注册表跟踪部署平台中已部署服务的 IP 地址。