共计 1435 个字符，预计需要花费 4 分钟才能阅读完成。
在咱们服务应用 REST API 调用服务时，是须要晓得服务实例的网络地位（IP 地址和端口）。
在服务器上运行的传统应用程序中服务实例的 api 通常是动态的。在当初基于云的微服务应用程序中，api 通常不是那么简略设置。因为主动缩放、故障和降级，服务实例会动态变化。因而，咱们必须在客户端代码中应用服务发现。
1、服务发现
服务的 IP 地址不能在客户端动态配置。须要应用动静服务发现。从概念上讲，服务发现非常简单，它的次要组件是一个服务注册表，它蕴含一个应用程序服务实例的网络地位列表。
当服务实例启动和进行时，服务注册表会更新。服务发现机制通过查问服务注册表以获取可用服务实例的列表，并在客户端调用服务时将申请路由到其中一个。
2、应用程序级服务发现模式
应用程序的服务及其客户端能够与服务注册核心交互以实现服务发现。每个服务实例向服务注册表注册其网络地位，在调用服务之前从服务注册核心申请服务实例列表。而后，客户端向其中一个实例发送申请。
这种办法是两种模式的组合。
自注册模式：在启动期间，服务实例调用注册核心的注册 API 来注册其网络地位，注册核心要求服务实例定期调用心跳 API 以避免其注册过期。当服务实例敞开时，它会从服务注册表中登记本人。
客户端发现模式：为了调用服务，服务客户端向服务注册核心查问服务实例列表。客户端应用负载平衡算法来抉择服务实例，而后由客户端申请选定的实例。
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 地址。
这种办法是两种模式的组合：
第 三 方注册模式：不是服务向服务注册核心注册本人，而是由第三方注册商（通常是部署平台的一部分）进行注册。注册器在启动时向服务注册核心注册服务实例。当实例敞开时，注册器会从服务注册表中勾销注册服务实例。
服务器端发现模式：它不是客户端查问服务注册表，而是向 DNS 名称发出请求，DNS 名称解析为查问注册表并负载平衡申请的申请路由器。AWS 弹性负载均衡器 (ELB) 是服务器端发现路由器的一个示例。客户端向 ELB 发送 HTTP/TCP 申请，ELB 在一组 EC2 实例之间对流量进行负载平衡。ELB 还充当服务注册表。实例通过 API 调用显式注册到 ELB，或者作为主动扩大组的一部分主动注册。
5、基于平台的服务发现的益处
部署平台解决服务发现的所有工作。
服务和客户端都不蕴含任何用于服务发现的代码。
服务发现对所有服务和客户端都可用，无论它们是用什么语言编写的。
6、基于平台的服务发现的毛病
只能发现已应用该平台部署的服务。
