由于微服务应用的动态性，很难调用具有固定 IP 地址的服务。这就是服务发现的概念出现的背景。服务发现有助于客户端了解服务实例的位置。在这种情况下，服务发现组件将充当服务注册表。
服务注册表 是一个包含服务实例位置的集中式服务器/数据库。在微服务设置中，服务会定期更新其在服务注册表中的位置。然后服务使用者可以连接到服务注册表并获取这些服务的位置。Netflix Eureka[1] 是一种流行的"应用级"开源服务注册表。
在服务发现中，有两种模式。
1.客户端端服务发现2.服务器端服务发现
客户端端服务发现
这涉及多个步骤。
图 01 --- 客户端端服务发现
1.将服务提供者实例的位置添加到服务注册表（自注册模式）。2.当服务消费者想要请求特定服务时，服务发现机制将查询服务注册表以获取可用服务提供者实例位置的列表。3.在从服务注册表中获取位置列表后，将其发送回服务消费者。4.最后，服务消费者将路由服务请求到其中一个服务提供者实例。
自注册模式
在自注册模式中，服务实例会在启动时向服务注册表注册自己（见图 01 --- 步骤 01）。这会在服务注册表上发生，并且在关闭时取消注册。
服务实例可能会调用服务注册表的注册 API 来注册其网络位置。除此之外，服务注册表还会调用服务提供者实例的健康检查 API。
模式 2：服务器端服务发现模式
与客户端端服务发现模式不同，服务器端服务发现模式中，服务客户端会发出对 DNS 名称的请求，该名称会解析为查询服务注册表并负载均衡请求的平台请求路由器。
这种模式的主要优点是，与客户端端发现模式不同，服务发现的所有方面都完全由部署平台处理。这对于任何开发方来说都是一个主要优势和一个无忧无虑的方法。部署平台（例如 Kubernetes）具有内置的服务注册表和服务发现机制，以覆盖服务器端发现模式。
这种方法的唯一限制是，您会稍微耦合到用于服务注册表的部署平台上。例如，如果您使用 Kubernetes 作为部署平台，那么您基本上与 Kubernetes 耦合，以用于服务发现。如果您的其他服务组件也在 Kubernetes 上运行，这将不是问题。然而，如今大多数部署都在云原生 Kubernetes 容器化环境中进行，这不是一个主要限制。
图 02 --- 服务器端服务发现模式
这涉及多个步骤。
1.服务实例通过 registrar（第三方注册模式）向服务注册表注册。2.服务客户端从 Router 获取服务网络位置，并 Router 从服务注册表查询请求。3.然后 Router 从可用的服务提供者实例中负载均衡请求。
第三方注册模式
在第三方注册模式（见图 02 --- 步骤 02）中，与服务注册表的自注册不同，一个称为 registrar 的第三方负责注册。
引用链接
[1] Netflix Eureka: https://github.com/spring-cloud/spring-cloud-netflix