当前位置: 首页 > 图灵资讯 > 技术篇> 为什么我们从代码中放弃反应式系统架构?

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

来源:图灵教育
时间:2024-09-04 20:20:04

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

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

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