Rest 微服务、amqp和服务注册/发现

我在研究微服务体系结构，实际上我在想一些事情

我完全同意使用（后台）服务发现在基于REST的微服务上实现请求。我需要知道发出请求的服务（或者至少是服务器集群的前端）在哪里。因此，在这种情况下，能够发现ip:端口是有意义的

但我想知道在处理AMQP（仅基于，没有HTTP可能的调用）时使用ServiceRegistry/discovery的目的是什么

我的意思是，使用AMQP就像“我需要它，我希望有人回答我”，我不需要知道谁是给我回复的服务器

那么，将服务注册/发现与基于AMQP的微服务结合使用的目的是什么

感谢您的帮助

AMQP（实际上是任何MOM）为流程提供了一种通信方式，而无需考虑实际IP地址、通信安全性、路由等问题。这并不一定意味着任何流程都可以信任，或者甚至拥有与之通信的流程的任何信息

消息队列解决了流程的一半：如何到达远程服务。但他们无法解决另一半问题：哪种服务适合我。换句话说，哪种服务：

• 有我需要的资源吗
• 可信任（托管在可靠的服务器上，具有令人满意的服务实施，位于当地法律符合您要求的国家/地区等）
• 收取您想要支付的费用（尽管人们很少讨论微服务的成本）
• 在处理您的服务所需的整个时间窗口内，您都会看到它——请记住，服务器正变得越来越不稳定。有些服务器实际上是可以持续几分钟的容器

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

有一些替代策略，例如多播使用服务的意图和等待回复。例如，在这种情况下，您可能会进行反向拍卖

---

简而言之，经验法则是，如果您对要使用的服务（硬编码或在某些配置文件中）没有先验知识，那么您的代理将不得不进行协商，其中包括动态服务发现。

有趣的问题。我还认为MOM的工作方式类似于服务发现功能。它提供位置透明度和弹性。MOM就像一个服务注册中心，您只需要知道服务的名称，例如exchange名称，MOM将您的消息路由和负载平衡到其中一个服务提供商（消费者），然后为您提供答案。坦白地说，我没有得到今天唯一答案中提供的分数。我正在努力理解你答案中的分数。您可以看到MOM将提供位置透明性、弹性和负载平衡，这是服务发现的关键特性。我不太明白“有我需要的资源”或“可以信任”等可能是这里的一个问题。我可以为新的消费者添加尽可能多的短暂的docker容器，他们会弹性地来来去去去。使用主题，我可以控制一些方面，比如使用最接近的消费者或最便宜的，而MOM很可能已经提供了安全功能。如果你能再详细一点，我相信妈妈会为你创建一个覆盖网络。如果您控制连接到此覆盖网络的所有进程，则可能不需要service registry或discovery。您可以简单地创建一个协议，在该协议中发送广播消息，询问“谁能为我做这件事”并相信答案。但问题是“在何种情况下，我将受益于服务注册和发现”。一个可能的答案是，事先不信任所有MOM参与者。如果您不能或不想信任任何人，您可以只信任注册表。如果注册中心建议您使用资源A，那么您可以与A进行交互。在您的示例中，似乎您控制了所有参与者，因此注册中心不会在这方面提供任何附加功能。但在其他使用情况下，注册中心是有益的。一个主要的方法是尽量减少你妈妈传递的信息量。您不需要广播“谁能为我做这件事”的请求。相反，您可以让每个新服务向一个中央注册中心声明自己，说“我可以做X和Y”，这样，如果有人想要X或Y，注册中心就会知道推荐哪种服务。