用 RSocket 解决响应式服务之间的通讯

分布式系统中的通讯问题

确实，微服务无处不在。从部署和维护非常麻烦的单体应用程序到完全分布式、微型、可扩展的微服务，我们经历了漫长的过程。微服务架构设计有很多好处。但是，它也有缺点。首先，为了向客户交付最终产品，服务之间必须交换大量数据。在单体应用程序中这不是问题，因为它整个通信都在单个 JVM 进程中进行。而在“微服务架构”中，部署在单独的容器中服务需要通过内部或外部网络进行通信。此时，“网络”是一等公民。如果在云上运行应用程序，事情将变得更加复杂。在这种情况下，网络问题和延迟增加将是不可避免的事情。与其尝试解决网络问题，不如设计具有弹性的体系结构，让其即使在网络抖动的情况下也能完全正常运行，这样岂不是更好。

我们来更深入地研究下微服务、数据、通信和云的概念。试想一下，对于一般的企业级系统，外部可以通过网站和移动 App 访问，或者通过小型外部设备（如家用加热控制器）与其进行交互。这些系统都是由多个微服务组成，这些微服务大多数是用 Java 编写的，其中一小部分是 Python 和 node.js 实现的组件，另外，为了确保整个系统高度可用，所有服务之间的传输数据都需要跨多个可用区进行复制备份。

IaaS 层是不可控的，为了改善开发人员体验，一般需要将应用程序运行在 PaaS 平台之上。对于 PaaS 平台，我们可以选择：Cloud Foundry，Kubernetes 或两者结合使用都是可行的。在服务之间的通信方面，设计比较简单，每个组件都暴露普通的 REST API，如下图所示。

乍一看，组件都被分散在云中运行，这样的体系结构看起来还不错。额，它可能出什么问题？主要有两个问题：它们都与通讯有关。

第一个问题是 HTTP 的请求/响应交互模型。尽管使用 HTTP 的案例有很多，但它并不是为机器之间的通信而设计的。微服务在不关心操作结果的情况下将某些数据发送到另一个组件是很常见的（即发即弃），或者在数据可用时自动流传输数据（数据流）。使用 HTTP 请求/响应交互模型难以用优雅、有效的方式实现这些交互模式。例如，在使用请求/响应交互模型时，执行简单的即发即弃操作也会产生副作用，会出现即使客户端对处理响应不感兴趣，服务器也必须将响应发送回客户端的问题。

第二个问题是性能。假设我们的系统被客户大量使用，流量增加了，并且我们注意到我们正在努力处理每秒数百个请求。借助容器和云，我们可以轻松扩展我们的服务；但是，如果我们关注下资源消耗的情况，则会发现一些问题。例如，当机器内存会出现不足时，可能 VM 的 CPU 还几乎处于空闲状态。这个问题主要来自于使用 HTTP 1.x 协议通常处理每个请求需要一个线程，致使每个请求都存在堆栈内存。在这种情况下，我们可以利用反应式编程模型和非阻塞 IO。它将在在不增加延迟的情况下大大减少内存使用量。 HTTP 1.x 是基于文本的协议，因此与二进制协议相比，需要传输的数据大小显著增大。

在机器之间的通信中，我们不应将自己局限于 HTTP（尤其是 1.x 版本，请求/响应交互模型以及性能低下）。在市场上还有许多更合适、更强大的解决方案。例如，基于 RabbitMQ、gRPC 或者 HTTP 2（支持多路复用和二进制化负载）进行信息传输在性能和效率方面会比纯 HTTP 1.x 更好。

在给定场景下，使用多种协议可以使我们最有效、最合适地连接微服务；但是，采用多种协议迫使我们一次又一次地重新发明轮子，另外，为了保证保证通讯的安全性，我们不得不用安全性相关的额外信息来丰富我们的数据；并且还需要创建多个适配器来处理协议之间的转换。在某些情况下，数据传输可能需要依赖外部资源（代理、服务等），这些服务必须高度可用。因此，尽管我们所需要的只是基于消息的简单“即发即弃