微服务服务注册中心注册和发现

Posted 2023-03-08

【中文标题】微服务服务注册中心注册和发现

【英文标题】：Microservices service registry registration and discovery

【发布时间】：2015-09-08 19:58:40

【问题描述】：

小域介绍

我实际上有两个微服务：

用户 - 管理用户的 CRUD 帐单 - 管理帐单上的 CRUD，并带有与帐单相关的用户的“参考”

说明

当在 HTTP 请求中调用计费时，我需要发送加载了用户的完整计费对象。在那种情况下，在这种特殊情况下，我真的需要这个。

我第一次环顾四周，似乎使用消息队列是一个好主意，因为异步性，所以计费服务可以在队列上发送：

“id 为 123456 的用户是谁？我需要加载它”

所以我的两个服务可以交换，而不需要真正了解对方，或者不知道对方的“位置”。

问题

我的第一个问题是，在这种情况下使用服务注册表的目的是什么？消息队列能够在不知道任何关于用户服务位置的情况下给我们提供信息？

我们什么时候需要使用服务注册： 在聚合器模式的情况下，使用 RESTFul API，我们可以浏览 hatoas 链接。在代理模式的情况下可能吗？当微服务被另一个服务接口时？

现在承认，我们使用代理模式，带有“前端服务”。在这种情况下，我可以使用服务注册。但这意味着前端发送服务知道服务注册中的用户服务和计费服务的名称吗？示例：

服务用户注册为“UserServiceOfHell:http://80.80.80.80/v1/” 在 ZooKeeper 上

Service Billing 注册为“BillingService:http://90.90.90.90/v4.3/”

前端服务需要向用户和计费服务发送一些请求，这意味着它需要知道用户服务是“UserServiceOfHell”。这是在项目开始时定义的吗？

最后一个问题，我们可以在一个微服务架构中使用多个微服务模式还是一种不好的做法？

注意：我所问的一切都是基于http://blog.arungupta.me/microservice-design-patterns/

【参考方案1】：

很多好问题！

首先，我想回答您的最后一个问题 - 当您知道自己在做什么时，可以使用多种模式。混合异步队列、HTTP 调用甚至二进制 RPC 都很好——这取决于一致性、可用性和性能要求。有时您可以看到非常适合简单的 PubSub，有时您需要分布式锁 - 微服务是不同的。

你的例子很简单：两个微服务需要交换一些信息。您选择了异步队列 - 很好，在这种情况下，他们并不真的需要了解彼此。队列不期望消费者之间有任何发现。

但在其他情况下我们需要服务发现！例如，支持服务：数据库、缓存和实际上也是队列。如果没有服务发现，您可能会将 URL 硬编码到队列中，但如果它出现故障，您将一无所有。您需要具有高可用性 - 例如，复制队列的节点集群。当您添加新节点或现有节点崩溃时 - 您不应更改任何内容，服务发现工具应了解这一点并更新注册表。

Consul 是一个完美的现代服务发现工具，您可以使用自定义 DNS 名称来访问您的支持服务，Consul 将执行持续的健康检查并保持您的集群健康。

同样的规则可以应用于微服务——当你有一个运行服务 A 的集群并且你需要从服务 B 访问它而不需要任何队列（例如，对于 HTTP 调用）你必须使用服务发现来确保您使用的端点会将您带到健康节点。因此，它非常适合您提到的文章中的聚合器或代理模式。

最令人困惑的原因可能是您在 Zookeeper 中看到“硬编码”的 URL。你认为你需要手动管理它。像 Consul 或 etcd 这样的现代工具可以让你避免这种头痛，只需要依赖它们即可。实际上，使用 Zookeeper 也可以实现，但需要更多时间和资源才能进行类似的设置。

PS：请记住微服务中最重要的规则 - http://martinfowler.com/bliki/MonolithFirst.html