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

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

云服务器架构正在改变我们构建Web应用程序的方式，我们正在将这些应用程序从单个大型单块体转移到将大型应用程序中称为微服务的越来越小的可单独部署的服务中。

问题就出现了，让我们考虑服务想要与其他服务进行通信的场景，假设Service-A需要与Service-B进行通信。

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

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

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

这种简单的方法过于静态并冻结了云。因此，这是一个新的解决方案

解决方案2：服务发现

服务发现通过提供方式有助于解决上述问题

• 要注册服务，即当新服务变为在线时，它会使用其IP和端口将自身注册到服务发现服务
• 帮助服务找到其他服务，即帮助Service-A找到Service-B
• 运行状况检查以检查实例的运行状况，并在不正常时将其删除。
• 要在服务脱机时取消注册。

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

Answer 3

如果您有2个微服务，比如A和B，并且您希望A与B通信，A将使用服务发现方法（工具）在微服务架构中查找B.

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

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

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

Answer 4

我必须承认你说的方法是可行的，但如果有这么多服务，你需要管理的复杂性会增加，手动配置服务列表也非常容易出错。

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

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