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

WBOY

发布时间：2024-08-29 21:30:09

545人浏览过

来源于dev.to

转载

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

理解响应式架构风格

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

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

反应式系统的一个主要好处是它们使用非阻塞 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 提供两种事件驱动和惰性类型：

小鸽子助手

一款集成于WPS/Word的智能写作插件

下载

uni： 发出单个事件（一项或失败），适合表示具有零个或一个结果的异步操作。
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));