コードからリアクティブシステムアーキテクチャを削除したのはなぜですか?-＆＃＆チュートリアル-php.cn

コードからリアクティブシステムアーキテクチャを削除したのはなぜですか?

王林

リリース： 2024-08-30 06:00:35

オリジナル

973 人が閲覧しました

この記事では、ソフトウェアプロジェクトでリアクティブアーキテクチャから移行するという決定について説明します。リアクティブシステムの中核原則、ノンブロッキング I/O の利点、リアクティブアプローチで直面した課題について詳しく説明します。

リアクティブアーキテクチャスタイルを理解する

Reactive には、応答性の高い分散システムとアプリケーションの構築を目的とした一連の原則とガイドラインが含まれており、次の特徴があります。

応答性: 負荷が重い場合でもリクエストを迅速に処理できます。
復元力: 最小限のダウンタイムで障害から回復できます。
弾力性: リソースをそれに応じてスケーリングすることで、ワークロードの変化に適応できます。
メッセージ駆動型: 非同期メッセージングを利用してフォールトトレランスを強化し、コンポーネントを分離します。

リアクティブシステムの主な利点の 1 つは、ノンブロッキング I/O の使用です。このアプローチにより、I/O 操作中のスレッドのブロックが回避され、単一のスレッドで複数のリクエストを同時に処理できるようになります。これにより、従来のブロッキング I/O と比較してシステム効率が大幅に向上します。
従来のマルチスレッドでは、ブロック操作はシステムの最適化において重大な課題を引き起こします (図 1)。過剰なメモリを消費する貪欲なアプリケーションは非効率的であり、他のアプリケーションに悪影響を及ぼし、多くの場合、メモリ、CPU、またはより大きな仮想マシンなどの追加リソースの要求が必要になります。

Why we discarded Reactive systems architecture from our code?

図 1 – 従来のマルチスレッド

I/O 操作は現代のシステムに不可欠であり、貪欲な動作を防ぐには I/O 操作を効率的に管理することが最も重要です。リアクティブシステムはノンブロッキング I/O を採用し、少数の OS スレッドで多数の同時 I/O 操作を処理できるようにします。

リアクティブ実行モデル

ノンブロッキング I/O には大きな利点がありますが、従来のフレームワークとは異なる新しい実行モデルが導入されます。リアクティブプログラミングは、ブロック操作中にアイドル状態になるプラットフォームスレッドの非効率性を軽減するため、この問題に対処するために登場しました (図 2)。

Why we discarded Reactive systems architecture from our code?

図 2 – リアクティブイベントループ

クォーカスとリアクティブ

Quarkus は、Eclipse Vert.x と Netty を活用したリアクティブエンジンを活用し、ノンブロッキング I/O インタラクションを促進します。 Mutiny は、Quarkus でリアクティブなコードを記述するための推奨アプローチであり、受信したイベントによってリアクションがトリガーされるイベント駆動型のパラダイムを採用しています。

Mutiny は 2 つのイベント駆動型と遅延型を提供します。

Uni: 0 または 1 つの結果を持つ非同期アクションを表すのに適した、単一のイベント (項目または失敗) を発行します。
マルチ: 複数のイベント (n 個の項目、1 つの失敗、または 1 つの完了) を発行し、項目のストリームを表し、場合によっては無制限です。

リアクティブの課題

リアクティブシステムには利点がありますが、開発中にいくつかの課題に直面しました。

パラダイムシフト: リアクティブプログラミングでは開発者の考え方の根本的な変化が必要ですが、これは特に命令型プログラミングに慣れている開発者にとっては困難な場合があります。 Streams API のような補助ツールとは異なり、事後対応アプローチでは考え方の完全な見直しが必要です。
コードの読みやすさと理解: リアクティブコードは、新しい開発者にとって理解が難しく、解読と理解に費やす時間が増加します。反応的なパラダイムによってもたらされる複雑さが、この問題をさらに悪化させます。

「確かに、読み取り時間と書き込み時間の比率は 10 対 1 をはるかに超えています。私たちは新しいコードを書く努力の一環として常に古いコードを読んでいます。...[したがって] 読みやすくすることで、書きやすいです。」
― Robert C. Martin、クリーンコード: アジャイルソフトウェアクラフトマンシップのハンドブック

デバッグの課題: ラムダがほとんどのコードをカプセル化するため、標準の 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));

ログイン後にコピー

将来の展望 - プロジェクトの可能性とその先へ

Java エコシステムの最近の開発である Project Loom は、操作のブロックに関連する問題を軽減すると約束しています。 Project Loom は、ハードウェアを変更せずに何千もの仮想スレッドを作成できるようにすることで、多くの場合、事後対応型のアプローチの必要性を排除できる可能性があります。