什么是服务发现，为什么需要它？

Question

据我所知，“服务发现”是指客户端了解它想要连接的服务器（或服务器集群）的方法。

我构建了使用HTTP和AMQP等协议与其他后端进程通信的Web应用程序。在这些客户端中，每个客户端都有一个配置文件，其中包含主机名或连接到服务器所需的任何信息，这些信息在部署时使用Ansible等配置工具进行设置。这很简单，似乎运作得很好。

服务发现是否只是将服务器信息放在客户端的配置文件中？如果是这样，为什么它更好？如果没有，它解决了什么问题？

Answer 1

让我们首先回顾一下服务发现是什么 - 这里有一个很好的解释：https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ （这个链接应该澄清问题）

这是一个如何在实践中使用它的例子： 假设您有服务B使用的服务B.服务B（与SOA中的大多数服务一样）实际上是B类应用程序的集群。服务A需要使用集群B中的一个节点，但是B节点集群动态。即，根据整个B服务的负载，创建和终止B节点。现在，我们希望服务A在每次需要使用服务B时与实时B节点进行通信。为此，我们将使用服务发现工具向我们提供在任何给定时间，一个实时B节点的地址。

因此，尝试回答上述问题，将端点服务器信息（特别是端点地址）作为静态配置放在配置文件中，该文件在服务A启动时读取，不会给你<强>动态您希望服务B端点可能不断变化。

Answer 2

在将docker映像动态部署在任何计算机或IP +端口组合上的云环境中，相关服务在运行时难以更新。服务发现仅出于该目的而创建。

服务发现是在微服务架构下运行的服务之一，它注册在服务网格下运行的所有服务的条目。所有操作都可以通过REST API获得。因此，每当服务启动并运行时，各个服务便会向服务发现服务进行注册，并且服务发现服务会保持心跳，以确保这些服务处于活动状态。这也用于监视服务的目的。服务发现还有助于在以公平方式部署的服务之间分配请求。

Answer 3

如果您有2个微服务，例如A和B，并且您希望A与B通信，则A将使用服务发现方法（工具）在微服务体系结构中找到B。

不仅客户端到服务器的通信，而且还有可能在同一服务器上运行的2个微服务。

它解决的问题是，在集群中2个不同节点上运行的2个微服务可以彼此发现，而没有服务发现，这是不可能的。

您可以看看kurbernetes如何通过使用coreDNS的DNS支持服务发现。 https://kubernetes.io/docs/concepts/services-networking/service/

Answer 4

我必须承认您说的方法是可行的，但是如果服务太多，您需要管理的复杂性将会增加，并且手动配置服务列表也很容易出错。

服务发现不是将要调用的服务列表放入客户端配置的简单方法，而是保存所有服务本身的实例列表的方法。

您可以简单地了解我们拥有一个注册服务，该服务可以自动管理要访问的服务实例列表。添加服务或关闭服务时，注册服务将自动更新您的服务列表。呼叫时，您将从注册中心获取最新的服务清单以进行呼叫。为了不影响性能，您还可以在客户端上缓存服务列表

Answer 5

云服务器体系结构正在改变我们构建Web应用程序的方式，从单一的大型组件转变为将它们分解为越来越小的可单独部署的服务（称为微服务），一起构成了大型应用程序。

问题来了，让我们考虑一个服务要与其他服务进行通信的情况，比如说Service-A需要与Service-B进行通信。

解决方案1：使用配置文件

对于小型应用程序，我们可以在每个服务中使用带有这些服务的IP和端口的配置文件。 但是，当应用程序中的服务数量增加时：-

• 很难管理。
• 启动后无法更改服务的IP或端口
• 它无法利用云的功能根据需求动态扩展或缩小。

这种简单的方法过于静态，会冻结云，因此出现了新的解决方案

解决方案2：服务发现

服务发现通过提供一种方法来帮助解决上述问题

• 要注册服务，即，当新服务上线时，它将使用其IP和端口将其自身注册到服务发现服务中
• 帮助服务查找其他服务，即帮助服务A查找服务B
• 运行状况检查，用于检查实例的运行状况，并在状况不佳时将其删除。
• 在服务离线时注销。

因此，它有助于利用云的全部功能根据需求动态扩展和收缩，并使架构之间松散耦合