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

本文讨论了我们在软件项目中放弃反应架构的决定。我们将深入研究反应系统的核心原则和非阻塞性 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 轴 它描述了这些发展变化所需的时间。

这就是为什么我们从代码中放弃反应系统架构？详情请关注图灵教育的其他相关文章！