springwebflux mysql_Spring WebFlux的明显陷阱 - ŁukaszKyć

几个月前，我们开始了一个新项目。我们的目标是设计一个可以处理许多并发连接的微服务。我们预测该应用程序将花费大量时间等待多个并行I / O操作。理想的体系结构解决方案似乎使用了非阻塞方法。经过简短的调查，我们决定使用Spring WebFlux作为主要框架。这是因为它基于无阻塞堆栈，具有出色的可伸缩性和灵活性。流stream形式的出色抽象看起来真的很方便使用，远比基于Java NIO或Netty的传统非阻塞代码要好得多。这就是为什么我们尝试基于Spring WebFlux实施该服务的原因。但是，一旦我们的开发工作开始，麻烦便随之而来。

新思维

如果您习惯于以传统的顺序方式编写代码，则可能会感到有些迷茫。那是我们开始该项目时的印象。有时候，简单的事情似乎很困难。最令人惊讶的是，即使是经验丰富的Java开发人员也不得不重新发明轮子。对于他们来说，这是一个新的编程范例，经过多年的不同编程方式转换到它并不容易。事实是，反应流可以使某些任务大大简化，但其他任务似乎要复杂得多。此外，以操作符序列的形式编写的代码，例如map或flatMap，不像传统的逐行阻塞方法调用那样容易理解。您不能简单地将任何一段代码提取到私有方法中以使其更具可读性。您必须在流上使用运算符序列。

我的观察是，反应灵敏的流stream对于思想开阔的开发人员而言不那么痛苦。虽然学习曲线绝对陡峭，但我认为值得花时间。

记录上下文信息

我们的技术要求之一是可追溯服务之间的对话。相关ID模式正是我们所需要的东西。简而言之：每条传入的消息都附加了一个唯一的文本值，它是在我们服务之外的某个位置生成的对话标识符。在我们的情况下，我们有两种类型的传入消息：

HTTP请求。

从SQS(Amazon简单队列服务)队列使用的消息。