微服务和低延迟传输

Question

在微服务领域，我只知道两种流行的传输协议：REST / HTTP和AMQP。

我感觉到两个问题：

1） 你不觉得他们很慢吗？如果您不同意这种说法（是的，是的，我没有关于AMQP的基准，尽管HTTP被普遍认为是慢速的，您可以在互联网文章中找到我的帮助），那么我可以告诉您的是， 2您总是可以想象没有出现许多更快的协议。 2是一个很小的数字，实际上意味着-别无选择。

2） HTTP似乎不打算用作服务器到服务器的协议，但是在该角色中被广泛使用。

您对此有何看法，能否提出一些替代方案（在框架的支持下，我的意思是我自己不需要从头开始编写）？

Answer 1

这一切都取决于您的域方案，其要求以及为降低延迟，减小带宽等，您可以在开发中投入多少资金。

如今，服务器通讯的选择范围很广。 Https恰好是最常见的一种，对于许多应用程序来说已经足够好了。

鉴于通信的两端都处于受控状态，没有什么可以阻止您投入更多的精力并基于UDP套接字构建自己的二进制协议，甚至在OSI层中甚至更低。例如，谷歌正在使用QUIC，并提出使其成为http / 2的后继者。因此，http / 3实际上可能会变得更有效率。

或者您可以尝试实施针对延迟甚至实时应用程序进行了更优化的现有标准。工业领域的一个示例是profinet。

很多时候，有效载荷是造成缓慢连接的原因。 JSON是这种格式的一个很好的例子，这种格式需要大量时间进行大量反序列化/序列化。为了改善这一点，您可以使用其他运输格式，例如游戏领域的flat buffers（另一项Google发明）。

通常，如果您对游戏中的网络连接方式进行了一些研究，则会发现很多有趣的技术。

Answer 2

首先，请从实现主题中分离出架构主题。一方面是架构，另一方面是实现。微服务架构正在谈论SOA中的新范例。现在，在实施阶段，您可以使用多种协议来实施微服务规模服务。您可以使用UDP，TCP，HTTP等。 HTTP协议广泛用于存在诸如无状态之类的某些担忧的微服务中，这并不一定意味着在实现阶段所有微服务都需要使用HTTP。他们可能/可以使用HTTP或其他任何传输协议，例如UDP，甚至CoAP。

以下是在代码项目中发布的有关微服务的一系列文章，您可以根据需要阅读并评论您的问题。

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-I

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-II

https://www.codeproject.com/Articles/1264113/Dive-into-Microservices-Architecture-Part-III