微服务REST或AMQP，在这种情况下

我读过许多有关微服务体系结构的文章，我想知道何时使用AMQP或REST。

我读到服务之间的松耦合是一件好事，在这种情况下，AMQP似乎是一个不错的选择。但是，如果我们使用AMQP，则意味着我们不再需要REST端点（但这意味着我们将失去HATEOAS概念）。

但是REST真的是构建我的服务的好方法吗？原因我将不使用任何端点...在这种情况下，一个端点比另一个端点更好？

什么时候应该使用其中一个？

通过丢弃REST，您损失的不仅是HATEOAS。如果您的微服务是公开的（对它们来说是一个好主意，或者至少有一天倾向于公开公开¹），那么使用除REST和SOAP之外的任何其他方法都会有问题：

• 有些开发人员从未使用过AMQP，

• 有些使用过AMQP，但通常对REST和SOAP更为熟悉，

• 某些语言的AMQP库不是特别简单，

• 对该服务的手动实验非常有限：我可以使用CURL向Amazon S3发出任何请求；如果要使用S3的AMQP变体，应该在机器上安装什么？

• 调试REST和SOAP很容易。我只是跟踪HTTP交换并进行分析。不知道我应该使用什么工具来调试AMQP交换。

AMQP很棒，但是这样做是出于基于事件的交流的非常特定的目的。尽管从技术上讲可以使用AMQP进行RPC，但这并不是其主要目的。

异步方面也很重要。有时这是一个好处：我不想在向服务器发送请求时阻止应用程序的用户界面。有时候，这只会使事情变得比他们需要的难：如果由于本地S损坏，我需要从Amazon S3恢复文件备份，然后还原备份，则我的批处理文件必须需要CURL才能完成其工作，然后再继续，同步操作（具有特定的超时）非常合理。

为主要操作保留REST：

• 获得产品

• 储存发票

并使用AMQP进行实际上有意义的任务：

• 处理9月份以来的所有发票，并在准备好显示报告时通知应用程序（假设操作通常需要2到10分钟），

  ^{AMQP的好处在于它的异步方面。等待十分钟的HTTP请求很有可能引起超时和其他问题。}

• 向可能感兴趣的每个人分发备份已损坏的信息，例如支持人员，数据库管理员，监视团队，使用此数据库的应用程序的开发人员等。

  ^{AMQP的好处是，无需更改应用程序即可添加订户，该应用程序会跟踪备份并在发现损坏的备份时触发警报。}

^{¹公司外部的用户不一定使用公共Web服务。在大中型公司中，您的服务通常由同一公司的其他部门使用，并且具有与任何第三方都会使用的要求相同的要求：它应该不信任任何呼叫（事实上，您从来没有某个人听说谁打电话给您的服务与您在同一家公司工作并不意味着他不会利用其安全性问题），应该妥善记录（因为同一印度人不一定知道您的电话号码，也不一定会英语），等等。}

同时使用。

REST风格的JSON Web服务非常适合与javascript，ios等实现互操作性

AMQP非常适合长时间运行的流程，事件和微服务的编排。

但是两者都只是实际服务的通信包装，您可以以多种方式公开同一服务，并且可能应该公开。

AMPQ可以很好地通过Websockets公开，如果斜视它，它看起来很像REST端点。

REST是一种标准技术，特别适合组件之间的互操作性-这是关键部分，对于制作其他人可以使用的Web服务非常有用。但是，它具有这种互操作性的常见问题，因为它的效率不如自定义协议。

如果您正在编写仅由您自己使用服务的后端体系结构，那么您可以使用任何您喜欢的协议-您不再受使用如此可互操作的协议的束缚。您可以使用MQ或更紧密耦合的性能。使用哪种消息取决于您的用例，消息总线非常适合用于处理数据的分布式服务集，而客户端不在乎客户端是谁来接收发送的消息。

AMQP还支持点对点通信（例如，请参阅python-qpid-proton教程）。从REST !=HTTP开始，您可以使用该接口实现RESTful接口。

AMQP的性能也比HTTP好很多。