なぜ Spring はクラウド ネイティブ時代においても優れたプラットフォームの 1 つなのでしょうか?

今日は、クラウド ネイティブ時代においても Spring が優れたプラットフォームの 1 つであり続ける理由についてお話ししたいと思います。

2015 年に、私はワシントンで開催された SpringOne 2015 カンファレンスに出席しましたが、基調講演は「クラウド ネイティブ エンタープライズ」でした。そのカンファレンスのスローガンも「クラウドネイティブ」であり、ポスターもすべてクラウドネイティブに関連したものでした。

当時はコンテナが普及していなかったのに、どうしてクラウド ネイティブと呼べるのか疑問に思うかもしれません。クラウド ネイティブに対する理解は学生によって異なるかもしれませんが、「クラウド ネイティブはコンテナではなく文化に関するものだ」と考える人が増えています。確かなのは、クラウド ネイティブはコンテナーと同じではないということです。それはソフトウェア開発の文化です。将来、V8 分離に基づくサーバーレスまたは WebAssembly FaaS プラットフォームが登場したとしても、それらは依然としてクラウド ネイティブの範囲内です。

クラウドネイティブのトレンドを受けて、Spring は分散アーキテクチャをサポートする Spring Cloud など、さまざまなことを実現してきました。これは基本的に、分散型およびクラウドベースの Java アプリケーションに不可欠なフレームワークです。 Spring Cloud Alibaba、AWS、Azure、GCP など、さまざまなクラウド ベンダーが Spring Cloud のドッキング バージョンを提供しています。Spring Cloud により、Java アプリケーションとクラウド サービスのドッキングが大幅に簡素化されます。

マイクロサービスがますます普及するにつれて、Spring エコシステムは常に主導的な立場にあると言えます。多くの人が疑問に思うかもしれません。Spring がこれまでに達成してきた成果は誰もが知っていますが、過去 2 年間で何の進展もなかったようです。 Spring は今後もテクノロジートレンドをリードし続けることができるでしょうか?

実際、このような混乱が生じる理由は、クラウドやクラウドネイティブ環境に基づく開発について話すとき、一般的にテクノロジー スタックの選択に重点が置かれ、その背後にある主な問題はコストであるためです。

すべての開発者や中小企業は、より多くのことを実行するために、より少ないクラウド リソースを購入したいと考えています。その中で最も重要なのは、メモリと CPU です。メモリ消費要件は小さいです。独立した実行可能プログラムにコンパイルできる場合は、軽量の開発フレームワークを選択するようにしてください。 CPU を最大限に活用し、スレッドの待機による無駄を回避するために、言語効率が高く完全に非同期のフレームワークを検討してください。

全体として、多くの人は Rust、Node.js、Golang などのテクノロジー スタックを選択することを好みます。しかし、Java は起動が遅く、メモリを大量に消費し、比較的高価であるため、これからのクラウドネイティブ時代には不向きだと思われます。

では、Java ベースの Spring エコシステムとして、クラウド ネイティブ、サーバーレス、Faas などの新しい開発方法に適応できるのでしょうか?クラウドネイティブ時代においても、それは依然として最良のプラットフォームの選択肢となるでしょうか?

次に、Java と JDK の発展、健全な競争に満ちた JVM 言語、Spring Boot と Spring Cloud の成熟したサービス指向アーキテクチャ、イベント駆動型アーキテクチャをより使いやすくする Spring Reactive という 5 つの観点からこの問題を分析します。

1. JavaとJDKの開発

Spring は Java フレームワークに基づいており、JDK は Java プログラムを実行するための基盤であることはご存じのとおりです。 「Spring は依然として最高のクラウド ネイティブ プラットフォームの 1 つとなるか?」という疑問を探るには、まず JDK ベースを調べて、それが Spring が時代の変化に対応するための優れた基盤を提供できるかどうかを確認する必要があります。

1 つ目はバージョンの反復です。 OpenJDK の開発速度は現在非常に速くなっています。以前はメジャーバージョンは3年ごとにリリースされていましたが、現在は6か月ごとにバージョンがリリースされています。多くの学生は、もうすぐ Java 17 になるのにまだ Java 1.8 を使用していると嘆いていました。ソフトウェア開発は小さなステップで迅速に進める必要があると誰もが言います。これは、小さなステップと素早い進歩、迅速なフィードバック、そして迅速な反復開発という優れた開発方法です。同様に、JavaScript には 1 年に 1 つのエディションがあり、TypeScript には 1 年に 3 つのエディションがあり、Java には 1 年に 2 つのエディションがあります。これらはすべて非常に良いリズムであると言えます。

2つ目は、JDK 機能の更新です。 JDK に注目すると、Loom プロジェクト、コルーチンに似た軽量スレッド、ネイティブ呼び出しサポートを改善する Panama プロジェクト (SIMD サポート)、より高度な GC アルゴリズムなど、ますます多くの機能が JDK に統合されていることがわかります。

前述のJavaの起動が遅い、メモリ消費量が多いといった問題に対応するため、OracleはOpenJDKをベースにしたGraalVMをリリースしました。これにより、JavaScript、Python、Rubyなどの言語をJVM内で直接実行できるようになります。これは正真正銘の Ployglot JVM です。さらに、GraalVM は、Java コードを独立した実行可能プログラムに変換できるネイティブ イメージ機能も提供します。 Spring は、Spring Native プロジェクトも開始しました。このプロジェクトでは、Spring Boot アプリケーションを簡単にネイティブ イメージ化できるため、Spring アプリケーションの起動が高速化し、メモリの消費量が少なくなります。ネイティブイメージの Spring アプリケーションは、あらゆる開発者や中小企業の「低コストでクラウドに移行したい」というニーズを満たすことができます。 Java コマンドライン アプリケーションの場合でも、GraalVM には非常に優れたソリューション (Picocli + GraalVM Native Image + upx) があり、Java アプリケーションをより便利な実行可能プログラムにコンパイルできます。

次の図は、GraalVM の多言語およびネイティブ イメージのサポート リストです。

さらに、AliJDK、Amazon Corretto、Azul など、さまざまなクラウドベンダーも JDK の開発を積極的に行っており、これらはすべて JDK の開発に非常に重要な役割を果たしています。

したがって、Spring の場合、JDK 基盤は依然として非常に堅牢です。

健全な競争に満ちたJVM言語

JDK は Java プログラミング言語のみをサポートするのではなく、Kotlin、Scala、Groovy など、ここでは JVM 言語と呼ぶ複数の言語をサポートできます。現在、JVM 言語は健全な競争状態にあります。

各言語には独自の使用シナリオがあることはわかっています。クラウドネイティブ時代においては、多言語開発サポートが非常に重要であり、開発者は実際のビジネスシナリオに基づいて異なる開発言語を選択する必要があります。 JVM 言語や GraalVM でサポートされている言語に関係なく、Spring と直接統合できるため、開発者は開発に Spring テクノロジー スタックを最大限に活用できます。

その中でも、Spring のサポートが最も優れている言語は Kotlin です。 Kotlin と Spring の統合はフレームワークのあらゆる側面に浸透しており、たとえば Spring Boot と Kotlin の統合、Spring Webflux の Kotlin Coroutines & Flow、Spring Data、SpringIntegration、SpringCloud Function など、すべて Kotlin のサポートが含まれています。これらは、言語とフレームワークをより適切に組み合わせ、開発効率を向上させることを目的として、Kotlin の深い統合を実現しました。さらに、Kotlin や Scala も Spring とよく統合される言語です。

Java、Kotlin、Scala は Spring で非常によく統合されているため、JVM 言語の現在の開発をより明確に理解できるように、これらについて詳しく説明します。

ジャワ

Java 言語の開発は依然として非常に急速に進んでいます。 OpenJDK の開発により、Java のバージョンは 6 か月ごとにリリースされることになります。各バージョンには構文のアップグレード、標準ライブラリのアップグレードなどが伴い、開発者の作業が大幅に容易になります。 Java 9 から 16 では、var キーワード (ローカル変数の型推論)、テキスト ブロック、instanceof のパターン マッチング、レコード、シール インターフェイスなど、構文と機能に多くの改善が加えられました。

コトリン

Kotlin は完全に JVM を対象としているわけではなく、ネイティブ、JavaScript なども含まれていますが、Kotlin の JVM と Android のサポートは、現在、多くの Kotlin プラットフォームの中で最も機能が豊富で安定しています。

Kotlin は現在急速に発展しており、最新の Kotlin Multiplatform Mobile (1 セットのコードで複数のモバイル プラットフォームをサポート) や Kotlin Compose for Desktop (1 セットのコードで複数のオペレーティング システム用のデスクトップ アプリケーションを開発) など、複数のサブプロジェクトが生まれています。もちろん、これらの変更の中で最も注目すべきは、Kotlin 1.5 で導入された Kotlin 中間表現 (IR) です。新しい IR を使用すると、Kotlin コードをコンパイルして、注目されている Kotlin WebAssembly などのより優れたプログラムを備えたさまざまなターゲット プラットフォームに出力できるようになります。

スカラ

Scala 2 は 2006 年 3 月にリリースされましたが、これはかなり昔のことです。良いニュースとしては、Scala 3.0 が 2021 年 5 月にリリースされたことです。Scala 3 では、Scala を使いやすくすることを目的として、Scala 2 からいくつかの目立たない機能が削除され、新しい機能が追加されています。ご興味がございましたら、Scala3 の公式 Web サイトをご覧ください。

Scala 3 のもう一つの重要な変更点は、Typed Abstract Syntax Trees の略である TASTy と呼ばれるコンパイラの調整です。構造は次のとおりです。

TASTy の助けにより、Scala.js が利用可能になりました。将来的に Scala WebAssembly が利用可能になったとしても不思議ではありません。

Kotlin と Scala はどちらも関数型プログラミングに非常に適しており、この点で Java の欠点を補っています。さらに、Kotlin と Scala はどちらも JavaScript コンパイル出力をサポートしており、これは Cloudflare の Serverless プラットフォームなどの V8 ベースの Serverless プラットフォームに非常に役立ちます。さらに、Kotlin と Scala も WebAssembly のサポートを積極的に検討しており、これは Web 開発をサポートする上で朗報です。

もちろん、Groovy、Clojure など、活発に開発されている JVM 言語も数多くあります。これらの JVM 言語は互いに競争し、互いに学習し合っており、これは開発者にとって非常に良いニュースです。

ここまで、Spring が依存する JDK と JVM 言語について説明してきましたが、次は Spring の 2 つの非常に成功したプロジェクト、SpringBoot と Spring Cloud について説明しましょう。

Spring Boot と Spring Cloud は 2 つの非常に成功したプロジェクトであり、基本的に Java テクノロジー スタックをベースとするすべてのインターネット企業で使用されています。さらに、Spring のトップエバンジェリストである Josh Long の最近のスピーチに注目していれば、彼が Spring Reactive について語っていることに気づくでしょう。彼はまた、「Spring Reactive」という本も執筆しました。

では、なぜ Spring Boot、Spring Cloud、Spring Reactive が人気なのでしょうか?

クラウド ネイティブには、サービス指向アーキテクチャとイベント駆動型アーキテクチャという 2 つの非常に重要なアーキテクチャ ソリューションがあることがわかっています。サービス指向アーキテクチャは通常、同期要求/応答モデルに基づいています。 Spring Boot と Spring Cloud の目標は、この機能をサポートすることです。イベント駆動型アーキテクチャは、非同期メッセージ モデルとメッセージ ルーティングに基づいており、Spring Reactive プロジェクトの中核はこのアーキテクチャをサポートすることです。

次に、Spring がクラウド ネイティブにおけるこれら 2 つの重要なアーキテクチャ ソリューションを具体的にどのようにサポートするかについて説明します。これを行うことで、Spring の 3 つの重要なプロジェクトである Spring Boot、Spring Cloud、Spring Reactive についてもより明確に理解できるようになります。

3. 成熟したサービス指向アーキテクチャ Spring Boot と Spring Cloud

一般的に、クラウドネイティブ アプリケーションはマイクロサービス設計を採用する傾向があり、マイクロサービス設計の中核はサービス指向アーキテクチャ設計とアプリケーション プログラミング インターフェイス (API) 管理です。 Spring Boot と Spring Cloud の目標はこの機能をサポートすることであり、これら 2 つのプロジェクトは非常に成功しています。 Java テクノロジー スタックをベースとするほぼすべてのインターネット企業がこれを使用しています。

サービス指向インターフェースの最も一般的な構造は、リクエスト/レスポンス モデル、特に Web のリクエスト/レスポンス モデルであることはよく知られています。もちろん、HTTP REST、gRPC、Dubbo などのリモート RPC 要求/応答もこのカテゴリに分類されます。

Spring のサービス指向アーキテクチャ設計に対応して、SpringMVC は OpenAPI のサポートを含め、Web および HTTP REST API を適切にサポートできます。その他の RPC タイプの通信にも対応する Spring Boot スターター サポートがあり、Spring Boot には対応するスターター コンポーネント サポートがあるため、開発が非常に便利になります。 Web サービスや SOAP などの従来のサービス形式など、他の形式のサービスを公開する場合は、Spring Web サービス (spring-ws) プロジェクトを通じて公開することもできます。

もう 1 つの機能である API 管理には、主にサービス ガバナンスとサービス コンシューマー呼び出しが含まれます。対応するコアテクノロジースタックは主に Spring Cloud プロジェクトです。 Spring Cloud は、サービス登録と検出、複雑なバランス調整、API ゲートウェイ、サーキットブレーカー保護など、サービス指向アーキテクチャと API 管理のためのさまざまな基本設定を提供します。これらのテクノロジー スタックにより、サービスの管理と制御が改善され、消費者がサービスをより適切に呼び出すことも可能になります。

要約すると、サービス指向アーキテクチャと API 管理は、Spring Boot および Spring Cloud テクノロジー スタックに対応しています。一般的なアーキテクチャは次のとおりです。

アーキテクチャがサービス オーケストレーション、サービス ガバナンス、API ゲートウェイなどのサービス指向である場合、完全な機能、安定したフレームワーク、完全なドキュメントを備え、Alibaba などの企業によって実際に実践されている Spring Cloud は、非常に良い選択肢です。あなたの会社が Java テクノロジー スタックをベースとしている場合、Spring Cloud はマイクロサービス アーキテクチャを実装するための最適なサポートとプラクティスです。

Alibaba は 2018 年 7 月から Spring Cloud Alibaba をオープンソース化しています。現在までに 19,000 を超えるスターを獲得しており、これは他のすべての実装の合計を上回っています。 X-labオープンラボが発表した「2020年マイクロサービス分野におけるオープンソースデジタル化レポート」からも、Spring Cloud Alibabaが最も活発で、開発者の間で最も人気があり、最も完全なツールチェーンSpring Cloud実装となっていることがわかります。選択プロセス中に考慮することができます。

4. Spring Reactive はイベント駆動型アーキテクチャを使いやすくします

先ほど、Spring のサービス指向アーキテクチャのサポートについて説明しました。イベント駆動型アーキテクチャという別のアーキテクチャ モデルもあります。イベント駆動型アーキテクチャは一般にクラウド ネイティブに適したアーキテクチャ ソリューションと考えられていますが、Spring はこの側面をどのようにサポートしているのでしょうか。これには Spring Reactive プロジェクトが関係しており、その中核はイベント駆動型アーキテクチャのサポートです。

Spring Reactive は非同期メッセージに重点を置いています。メッセージまたはイベントは、エンタープライズ統合パターン (EIP) によって推奨される最初のアーキテクチャ パターンです。エンタープライズ統合を主に担当する Spring Enterprise Integration プロジェクトについて聞いたことがあるかもしれません。 Spring Reactive の目的は、イベント駆動型アーキテクチャ設計をアプリケーション アーキテクチャの第一選択肢にし、それをよりシンプルにすることです。

ここで余談ですが、私は何人かの上級 Spring Boot および Spring Cloud プログラマーとコミュニケーションをとってきました。コードレベルの詳細も含め、さまざまなサービス指向のインターフェース設計に精通しています。しかし、エンタープライズ統合パターン (EIP) について議論したとき、彼らは皆、それがマーティン・ファウラーの有名な傑作だと言いました。システムで Apache Camel と Spring Integration のどちらを使用しているかを尋ねると、全員が、サービス指向の構造がビジネス ニーズを満たすようになったと答えました。

そこで疑問が生じます。なぜ、このようなよく知られた EIP、ESB、EDA がアーキテクチャ設計に採用されないのでしょうか?それは、ランプの下の暗闇が忘れられているからでしょうか、それとも閾値が高すぎるからでしょうか、それとも、それは単なる理論で、まったく実践されていないからでしょうか?

サービス指向アーキテクチャ設計では、基本的にサービス インターフェイス呼び出しに基づいており、呼び出しは同期されているため、サービス オーケストレーションと API 管理が非常に重要な役割を果たします。もちろん、サービス指向アーキテクチャ設計では、Kafka やその他の MQ システムなどのシステムを使用して、ユーザー登録後の電子メールの送信、ユーザー ログイン後のセキュリティ監査のイベントのトリガー、製品情報や価格の変更後の検索エンジンの増分インデックスのトリガー、ユーザーが注文した後のさまざまな通知のトリガーなど、いくつかの非同期またはデータ分析シナリオを処理するメッセージ駆動型設計も導入します。

サービス指向には利点がありますが、非ブロッキング、サービスの登録と検出、高パフォーマンス、容易な統合など、多くの問題を解決する必要もあります。このため、多くの専門家は、クラウド ネイティブ シナリオではイベント駆動型アーキテクチャが主流であると提案しています。

イベント駆動型アーキテクチャには、サービス登録や検出などの複雑なメカニズムは含まれません。メッセージベースのルーティングも非常に簡単です。非同期メッセージ通信はパフォーマンスが高く（もちろん請求額も少なくなります）、さまざまな SaaS サービスの統合も簡単（EventBridge 製品）、FaaS のトリガーも簡単、などです。さらに詳しく知りたい場合は、『Building Event-Driven Microservices』という書籍を参照してください。以下は、Redhat が推奨するマイクロサービスに基づくイベント駆動型アーキテクチャ設計です。

この図から、システム間のすべてのやり取りはメッセージングを通じて実行されることがわかります。マイクロサービスは、さまざまなアプリケーションからの要求/応答要求を処理するインターフェイス指向の要求/応答設計ではなく、ブローカーからのメッセージを非同期で継続的に処理します。

この時点で、Cloud Native がイベント駆動型設計アーキテクチャに基づいている場合、Spring Reactive の目的は、イベント駆動型アーキテクチャをシンプルで使いやすく、開発しやすいものにすることであることがおわかりいただけると思います。これは、Spring Boot と Cloud のサービス指向アーキテクチャのサポートと同じです。さらに、これら 2 つのアーキテクチャは矛盾しておらず、共存して相互に補完することができます。

より優れたイベント駆動型アーキテクチャを実現するには、非同期性とメッセージングという 2 つの基盤が不可欠です。非同期によりスレッド待機の問題を解決できる一方、メッセージとそのメッセージ ルーティングによりアプリケーションの疎結合を実現できます。現在、さまざまなメッセージング製品ミドルウェアはもちろんのこと、非同期メッセージング ソリューションを使用する製品が増えています。よく知られている HTTP/2 は、非同期メッセージング通信に基づいています。

では、なぜ非同期化が必要なのでしょうか?メッセージ処理モデルは同期サービス呼び出しとは異なることがわかっています。たとえば、メッセージ処理のイベント ループ モデルとアクター モデルはどちらも非常に効率的なメッセージ処理方法です。メッセージ処理プロセス中にスレッド プール ベースの同期サービス呼び出しも処理する必要がある場合、モデルとパフォーマンスに必然的に影響します。もちろん、同期がまったくできないというわけではありませんが、同期サービス呼び出しのシナリオが多すぎることは避けるようにする必要があります。

Spring には、非同期性とメッセージングのシナリオに関してやるべき作業がたくさんあります。 Java の非同期サポートが非常に遅れていることは誰もが知っています。 Java 1.8 では CompletionStage インターフェイスが追加され、Java 9 では Flow を導入するために Reactive Stream サポートが追加されました。誰もが注目している軽量スレッドである Loom プロジェクトはまだ開発中であり、Java 17 までリリースされない予定です。

そのため、現在、ほとんどの Java プロジェクトでは Reactive フレームワークが選択されています。もちろん、Spring チームは Reactor フレームワークを開発し、Reactor の Netty、Kafka などへの適応を追加して、ボトムアップで非同期であることを保証したため、これも Spring Reactive と名付けられている理由です。

次のシーンは誰もが見たことがあるものです。 Spring Webflux、Spring Integration、Spring Data などの多くのプロジェクトで非同期のサポートが追加されています。これらすべての調整は、ボトムアップで完全な非同期サポートを確保するためのものです。 5G には、非独立型ネットワークと独立型ネットワークという 2 つの方法があると理解できます。 Spring が Reactive、つまり独立したネットワークと独立したエコシステムのアプローチを選択しただけです。もちろん、作業量も非常に多くなります。これには、データベースと分散通信という 2 つの非常に大きな問題が関係します。

現在、ほとんどの NoSQL 製品は非同期インターフェースを提供しているため、NoSQL 製品に非同期でアクセスしても問題はありません。 NoSQL は急速に発展しましたが、データベースの地位を揺るがすほどではありませんでした。 Java でのデータベース アクセスの標準は JDBC であることは誰もが知っていますが、JDBC は同期インターフェイスであるため、Spring は Reactive 非同期インターフェイスを使用してデータベースにアクセスすることを目的とした R2DBC プロジェクトを開始しました。現時点では、Spring フレームワークで JDBC と R2DBC を使用する経験はほぼ同じです。

ここで、クラスメートと 2 つのニュースを共有したいと思います。Spring 5.3 には、spring-jdbc と同等の spring-r2dbc という R2DBC サポートが組み込まれています。誰もが好んで使用しているMySQLデータベースもmariadb-r2dbc 1.0.0安定版をリリースしており、OracleもR2DBC版ドライバーをリリースしています。もちろん、Spring JPA や MyBatis などの Java の DB フレームワークには、R2DBC への適応が追加されています。 Hibernate は、hibernate-reactive プロジェクト (Vert.x データベースに基づく) も開始しました。 R2DBC に基づいていませんが、完全に非同期です。

もう 1 つの問題は、マイクロサービス アーキテクチャで非常に重要な役割を果たす分散通信です。 Spring は常に HTTP を主にサポートしてきましたが、HTTP プロトコルは主にブラウザ向けに設計されており、バックエンド サービス間の通信に明らかな利点はなく、パフォーマンス上の利点もありません。もちろん、HTTP/2 非同期メッセージ通信に基づく gRPC は良い選択ですが、Spring には gRPC サポートが組み込まれていません。もちろん、これはほとんどの開発者にとって大きな問題ではなく、サードパーティの grpc-spring-boot-starter は非常に優れた機能を果たします。

Spring のリリースをフォローしている場合は、Spring 5.2 以降のバージョンでは RSocket 通信プロトコルが選択され、RSocket が spring-message プロジェクトに組み込まれていることを知っておく必要があります。なぜ？ RSocket は、完全な通信モデルとピアツーピア通信を提供する、完全に非同期のバイナリ メッセージ通信プロトコルであり、イベント駆動型アーキテクチャに非常に適しています。これが、Spring Reactive が RSocket を Spring コアに組み込む理由です。もちろん、Spring チームと Alibaba チームが RSocket の開発で主導的な役割を果たしています。

CNCF には CloudEvents 仕様があり、主に異種システムのイベント通信を解決します。メッセージとイベントはデータ構造が一貫しており、どちらもヘッダーとペイロード (データ) 構造であり、メッセージ ヘッダー拡張も含まれます。最新の cloudevents-java SDK 2.1 では、Spring メッセージングに CloudEvents のサポートが追加され、CloudEvent インターフェースのエンコードとデコードもサポートされ、メッセージとイベントが統一および統合されるため、Spring で CloudEvents とメッセージを処理することが容易になります。

Apache Camel、Akka ベースの Alpakk、MuleSoft の Mule 4、Spring Integration などのエンタープライズ統合関連製品はすべて Reactive 統合を提供し、Spring Reactive とシームレスに接続できます。

V. 結論

記事の質問に戻りますが、なぜ Spring はクラウド ネイティブ時代においても依然として最高のプラットフォームの 1 つなのでしょうか?まとめると、Java と JDK の開発は非常に順調に進んでおり、JVM 言語は健全に発展し、競争が激しくなっています。成熟した Spring Boot と Spring Cloud により、サービス指向アーキテクチャの設計がシンプルで使いやすくなりました。一方、Spring Reactive により、イベント駆動型アーキテクチャが使いやすくなり、IoT デバイス、ESB 製品、SaaS、クラウド サービスなど、より多くのエンタープライズ システムを Spring Reacitve に接続できるようになりました。

マイクロサービス シナリオの場合、Spring Cloud は成熟したアーキテクチャ指向のサービス基盤を提供し、Spring Reactive は将来志向のイベント駆動型アーキテクチャです。もちろん、これはサービス指向アーキテクチャが時代遅れであると言っているわけではありません。実際、サービス指向アーキテクチャは非常に成功しています。ただし、クラウド ネイティブ環境や新しいサーバーレス環境では、イベント駆動型アーキテクチャの方が合理的である可能性があり、または 2 つを組み合わせて使用​​することもできます。心配しないでください。Spring はどちらの面でも非常に優れています。