logo标签列表

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

web-servicesconfigurationarchitecturemicroservices
54
据我所知，“服务发现”是指客户端查找它想要连接的服务器（或服务器集群）的一种方式。
我已经构建了使用诸如HTTP和AMQP之类的协议与其他后端进程通信的Web应用程序。在这些应用中，每个客户端都有一个配置文件，其中包含主机名或其需要连接到服务器的任何信息，该配置文件在部署时使用像Ansible这样的配置工具进行设置。这很简单，并且似乎运作良好。
服务发现是将服务器信息放入客户端配置文件的替代方法吗？如果是，为什么更好？如果不是，它解决了哪个问题？
你使用 [tag:微服务] 不就已经回答了那个问题吗？ - jonrsharpe
7
不，我不理解服务发现是什么，如果它是我认为的那样，我也不知道微服务为什么需要它。 - gesgsklw
5个回答
41
让我们先回顾一下什么是服务发现——这里有一个很好的解释: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ （这个链接应该能够澄清所提出的问题）
以下是它在实践中的一个例子： 假设您有一个由服务A使用的服务B。服务B（像大多数SOA服务一样）实际上是类型为B的应用程序集群。服务A需要使用B集群中的一个节点，但B节点集群是动态的。即B节点根据整个B服务的负载情况而创建和终止。现在，我们希望每当服务A需要使用服务B时，它都能与一个活动的B节点通信。为了做到这一点，我们将使用服务发现工具，在任何给定时间，提供一个活动的B节点地址。
因此，试图回答您上面的问题，将终端点服务器信息（特别是终端点地址）作为静态配置放入在服务A启动时读取的配置文件中，无法提供您想要的动态性，当服务B终端点可能经常更改时。
16
为什么服务发现很重要的解释中通常包括这样一种场景：重新部署具有动态IP地址的应用程序。根据我的经验，这就是为什么你需要在你的集群前面放置一个已知CNAME的负载均衡器（例如AWS Elastic Load Balancer），它也将只路由到集群中健康的节点。那么，服务发现只是避免了使用带有CNAME的负载均衡器的成本吗？还是有其他更多的作用？ - ecoe
1
我遇到了类似的问题，也有同样的想法。根据我的阅读，ALB 可以作为服务器端服务发现，因为它可以注册和注销服务实例。我在这个答案中找到了链接，以及 https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/service-discovery.html 这个网址非常有用！ - Olly
@ecoe 我也有类似的困惑。不知道你是否已经解决了？或者能否帮我理解一下。 - Gautam
4
这个链接（https://dev59.com/ZlwY5IYBdhLWcg3wq5fl）上的问题和答案阐述了服务发现工具和负载均衡之间的核心区别。但仍然感到不太满意。 - Karuhanga
10

云服务器架构正在改变我们构建 Web 应用程序的方式，由单个大型整块转向将它们拆分为称为微服务的越来越小的可独立部署的服务，这些服务组合成一个大应用程序。

让我们考虑一下当一个服务想要与其他服务通信时的情况，比如说 Service-A 需要与 Service-B 通信。Service-A 需要知道 Service-B 的 IP 地址和端口号。解决问题的最简单方法是在 Service-A 中维护一个配置文件，其中包含指向 Service-B 的 IP 地址和端口号。但是这种方法有以下几个缺点：

  • 当应用程序中的微服务数量增加时
  • 在配置文件中管理困难
  • 当出现错误时容易出现问题
  • 缺乏以后更改 IP 或端口的灵活性
  • 不能利用云的能力根据要求动态扩展或缩小。

这种简单的方法过于静态并且使云无法发挥其作用，因此出现了新的解决方案：

备选方案：服务发现

服务发现通过提供以下方式来解决上述问题：

  • 注册服务，即当一个新的服务上线时，它会将自己的 IP 和端口注册到服务发现服务中。
  • 帮助服务发现其他服务，即帮助Service-A找到Service-B。
  • 健康检查以检查实例的状态，并在其不佳时将其移除。
  • 当服务离线时注销服务。

    • 因此，它有助于充分利用云的能力根据需求动态缩放和收缩，并使架构相互之间解耦。

    5
    在云环境中，docker镜像可以动态部署在任何机器上，IP地址和端口组合，这就使得依赖服务在运行时更新变得困难。因此，服务发现应运而生。
    服务发现是微服务架构下运行的一种服务，它注册了服务网格下所有服务的条目。所有操作都可通过REST API访问。因此，当服务启动并运行时，各个服务将自己注册到服务发现服务，而服务发现服务则通过心跳检测确保这些服务仍然存活。这也有助于监视服务。服务发现还有助于公平地分发请求到部署的服务中。
    4

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

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

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

    2
    如果您有两个微服务，比如A和B，且您想让A与B通信，那么在微服务架构中，A将使用服务发现方法（工具）来查找B，这不仅适用于客户端与服务器之间的通信，还适用于可能在同一服务器上运行的两个微服务。它解决的问题是在集群中运行的两个不同节点上的两个微服务可以相互发现，如果没有服务发现，这将是不可能的。您可以查看kubernetes如何支持服务发现，例如通过使用coreDNS的DNS。 https://kubernetes.io/docs/concepts/services-networking/service/
    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接