微服务、AMQP和服务注册/发现

Question

我正在学习微服务架构，有一个问题让我感到疑惑。

对于基于REST的微服务，使用（后端）服务发现来使请求方法可用是可以接受的。我们需要知道服务（或至少服务器集群的前端）在哪里，才能发出请求并得到响应。因此，在这种情况下，能够发现IP：端口是有意义的。

但是当处理基于AMQP的微服务时，使用服务注册/发现有什么目的呢？使用AMQP就像“我需要XXX，并期望有人回答我”，我不需要知道谁是发送响应的服务器。

那么，在基于AMQP的微服务中使用服务注册/发现的目的是什么？

谢谢您的帮助。

- mfrachet

---

有趣的问题。我也曾认为 MOM 的工作方式类似于服务发现功能。它提供位置透明度和弹性。MOM 就像一个服务注册表，你只需要知道服务的名称，例如交换机名称，然后 MOM 会将你的消息路由和负载均衡到其中一个服务提供者（消费者），然后给你一个答案。坦率地说，我没有理解今天唯一存在的回答中提供的要点。 - Edwin Dalorzo

Answer 1

AMQP（实际上是任何消息中间件）提供了一种进程间通信的方式，无需考虑实际 IP 地址、通信安全、路由等问题。但这并不意味着任何进程都可以信任或者了解它所通信的进程信息。

消息队列确实解决了一半的问题：如何到达远程服务。但它们没有解决另一半问题：哪个服务才是适合我的。换句话说，哪个服务：

- 拥有我需要的资源 - 可以被信任（托管在可靠的服务器上，具有令人满意的服务实现，在符合你要求的国家/地区，等等） - 收费符合预算（尽管当涉及微服务时，人们很少讨论成本） - 将在整个处理服务所需的时间窗口内保持运行 - 请记住，服务器变得越来越易失。有些服务器实际上是只能持续几分钟的容器。

这两个问题几乎是线性独立的。为了解决第二类问题，在网格计算中有资源代理。还有资源分配，以确保正确管理上面的最后一项。

还有一些替代策略，例如广播使用服务的意图并等待带有报价的回复。在这种情况下，你可能会有反向拍卖。

简而言之，经验法则是，如果你没有关于要使用哪个服务的先验知识（硬编码或在某个配置文件中），你的代理将不得不进行谈判，其中包括动态服务发现。

- Akira

---

我正在努力理解你回答中的要点。你说 MOM 将提供位置透明度、弹性和负载均衡，这些都是服务发现的关键特性。我不太明白“具有我需要的资源”或“可信任”等方面在这里可能成为问题。我可以添加许多短暂的 Docker 容器和新的消费者，它们将弹性地出现和消失。使用主题，我可以控制诸如使用最近的消费者或最便宜的消费者之类的方面，而 MOM 很可能已经提供了安全功能。如果你能再详细说明一下就太好了。 - Edwin Dalorzo

MOM将为您创建一个覆盖网络。如果您控制附加到此覆盖网络的所有进程，则可能不需要服务注册表或发现。您可以简单地创建一个协议，在其中发送广播消息询问“谁能为我做到这一点”，并信任答案。 - Akira

但问题是“在什么情况下我会从服务注册表和发现中受益”。一种可能的答案与没有先前信任所有MOM参与者有关。如果您不能或不想信任任何人，那么只能信任注册表。如果注册表建议您使用资源A，则可以与A交互。在您的例子中，似乎您控制所有参与者，因此拥有注册表将在这方面提供任何额外功能。 - Akira

但是还有其他情况下拥有注册表是有益的。其中一个主要的用例是最小化在 MOM 中循环的消息数量。您不需要广播“谁可以为我做这个”的请求。相反，您可以让每个新服务向中央注册表声明自己能够做 X 和 Y，因此如果有人需要 X 或 Y，注册表将知道推荐哪个服务。 - Akira