API上に構築されたリアクティブスタックWebアプリケーションのサポートについて説明します。テストのサポート、およびリアクティブライブラリをカバーしています。サーブレットスタックWebアプリケーションについては、サーブレットスタック上のWebを参照してください。MVCに含まれる元のWebフレームワークは、サーブレットAPIおよびサーブレットコンテナー専用に作成されました。WebFluxは、バージョン5.0で後から追加されました。3.1+コンテナーなどのサーバーで実行されます。Frameworkで共存します。各モジュールはオプションです。アプリケーションは、一方または他方のモジュール、または場合によっては両方を使用できます。MVCコントローラーです。WebFluxが作成されたのはなぜですか?答えの一部は、少数のスレッドで同時実行性を処理し、より少ないハードウェアリソースでスケーリングするためのノンブロッキングWebスタックの必要性です。サーブレット3.1は、ノンブロッキングI/O用のAPIを提供していました。getPart)であるサーブレットAPIの残りの部分から離れます。これが、ノンブロッキングランタイム全体の基盤として機能する新しい共通APIの動機でした。サーバー(Nettyなど)が非同期のノンブロッキングスペースで十分に確立されているため、これは重要です。答えの他の部分は関数型プログラミングです。8にラムダ式を追加するとJavaの関数APIの機会が作成されます。よって普及した)の恩恵です。WebFluxはアノテーション付きコントローラーとともに機能的なWebエンドポイントを提供できました。available.Springチームが「リアクティブ」に関連付けるもう1つの重要なメカニズムは、ノンブロッキングバックプレッシャーです。同期命令型コードでは、呼び出しをブロックすることは、呼び出し側を待機させるバックプレッシャーの自然な形として機能します。ノンブロッキングコードでは、高速プロデューサーがその宛先を圧倒しないように、イベントのレートを制御することが重要になります。して機能)が応答に書き込むことができるデータを生成できます。Streamsの主な目的は、パブリッシャーがデータを生成する速さまたは遅さをサブスクライバーが制御できるようにすることです。パブリッシャーがスローダウンできない場合はどうなりますか?リアクティブストリームの目的は、メカニズムと境界を確立することだけです。パブリッシャーがスローダウンできない場合、バッファーするか、ドロップするか、失敗するかを決定する必要があります。リアクティブAPIリアクティブストリームは、相互運用性にとって重要なロールを果たします。ライブラリやインフラストラクチャコンポーネントには関心がありますが、低すぎるためアプリケーションAPIとしてはあまり有用ではありません。APIに似ていますが、コレクションだけでなく、非同期ロジックを構成するために、より高レベルでより関数APIが必要です。これは、リアクティブライブラリが果たすロールです。WebFluxに最適なリアクティブライブラリです。APIタイプを提供します。Reactorはリアクティブストリームライブラリであるため、すべてのオペレーターがノンブロッキングバックプレッシャーをサポートしています。Reactorは、サーバー側のJavaに重点を置いています。Springとの緊密なコラボレーションで開発されます。Streamsを介して他のリアクティブライブラリと相互運用できます。入力として渡すことができ、出力に操作を適用できますが、別のリアクティブライブラリで使用するために出力を調整する必要があります。可能な場合はいつでも(たとえば、アノテーション付きコントローラー)、WebFluxはRxJavaまたは別のリアクティブライブラリの使用に透過的に適応します。詳細については、リアクティブライブラリを参照してください。APIでも使用でき、より命令的なスタイルのプログラミングを提供します。APIで提供されます。APIを含むリアクティブファウンデーションが含まれています。WebFluxは2つのプログラミングモデルの選択肢を提供します。モジュールからの同じアノテーションに基づいています。MVCコントローラーとWebFluxコントローラーは両方とも、リアクティブ(ReactorおよびRxJava)戻り型をサポートしているため、区別するのは簡単ではありません。引数もサポートしていることです。ラムダベースの軽量で機能的なプログラミングモデル。これは、アプリケーションがリクエストのルーティングと処理に使用できる小さなライブラリまたはユーティリティのセットと考えることができます。アノテーション付きコントローラーとの大きな違いは、アプリケーションが開始から終了までのリクエスト処理を担当することと、アノテーションを介してインテントを宣言してコールバックすることです。MVCまたはWebFlux?当然の質問ですが、不健全な二分法を設定します。実際、両方が連携して利用可能なオプションの範囲を拡大します。この2つは互いに連続性と一貫性を保つように設計されており、並べて利用できます。各側からのフィードバックは両側に役立ちます。次の図は、2つの関係、それらの共通点、それぞれが独自にサポートするものを示しています。次の特定の点を考慮することをお勧めします。MVCアプリケーションがある場合、変更する必要はありません。命令型プログラミングは、コードを記述、理解、およびデバッグする最も簡単な方法です。歴史的に、ほとんどがブロックしているため、ライブラリの選択肢は最大限にあります。3.1+コンテナー)の選択肢も提供します。プログラミングモデル(アノテーション付きコントローラーおよび機能的なWebエンドポイント)、およびリアクティブライブラリ(Reactor、RxJava、またはその他)の選択。WebFlux関数Webエンドポイントを使用できます。透明性と制御性を高めることでメリットが得られる複雑な要件を持たない小規模なアプリケーションやマイクロサービスにも適しています。WebFlux機能エンドポイントのいずれかのアプリケーションを混在させることができます。両方のフレームワークで同じアノテーションベースのプログラミングモデルをサポートしているため、適切なジョブに適切なツールを選択しながら、知識を再利用しやすくなります。アプリケーションを評価する簡単な方法は、依存関係をチェックすることです。MVCは少なくとも一般的なアーキテクチャに最適です。ReactorとRxJavaの両方で別のスレッドでブロッキング呼び出しを実行することは技術的には可能ですが、ノンブロッキングWebスタックを最大限に活用することはできません。WebClientを試してください。)を返すことができます。コールごとのレイテンシーまたはコール間の相互依存性が大きいほど、メリットは劇的になります。MVCコントローラーは、他のリアクティブコンポーネントも呼び出すことができます。大規模なチームがある場合は、ノンブロッキング、機能的、宣言的プログラミングへの移行における急な学習曲線に留意してください。WebClientを使用することです。それを超えて、小さく始めて、利益を測定します。幅広いアプリケーションでは、シフトは不要であると予想されます。どのような利点を探すべきかわからない場合は、ノンブロッキングI/Oの仕組み(たとえば、シングルスレッドNode.jsの同時実行)とその影響について学習することから始めてください。WebFluxは、Tomcat、Jetty、サーブレット3.1+コンテナー、およびNettyやUndertowなどの非サーブレットランタイムでサポートされています。すべてのサーバーは低レベルの共通APIに適合しているため、サーバー全体で高レベルのプログラミングモデルをサポートできます。WebFluxには、サーバーを起動または停止するための組み込みサポートがありません。Spring構成とWebFluxインフラストラクチャからアプリケーションをアセンブルし、数行のコードで実行するのは簡単です。Bootには、これらのステップを自動化するWebFluxスターターがあります。デフォルトでは、スターターはNettyを使用しますが、MavenまたはGradleの依存関係を変更することにより、Tomcat、Jetty、またはUndertowに簡単に切り替えることができます。BootのデフォルトはNettyです。これは、非同期のノンブロッキングスペースでより広く使用されており、クライアントとサーバーがリソースを共有できるためです。MVCとWebFluxの両方で使用できます。それらの使用方法は非常に異なることに注意してください。MVCは、サーブレットのブロックI/Oに依存しており、必要に応じてアプリケーションがサーブレットAPIを直接使用できるようにします。WebFluxは、サーブレット3.1ノンブロッキングI/Oに依存し、低レベルアダプターの背後にあるサーブレットAPIを使用し、直接使用には公開されません。APIを直接使用します。パフォーマンスパフォーマンスには多くの特性と意味があります。一般に、リアクティブでノンブロッキングは、アプリケーションの実行を高速化しません。使用してリモート呼び出しを並行して実行する場合)可能です。全体として、ノンブロッキング方式で物事を行うにはより多くの作業が必要であり、必要な処理時間をわずかに増やすことができます。リアクティブでノンブロッキングの主な期待される利点は、少数の固定スレッドと少ないメモリで拡張できることです。予測可能な方法でスケーリングされるため、負荷がかかった場合でもアプリケーションの回復力が高まります。これらの利点を観察するには、ある程度の遅延(低速で予測不可能なネットワークI/Oの混在を含む)が必要です。それが、リアクティブスタックの強みを示し始めた場所であり、違いは劇的です。WebFluxは両方ともアノテーション付きコントローラーをサポートしますが、並行性モデルと、ブロッキングとスレッドのデフォルトの仮定に重要な違いがあります。ブロックできると想定されているため、サーブレットコンテナーはリクエスト処理中にブロックされる可能性を吸収するために大きなスレッドプールを使用します。WebFlux(および一般的なノンブロッキングサーバー)では、アプリケーションはブロックしないと想定されているため、ノンブロッキングサーバーは小さな固定サイズのスレッドプール(イベントループワーカー)を使用して要求を処理します。「スケーリングする」と「少数のスレッド」は矛盾しているように聞こえるかもしれませんが、現在のスレッドをブロックしない(および代わりにコールバックに依存する)ことは、吸収するブロッキング呼び出しがないため、余分なスレッドが必要ないことを意味します。オペレーターを提供します。簡単な脱出ハッチがあります。ブロッキングAPIはこの同時実行モデルには適していません。可変状態ReactorおよびRxJavaでは、演算子を介してロジックを宣言し、実行時に、データが個別の段階で順次処理されるリアクティブパイプラインが形成されます。この主な利点は、パイプライン内のアプリケーションコードが同時に呼び出されることがないため、アプリケーションが可変状態を保護する必要がないことです。WebFluxサーバー(たとえば、データアクセスやその他のオプションの依存関係なし)では、サーバー用に1つのスレッドと、リクエスト処理用にいくつかの他のスレッド(通常はCPUコアの数)が期待できます。サーブレット(ブロッキング)I/Oとサーブレット3.1(ノンブロッキング)I/Oの両方の使用をサポートするサーブレットコンテナーは、より多くのスレッド(たとえば、Tomcatで10)で開始する場合があります。イベントループスタイルで動作します。Nettyがクライアントとサーバーの両方に使用される場合、2つはデフォルトでイベントループリソースを共有します。オペレーターとともに使用します。スケジューラには、特定の並行性戦略を提案する名前があります。「並列」(スレッド数が限られたCPUバインド作業の場合)または「弾性」(多数のスレッドを使用したI/Oバウンド作業の場合)です。戦略を使用しているコードがあることを意味します。データアクセスライブラリおよびその他のサードパーティの依存関係も、独自のスレッドを作成して使用できます。Frameworkは、サーバーの起動と停止のサポートを提供しません。Boot構成オプションを確認する必要があります。他のすべてのライブラリについては、それぞれのドキュメントを参照してください。モジュールには、リアクティブWebアプリケーションに対する次の基本的なサポートが含まれています。サーバー要求処理には、2つのレベルのサポートがあります。Netty、Undertow、Tomcat、Jetty、および任意のサーブレット3.1+コンテナー用のアダプター。その上に、アノテーション付きコントローラーや機能エンドポイントなどの具体的なプログラミングモデルが構築されます。アプリケーションで使用される上位レベルのWebClientは、この基本契約に基づいています。クライアントおよびサーバーの場合、HTTPリクエストおよび応答コンテンツをシリアライズおよびデシリアライズするために使用するコーデック。要求と応答を処理する単一のメソッドを持つ単純な契約です。これは意図的に最小限であり、その主な唯一の目的は、異なるHTTPサーバーAPIを最小限に抽象化することです。次の表に、サポートされているサーバーAPIを示します。StreamsブリッジTomcatサーブレット3.1ノンブロッキングI/O。bridgeJettyサーブレット3.1ノンブロッキングI/O。アダプターを使用することを示しています。継承してWARに含めることができます。ラップし、Servletとして登録します。組み合わせることができます。APIは、次のようなWebアプリケーションで一般的に使用される広範な機能セットを提供することを目的としています。属性を持つユーザーセッション。