本文探讨了我们在软件项目中放弃反应式架构的决定。我们将深入研究反应式系统的核心原则、非阻塞 I/O 的好处以及反应式方法所面临的挑战。
Reactive 包含一系列旨在构建响应式分布式系统和应用程序的原则和指南,其特点是:
反应式系统的一个主要好处是它们使用非阻塞 I/O。这种方法避免了 I/O 操作期间阻塞线程,允许单个线程同时处理多个请求。与传统的阻塞 I/O 相比,这可以显着提高系统效率。
在传统的多线程中,阻塞操作对优化系统提出了重大挑战(图 1)。消耗过多内存的贪婪应用程序效率低下,并且会惩罚其他应用程序,通常需要请求额外的资源,如内存、CPU 或更大的虚拟机。
图 1 – 传统多线程
I/O 操作是现代系统不可或缺的一部分,有效管理它们对于防止贪婪行为至关重要。反应式系统采用非阻塞 I/O,使少量的操作系统线程能够处理大量并发 I/O 操作。
虽然非阻塞 I/O 提供了巨大的好处,但它引入了一种不同于传统框架的新颖的执行模型。响应式编程的出现就是为了解决这个问题,因为它可以缓解阻塞操作期间平台线程空闲的低效率问题(图 2)。
图 2 – 响应式事件循环
Quarkus 利用由 Eclipse Vert.x 和 Netty 提供支持的反应式引擎,促进非阻塞 I/O 交互。 Mutiny 是使用 Quarkus 编写反应式代码的首选方法,它采用事件驱动范例,其中反应由接收到的事件触发。
Mutiny 提供两种事件驱动型和惰性类型:
虽然反应式系统提供了好处,但我们在开发过程中遇到了一些挑战:
“事实上,阅读与写作所花费的时间之比远远超过 10 比 1。我们不断地阅读旧代码,作为编写新代码的一部分。...[因此,]使其易于阅读使得写起来更容易。”
―Robert C. Martin,《整洁代码:敏捷软件工艺手册》
这是一个使用 Mutiny 的反应式代码示例来说明其复杂性:
Project Loom 是 Java 生态系统的最新开发项目,有望缓解与阻塞操作相关的问题。通过在不更改硬件的情况下创建数千个虚拟线程,Project Loom 可能在许多情况下消除对反应式方法的需求。
“Loom 项目将杀死响应式编程”
―布莱恩·戈茨
总之,我们决定放弃反应式架构风格,采用务实的方法来实现项目的长期可维护性。虽然反应式系统提供了潜在的好处,但它们给我们团队带来的挑战超过了我们特定环境中的这些优势。
重要的是,这种转变并没有影响性能。这是一个积极的结果,因为它表明设计良好的非反应式(命令式)架构可以提供必要的性能,而不会带来与我们案例中的反应式架构相关的复杂性。
展望未来,我们的重点仍然是构建一个代码库,该代码库不仅实用,而且易于所有经验水平的开发人员理解和维护。这不仅减少了开发时间,还促进了团队内更好的协作和知识共享。
在下图中,X 轴代表我们的代码库在发展过程中不断增加的复杂性,而Y 轴则描述了这些开发变化所需的时间。
以上是为什么我们从代码中放弃反应式系统架构?的详细内容。更多信息请关注PHP中文网其他相关文章!