微服务架构的服务发现设计形式
在咱们服务经常使用 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 地址。
