微服务与套接字的服务间通信

Question

我目前正在为以下场景设计一个系统：数据从客户端流式传输，由多个服务依次处理（无并行）。然后，在分析数据时将数据传输回客户端。重要的是，服务器将在此过程中向客户端返回部分分析的数据（这就是我需要套接字的原因）。

客户端甚至可以在服务器分析过程中发送更多信息，这可能会影响分析结果。

我制作的高级草图

我对此进行了大量研究，并且只看到了REST 微服务或使用各种消息队列的套接字的异步处理。我还没有见过任何人在服务之间直接使用如此多打开的套接字来实现微服务。

现在我的问题是：我在这里做的事情正确吗？在我的所有服务器之间打开套接字是否错误或不可靠？

Answer 1

这是一个非常广泛的问题，所以我将尝试向您提供一些广泛的想法：

首先，我认为总体思路是非常好的。所有微服务都以一种方式使用套接字，您只是将其降低到较低的级别，而无需在顶部进行各种抽象。这是有道理的，特别是如果您有一些非常具体的要求。

插座的数量对我来说似乎并没有那么大。十年前我就见过系统维护着数千个并发的打开套接字。您的建议在现代硬件和操作系统上似乎微不足道。

所以总体来说，这个设计是完全可行的。但问题是你将被迫一路上重新发明一些轮子。我会提到其中的一些。

首先，您需要微服务的服务发现来找到彼此。

然后，您需要在每对服务之间设计一个协议 - 您需要指定消息以及发送消息的时间和方式的规则。你需要消息构建器和解析器；以及处理各种消息错误的逻辑以及前向/后向兼容性。这比听起来更棘手，尤其是在通信必须稳定的情况下。这让我想到了下一点——处理网络故障。

什么网络故障？TCP是可靠的，对吗？嗯，不完全是。首先，存在断开连接和各种网络错误。然后，会出现一些安静的故障 - 尝试打开远程计算机的套接字，然后突然拔掉其网络电缆。本地socket需要多长时间才会抛出异常？好吧，事实证明，可能需要几分钟，几分钟，在此期间您的本地套接字认为删除机器处于活动状态并且运行良好。当然，如果数据到达，那么它就不会出现错误并且按正确的顺序到达。但那只是当它到来的时候。

然后是线程。虽然线程并不是纯套接字所独有的，但在较低的抽象级别上线程往往会更加痛苦。

因此，虽然可以做到，但您可能希望尽量避免在这里重新发明一些轮子。例如，使用RPC库怎么样？它们适用于所有现代语言，并且已经解决了您必须处理的一些问题。