为什么我们从代码中放弃反应式系统架构？（反应式.架构.放弃.代码.系统...）

本文探讨了我们在软件项目中放弃反应式架构的决定。我们将深入研究反应式系统的核心原则、非阻塞 i/o 的好处以及反应式方法所面临的挑战。

理解响应式架构风格

reactive 包含一系列旨在构建响应式分布式系统和应用程序的原则和指南，其特点是：

1. 响应能力：即使在重负载下也能够快速处理请求。
2. 弹性：能够以最短的停机时间从故障中恢复。
3. 弹性：可以通过相应地扩展资源来适应不断变化的工作负载。
4. 消息驱动：利用异步消息传递来增强容错能力并解耦组件。

反应式系统的一个主要好处是它们使用非阻塞 i/o。这种方法避免了 i/o 操作期间阻塞线程，允许单个线程同时处理多个请求。与传统的阻塞 i/o 相比，这可以显着提高系统效率。
在传统的多线程中，阻塞操作对优化系统提出了重大挑战（图 1）。消耗过多内存的贪婪应用程序效率低下，并且会惩罚其他应用程序，通常需要请求额外的资源，如内存、cpu 或更大的虚拟机。

图 1 – 传统多线程

i/o 操作是现代系统不可或缺的一部分，有效管理它们对于防止贪婪行为至关重要。反应式系统采用非阻塞 i/o，使少量的操作系统线程能够处理大量并发 i/o 操作。

反应式执行模型

虽然非阻塞 i/o 提供了巨大的好处，但它引入了一种不同于传统框架的新颖的执行模型。响应式编程的出现就是为了解决这个问题，因为它可以缓解阻塞操作期间平台线程空闲的低效率问题（图 2）。

图 2 – 响应式事件循环

quarkus 和 reactive

quarkus 利用由 eclipse vert.x 和 netty 提供支持的反应式引擎，促进非阻塞 i/o 交互。 mutiny 是使用 quarkus 编写反应式代码的首选方法，它采用事件驱动范例，其中反应由接收到的事件触发。

mutiny 提供两种事件驱动和惰性类型：

1. uni： 发出单个事件（一项或失败），适合表示具有零个或一个结果的异步操作。
2. multi： 发出多个事件（n 个项目、一个失败或一个完成），表示项目流，可能是无限的。

响应式的挑战

虽然反应式系统提供了好处，但我们在开发过程中遇到了一些挑战：

• 范式转变： 响应式编程需要开发人员思维方式的根本转变，这可能具有挑战性，特别是对于习惯命令式编程的开发人员来说。与 streams api 等辅助工具不同，反应式方法需要彻底改变思维方式。
• 代码可读性和理解： 反应式代码给新开发人员带来了理解困难，导致破译和理解代码的时间增加。反应式范式带来的复杂性加剧了这个问题。

“事实上，阅读与写作所花费的时间之比远远超过 10 比 1。我们不断地阅读旧代码，作为编写新代码的一部分。...[因此，]使其易于阅读使得写起来更容易。” ― robert c. martin，《整洁代码：敏捷软件工艺手册》

• 调试挑战：由于 lambda 封装了大多数代码，使用标准 ide 调试器调试反应式代码几乎是不可能的。此外，异常期间有意义的堆栈跟踪的丢失进一步阻碍了调试工作。 增加开发和测试工作：由于编写、修改和测试所需的时间，反应式代码固有的复杂性可能会导致更长的开发周期。

这是一个使用 mutiny 的反应式代码示例来说明其复杂性：

Multi.createFrom().ticks().every(Duration.ofSeconds(15))
    .onItem().invoke(() - > Multi.createFrom().iterable(configs())
    .onItem().transform(configuration - > {
  try {
    return Tuple2.of(openAPIConfiguration,
        RestClientBuilder.newBuilder()
            .baseUrl(new URL(configuration.url()))
            .build(MyReactiveRestClient.class)
            .getAPIResponse());

  } catch (MalformedURLException e) {
    log.error("Unable to create url");

  }
  return null;
}).collect().asList().toMulti().onItem().transformToMultiAndConcatenate(tuples - > {

  AtomicInteger callbackCount = new AtomicInteger();
  return Multi.createFrom().emitter(emitter - > Multi.createFrom().iterable(tuples)
      .subscribe().with(tuple - >
          tuple.getItem2().subscribe().with(response - > {
              emitter.emit(callbackCount.incrementAndGet());

  if (callbackCount.get() == tuples.size()) {
    emitter.complete();
  }
                    })
                ));

}).subscribe().with(s - > {},
Throwable::printStackTrace, () - > doSomethingUponComplete()))
    .subscribe().with(aLong - > log.info("Tic Tac with iteration: " + aLong));

未来展望-project loom 及未来

project loom 是 java 生态系统的最新开发项目，有望缓解与阻塞操作相关的问题。通过在不更改硬件的情况下创建数千个虚拟线程，project loom 可能在许多情况下消除对反应式方法的需求。

“loom 项目将杀死响应式编程”
―布莱恩·戈茨

结论

总之，我们决定放弃反应式架构风格，采用务实的方法来实现项目的长期可维护性。虽然反应式系统提供了潜在的好处，但它们给我们团队带来的挑战超过了我们特定环境中的这些优势。

重要的是，这种转变并没有影响性能。这是一个积极的结果，因为它表明设计良好的非反应式（命令式）架构可以提供必要的性能，而不会带来与我们案例中的反应式架构相关的复杂性。

展望未来，我们的重点仍然是构建一个代码库，该代码库不仅实用，而且易于所有经验水平的开发人员理解和维护。这不仅减少了开发时间，还促进了团队内更好的协作和知识共享。

在下图中，x 轴 代表我们的代码库在发展过程中不断增加的复杂性，而 y 轴 则描述了这些开发变化所需的时间。

以上就是为什么我们从代码中放弃反应式系统架构？的详细内容，更多请关注知识资源分享宝库其它相关文章！