SpringCloud - Microservices (マイクロサービス); Spring Cloud 詳細説明 (1)

Java プログラマーとして、システム アーキテクチャの進化について明確にする必要があるので、まず、アーキテクチャの進化について簡単に説明します。

1. モノリシック アーキテクチャ (集中型アーキテクチャ)

単一構造は比較的初歩的なもので、代表的な 3 層構造、フロントエンド (Web/モバイル端末) + 中間ビジネス ロジック層 + データベース層です。これは、典型的な Java Spring MVC フレームワーク アプリケーションです。

モノリシック アーキテクチャとは、すべての機能とモジュールを 1 つのプロジェクトにまとめてサーバーにデプロイし、外部サービスを提供することです (集中型アーキテクチャ、モノリシック サービス、モノリシック アプリケーション)

モノリシック アプリケーションは、デプロイとテストが容易です。プロジェクトの初期段階では、モノリシック アプリケーションを適切に実行できます。しかし、需要が増え続け、開発チームに参加する人が増えるにつれて、コード ベースも急速に拡大しました。ゆっくりと、モノリシック アプリケーションはますます肥大化し、保守性と柔軟性が徐々に低下し、保守コストがますます高くなります。

2. 分散アーキテクチャ

本「分散システムの原則とパラダイム」には、次の定義があります: 分散システムは、いくつかの独立したコンピューターの集まりであり、これらのコンピューターは、ユーザーにとって 1 つの関連システムのようなものです。共通のタスクを実行します。

簡単に言えば、すべての機能とモジュールを別々のサブプロジェクトに分割し、それらを複数の異なるサーバーにデプロイし、これらのサブプロジェクトが相互に連携して外部サービスを提供することです。

単一アーキテクチャと比較して、このアーキテクチャは負荷分散機能を提供し、システムの負荷容量を大幅に改善し、Web サイトの高い同時実行要件を解決します。たとえば、e コマース プロジェクトは、ユーザー ユーザー、オーダー オーダー、ショッピング カート ショップなどのサブプロジェクト/モジュールに分割できます。

写真は百度より

このアーキテクチャの利点:

（1）結合度を下げる：モジュールを分割し、インターフェイスを使用して通信し、モジュール間の結合度を下げます

(2) 明確な責任:プロジェクトをいくつかのサブプロジェクト/モジュールに分割し、異なるチームが異なるサブプロジェクト/モジュールを担当します。

(3) 拡張が容易:機能を追加するときは、別のサブプロジェクト/モジュールを追加し、他のシステムのインターフェースを呼び出すだけです。

(4) 簡単な展開:柔軟な分散展開

(5) コードの再利用性向上：例えば、サービス層が分散型サービスアーキテクチャを採用していない場合、pc、android、ios 端でサービス層を書く必要があり、大量の開発が困難分散サービスを使用し、サービス レイヤーを共有します。

短所: システム間の対話にはリモート通信が必要であり、インターフェイスの開発によりワークロードが増加します (ただし、全体的な利点は欠点を上回ります)

3. マイクロサービス アーキテクチャ

以下はコーミングに焦点を当てています

4. クラウド ネイティブ アーキテクチャ

クラウドネイティブ アプリケーションとは、一般に、クラウド展開をネイティブにサポートし、クラウド プラットフォームの機能を最大限に活用できるアプリケーションを指します。一般に、次の 3 つの特徴があります。

コンテナ包装。コンテナ化されたカプセル化とは、コンテナにカプセル化され、コンテナ内で実行されるコンテナベースのアプリケーションを指し、リソースの相対的な分離とコンテナ イメージの再利用を実現します。

マイクロサービス指向。マイクロサービス指向とは、大規模な機能アプリケーションを単一の機能を持つマイクロ アプリケーションに分割することを指し、比較的独立しており、互いに分離されており、マイクロ アプリケーションはインターフェイスを介して通信します。

動的管理。動的管理とは、K8S などの統合オーケストレーション ツールを介したこれらのマイクロサービスの動的管理とスケジューリングを指します。
その後、クラウド コンピューティングの発展に伴い、CNCF Cloud Native Computing Foundation は宣言型 API とサービス グリッドという2 つの項目を追加しました。

アプリケーションが上記の特性を満たしている場合、それはクラウドネイティブ アプリケーションと呼ぶことができます。クラウド ネイティブ アプリケーションには固有の利点があるため、ますます多くの企業がクラウド ネイティブ アプリケーションを採用しています。これには、企業がクラウド ネイティブ テクノロジーをより有効に活用するための新しい技術アーキテクチャが必要です。そして、クラウドネイティブ テクノロジを使用してビジネスの俊敏性、費用対効果、および強力さを向上させるこの種の技術アーキテクチャは、クラウドネイティブ アーキテクチャになる可能性があります。コンテナー テクノロジを使用し、マイクロサービスに基づいており、アジャイルな方法を使用して、DevOps ジャーニーを通じてアプリケーションの継続的な配信を実現します。

クラウド ネイティブ アーキテクチャ = マイクロサービス + コンテナ化 + DevOps + 継続的デリバリー.

1.マイクロサービスアーキテクチャ

マイクロサービス アーキテクチャ

マイクロサービス (マイクロサービス) は、特定の技術標準ではなくビジネス機能を中心に構築された、複数の小さなサービスの構成を通じて単一のアプリケーションを構築するためのアーキテクチャ スタイルです。各サービスは、異なるプログラミング言語、異なるデータ ストレージ テクノロジを使用し、異なるプロセスで実行できます。このサービスは、通信と運用と保守を実現するために、軽量の通信メカニズムと自動展開メカニズムを採用しています。

マイクロサービスの起源

「マイクロサービス」という技術用語は、2005 年に初めて提案されました。2005 年の Cloud Computing Expo (Web Services Edge 2005) で Dr. Peter Rodgers によって最初に使用され、「マイクロ Web サービス」と呼ばれ、単一のサービスを指します。 -責任に焦点を当てた、言語に依存しない、きめの細かい Web サービス (Granular Web Services)。

マイクロサービス

マイクロサービスが本格的に台頭したのは 2014 年のことで、 Martin Fowler (Martin Fowler)と James Lewis (James Lewis) が共同執筆した記事「マイクロサービス: この新しいアーキテクチャ用語の定義」からマイクロサービスについて初めて知ったのもこの時でした。 ) . . 誰もが知っている「マイクロサービス」が、この記事で定義した「マイクロサービス」です

マイクロサービスへの元のリンク 

元のリンクを マイクロサービスに翻訳｜YYGCuiのブログ

この記事では、最新のマイクロサービスの概念を最初に説明します。

「マイクロサービスは、複数の小さなサービスを組み合わせて単一のアプリケーションを構築するアーキテクチャ スタイルです。これらのサービスは、特定の技術標準ではなく、ビジネス機能を中心に構築されています。各サービスは、異なるプログラミング言語、異なるデータ ストレージ テクノロジを使用し、異なるプロセスで実行できます。このサービスは、通信と運用と保守を実現するために、軽量の通信メカニズムと自動展開メカニズムを採用しています。」

さらに、この記事では、マイクロサービスのビジネス上および技術上の 9 つの主要な特徴を挙げています。

• ビジネス能力を中心に構成されています。ここでもコンウェイの法則の重要性が強調されますが、どのような構造、規模、能力を備えたチームでも、対応する構造、規模、能力を備えた製品を生み出します。この結論は、あるチームやある企業が遭遇した偶然ではなく、進化の必然的な結果です。同じ製品に属するべき機能が別のチームに分割されると、チーム間の大量のコミュニケーションとコラボレーションが必然的に発生します.チームの境界を越えると、管理、コミュニケーション、および作業手配の面でコストが高くなります.効率的なチームチームと製品が調整されて安定すると、チームと製品は一貫した構造になります。
• 分散型ガバナンス。これは、「誰の子が担当するか」という意味を表すためのもので、サービスに対応する開発チームは、サービス運用の品質に直接責任を負い、外部からの干渉なしにサービスのすべての側面を制御する権利も持つ必要があります。選択およびその他のサービスとして 独自のサービスを実装するための異種技術。この点は実際にはある程度の余裕があります. ほとんどの企業は、あるサービスに Java を使用したり、別のサービスに Python を使用したり、次のサービスに Golang を使用したりすることはありません. 代わりに、通常、統一されたメインストリーム言語、または統一されたテクノロジ スタックまたは独自のテクノロジ プラットフォームを使用します. マイクロサービスは、この種の「統合」を支持も反対もしません. 基本的な技術スタックを提供および維持する責任を負うチームが、すべての関係者から依存されているという意識を持ち、「頻繁に目覚める」という精神的準備をしている限り、朝の3時に目覚まし時計」、いいですね。マイクロサービスは、技術的な不均一性が本当に必要な場合は、「不均一性」を選択する権利を持つべきだと強調しています. たとえば、Node.js にレポート ページの開発を強制するべきではありません. 人工知能のトレーニング モデルを実行するときは、 Python などを選択します。
• 独立した自律的なコンポーネントを実現するためのサービスによるコンポーネント化（サービスによるコンポーネント化）。「ライブラリ」ではなく「サービス」を通じてコン​​ポーネントを構築することを強調する理由は、クラス ライブラリがコンパイル時にプログラムに静的にリンクされ、ローカル呼び出しを通じて関数を提供するのに対して、サービスはプロセス外のコンポーネントであるためです。リモート通話で提供されます。前回の記事では、リモート サービスは呼び出しコストが高くなりますが、これはコンポーネントに分離と自律性をもたらすために必要なコストであると分析しました。
• 製品思考(プロジェクトではなく製品)。ソフトウェア開発を完了する機能としてではなく、継続的な改善と改善のプロセスと見なすことは避けてください。例えば、運用保守は運用保守チームの仕事とみなすだけでなく、開発は開発チームの仕事とみなすべきであり、チームはソフトウェア製品のライフサイクル全体に責任を持つべきです。開発者は、ソフトウェアがどのように開発されるかだけでなく、ソフトウェアがどのように開発されるか、どのように機能するか、ユーザーがどのようにフィードバックを提供するか、さらにはアフターセールス サポート作業がどのように行われるかを知る必要があります。ここでのサービスのユーザーは、必ずしもエンド ユーザーではなく、このサービスを使用する別のサービスである可能性があることに注意してください。これまでのモノリシック構造では、プログラムの規模が大きくなり、すべての人員が完全な製品に注意を向けることができず、組織内で開発、運用保守、サポートなどの詳細な分業を行うメンバーが存在していました。 . 各人は自分の仕事だけに集中していましたが、マイクロサービスの下では、開発チームの全員が製品の考え方を持ち、製品全体のあらゆる側面に注意を払うことが可能です.
• データの分散化(分散型データ管理)。マイクロサービスは、データが分散された方法で管理、更新、維持、および保存されるべきであることを明確に提唱しています. 単一のサービスでは、システムの各機能モジュールは通常、同じデータベースを使用します. 集中型ストレージは本質的に一貫性の問題を回避するのが容易であることは事実です.ただし、同じデータ エンティティの抽象的な形式は、異なるサービスの観点からは異なることがよくあります。例えば、書店アプリの本は、販売分野では価格、倉庫保管分野では在庫数、商品陳列分野では書籍の紹介情報に着目し、集中保管庫として利用する場合、すべての分野が同じエンティティを変更してマッピングすると、異なるサービスが互いに影響し合い、独立性を失う可能性があります。分散環境で一貫性の問題に対処することは非常に困難ですが、従来のトランザクション処理を使用して一貫性を保証することは不可能なことがよくあります。
• 強力な端末の弱いパイプライン(スマート エンドポイントとダム パイプ)。弱いパイプライン (Dumb Pipe) は、SOAP と ESB に直接対抗する複雑な通信メカニズムの集まりです。ESB はメッセージ エンコーディング処理、ビジネス ルール変換などを処理でき、BPM はエンタープライズ ビジネス サービスを一元的に編成でき、SOAP はトランザクション、一貫性、認証、承認などの一連のタスクを処理するために数十の WS-* プロトコル ファミリを備えています。上記の機能は、特定のシステムのサービスの特定の部分に必要な場合がありますが、他の多くのサービスには負担がかかります。サービスに上記の追加の通信機能が必要な場合は、通信パイプライン上のパッケージではなく、サービス自体のエンドポイントで解決する必要があります。マイクロサービスは、従来の UNIX フィルターに似たシンプルで直接的な通信方法を提唱しており、マイクロサービスでは RESTful スタイルの通信がより適切な選択肢になります。
• フォールト トレラントな設計(失敗に対する設計)。サービスの永遠の安定性を幻想的に追求するのではなく、サービスが常にうまくいかないという現実を受け入れるマイクロサービスの設計には、依存するサービスの障害を迅速に検出し、障害が発生した場合にそれらを分離できる自動メカニズムがあります。サービスが回復したら再接続してください。したがって、「サーキット ブレーカー」などの設備は、実際の運用環境におけるマイクロサービスのオプションの周辺コンポーネントではなく、必要なサポート ポイントです。サービスの崩壊によってもたらされる効果は圧倒されます。信頼できるシステムが失敗する可能性のあるサービスで構成されている可能性は十分にあります.これがマイクロサービスの最大の価値であり、これがこのオープンソース ドキュメントのタイトル「The Fenix Project」の意味です.
• 進化的デザイン。フォールト トレラント設計はサービスが失敗することを認識し、進化的設計はサービスが陳腐化することを認識します。よく設計されたサービスは廃棄できるものであるべきであり、永遠に存続することは期待されていません。変えられない、かけがえのないサービスがシステムにあるとすれば、それはそのサービスが優れていて重要であるということではなく、システム設計の脆弱性の表れであり、マイクロサービスが追求する独立性と自律性は、この脆弱性の顕在化にも反しています。
• インフラ自動化。CI/CDの急速な発展などインフラの自動化により、構築、リリース、運用・保守作業の煩雑さが大幅に軽減されています。マイクロサービスの下での運用と保守の対象は、単一のアーキテクチャと比較して桁違いに増加するため、マイクロサービスを使用するチームはインフラストラクチャの自動化に依存し、人間が数百、数千、さらには数万をサポートすることは困難ですのサービスです。

マイクロサービスは非常に小さいサービスであり、非常に小さいため、サービスは 1 つの機能にのみ対応し、1 つのことだけを行います。このサービスは独立して展開および実行でき、サービスはrpcを介して相互に対話できます. 各マイクロサービスは、ライフサイクル全体を担当する独立した小さなチームによって開発、テスト、展開、および開始されます

分散サービスは、さまざまなマシンに分散および展開されます。サービスは、複数の機能を担当する場合があります。これは、SOA 指向のアーキテクチャです。サービスは、rpc または webservice を介して対話します。

分散システムの各モジュールは、インターフェイスを介してデータとやり取りします. 実際、分散システムも一種のマイクロサービスです. モジュールを独立したユニットに分割し、呼び出すためのインターフェイスを提供するからです.

したがって、分散サービスとマイクロサービスには多くの類似点がありますが、同一ではないことがわかります。それらの間にはまだいくつかの違いがあります

1. 分散型サービスと比較して, マイクロサービスは粒度が小さく, サービス間の結合が少ない. 各マイクロサービスは独立した小さなチームが担当するため, 俊敏性が高い. 分散型サービスは最終的にマイクロサービスアーキテクチャに進化する.

2. マイクロサービスと分散サービスの本質的な違い

マイクロサービスと分散構造の本質的な違いは「ターゲット」に反映されています 

マイクロサービスと分散型の微妙な違いは、マイクロサービスのアプリケーションが必ずしも複数のサーバーに分散しているわけではなく、同じサーバーであってもよいということです。

Distributed はマイクロサービスに属し、モジュールは独立したサービス ユニットに分割され、インターフェイスを介したデータのやり取りを実現します。

分散サービスとマイクロサービスのアーキテクチャは非常に似ていますが、デプロイの方法が異なります。

解決すべき分散アーキテクチャ: 1 台のマシンでは多数のユーザー アクセスに対応できない、またはコストの問題により、サービスの展開を完了するために複数のマシンを使用する必要がある

マイクロサービスの構造設計は、特定のモジュールのアップグレードやバグによって既存のシステム業務に影響を与えないようにするためのものであり、モジュールのアップグレードやバグやリファクタリングなど、各モジュールを分離するだけで、相互に影響を受けることはありません。他のモジュールに影響を与えるため、マイクロサービスは 1 台のマシンにデプロイできます

マイクロサービスは、各モジュールが独立するようにデカップリングに重点を置いています。分散型は、リソースの共有とコンピュータ コンピューティングの高速化に重点を置いています

分散型もマイクロサービスの一種で、マイクロサービスも分散型

二、春雲

マイクロサービスはプロジェクト アーキテクチャの手法とアーキテクチャの概念であり、Spring Cloud はこのアーキテクチャの手法を技術的に実現したものです。

SpringCLoud 公式サイト: Spring Cloud

以下、公式サイトより引用

Spring Cloud は、開発者が分散システムの一般的なパターン (構成管理、サービス検出、サーキット ブレーカー、インテリジェント ルーティング、マイクロプロキシ、制御バス、ワンタイム トークン、グローバル ロック、リーダーシップ選挙、分散型など) のいくつかを迅速に構築するためのツールを提供します。セッション、クラスター状態)。分散システムの調整は定型パターンにつながり、Spring Cloud 開発者を使用すると、それらのパターンを実装するサービスとアプリケーションを迅速に立ち上げることができます。これらは、開発者自身のラップトップ、ベアメタル データ センター、Cloud Foundry などのマネージド プラットフォームなど、あらゆる分散環境でうまく機能します。

特徴

Spring Cloud は、典型的なユースケースにすぐに使用できる優れたエクスペリエンスと、他のユースケースをカバーする拡張メカニズムを提供することに重点を置いています。

• 分散/バージョン管理された構成

• サービスの登録と検出

• ルーティング

• サービス間の呼び出し

• 負荷分散

• サーキットブレーカー

• グローバル ロック

• リーダーの選出とクラスターの状態

• 分散メッセージング

翻訳は次のとおりです。

Spring Cloud は、分散システムでいくつかの一般的なパターンを迅速に構築し、いくつかの一般的な問題 (構成管理、サービス検出、サーキット ブレーカー、インテリジェント ルーティング、マイクロエージェント、制御バス、ワンタイム トークン、グローバル ロックなど) を解決するためのツールを開発者に提供します。リーダー選出、分散セッション、クラスター状態)。分散システムの調整は、大量のボイラープレート コード (ルーチンが固定された多数のコード) につながります。Spring Cloud 開発者を使用すると、これらのパターンを実装するサービスとアプリケーションをすばやく構築できます。開発者自身のラップトップ、ベアメタル データ センター、クラウド コンピューティングなどのホスティング プラットフォームなど、あらゆる分散環境で適切に機能します。

Spring Cloud特性

Spring Cloud は、次のような分散システム開発の典型的なアプリケーション シナリオにすぐに使える優れた機能を提供します。

分散/バージョン管理された構成

サービスの登録と検出

ルーティング

サービス間の呼び出し

負荷分散

ブレーカ

グローバルロック

リーダーの選出とクラスターの状態

分散メッセージング

SpringCloud の主なプロジェクト

春のクラウド構成

春の雲 ネットフリックス

春の雲バス

Spring Cloud クラウドファウンドリー

Spring Cloud オープン サービス ブローカー

スプリング クラウド クラスター

春雲領事

スプリング クラウド セキュリティ

春の雲探偵

Spring クラウド データ フロー

春の雲の流れ

Spring Cloud Stream アプリ スターター

スプリング クラウド タスク

Spring Cloud タスク アプリ スターター

春の雲の飼育係

春のクラウド AWS

Spring クラウド コネクタ

Spring Cloud スターター

スプリング クラウド CLI

春のクラウド契約

Spring クラウド ゲートウェイ

スプリング クラウド OpenFeign

Spring クラウド パイプライン

春のクラウド関数

Spring Cloud は、SpringBoot で開発された分散型マイクロサービス アーキテクチャに基づくワンストップ ソリューションであり、サービスの登録と検出、構成センター、サービス ゲートウェイ、ロード バランシング、ヒューズ、フル リンク モニタリングなどを含みます

。サービス システムの「ファミリー バケット」は、特定のテクノロジではなく、一連のマイクロサービス ソリューションまたはフレームワークの順序付けられたコレクションです。市場で成熟した実績のあるマイクロサービス フレームワークを統合し、Spring Boot のアイデアを通じてそれらを再パッケージ化し、複雑な構成と実装の原則を保護して調整し、最終的に開発者にシンプルで理解しやすく簡単な一連のサービスを提供します。 -展開しやすく、保守が容易な分散システム開発キットです。

Spring Cloud によってリリースされたバージョンは、ロンドンの地下鉄駅のアルファベット順の名前です (「Angel」は最初のバージョン、「Brixton」は 2 番目のバージョン)、アルファベット順は AZ から、最新の安定バージョン 2021.0 .x 別名 Jubilee です 。 Spring Cloud の一部のサブプロジェクトには重大なバグまたはメジャー アップデートがあり、リリース シーケンスは、名前が「.SRX」で終わるバージョンを起動します。「X」は、グリニッジ SR1、グリニッジ SR2、グリニッジ SR3 などの数字です。

1. Spring Cloud の共通コンポーネント

Spring Cloud 自体はすぐに使えるフレームワークではなく、2 世代の実装を持つマイクロサービス仕様のセットです。

(1) Spring Cloud Netflix は  Spring Cloud の第 1 世代の実装であり、主に Eureka、Ribbon、Feign、Hystrix などのコンポーネントで構成されています。

(2) Spring Cloud Alibaba はSpring Cloud の第 2 世代の実装であり、主に Nacos、Sentinel、Seata およびその他のコンポーネントで構成されています。

Spring Cloud (具体的には Spring Cloud Netflix) には、spring-cloud-config や spring-cloud-bus などの約 20 のサブプロジェクトが含まれており、サービス ガバナンス、サービス ゲートウェイ、インテリジェント ルーティング、負荷分散、サーキット ブレーカー、監視追跡、分散ソリューションを提供します。メッセージ キューイングと構成管理の分野。

Netflix は、米国のオンライン動画 Web サイトであり、大規模なプロダクション レベルのマイクロサービスの優れた実践者であり、マイクロサービス業界のリーダーとして認められています。Netflix のオープン ソース コンポーネントは、大規模な分散型マイクロサービス環境で長年にわたって実稼働環境で実証されており、成熟しており信頼性があります。

Spring Cloud は、Netflix のオープン ソース サービス コンポーネント (Eureka、Ribbon、Feign、Hystrix など) を Spring Cloud Netflix モジュールに統合します. 統合されたコンポーネントは Spring Cloud Netflix XX と呼ばれるため、第 1 世代の SpringCloud 実装もSpring Cloud Netflixと呼ばれる

その後、  Spring Cloud Netflix と Spring Cloud Alibaba が区別されます。

Spring Cloud (特にSpring Cloud Netflix ) の共通コンポーネントを以下の表に示します。

Spring Cloud コンポーネント	説明
春の雲 Netflix エウレカ	Spring Cloud Netflix のサービス ガバナンス コンポーネントには、サービス レジストリ、サービス登録、および検出メカニズムの実装が含まれます。
スプリング クラウド Netflix リボン	Spring Cloud Netflix のサービス呼び出しおよびクライアント負荷分散コンポーネント。
スプリング クラウド ネットフリックス ハイストリックス	「Brother Porcupine」として知られる Spring Cloud Netflix のフォールト トレラント管理コンポーネントは、サービスの遅延と障害に対して強力なフォールト トレランスを提供します。
春の雲 Netflix のふり	リボンと Hystrix に基づく宣言型サービス呼び出しコンポーネント。
春の雲 ネットフリックス ズール	Spring Cloud Netflix のゲートウェイ コンポーネントは、インテリジェント ルーティングやアクセス フィルタリングなどの機能を提供します。
Spring クラウド ゲートウェイ	Spring 5.0、Spring Boot 2.0、Project Reactor などのテクノロジーに基づいて開発されたゲートウェイ フレームワークで、フィルター チェーンを使用して、セキュリティ、監視/インジケーター、電流制限などのゲートウェイの基本機能を提供します。
春のクラウド構成	Spring Cloud の構成管理ツールは、Git を使用して構成コンテンツを保存することをサポートし、アプリケーション構成の外部ストレージを実現し、クライアント側での構成の更新、暗号化、および復号化などの操作をサポートします。
春の雲バス	Spring Cloud のイベントおよびメッセージ バスは、主にクラスター内のイベントまたは状態の変化を伝播して、動的更新構成などの後続の処理をトリガーするために使用されます。
春の雲の流れ	Spring Cloud のメッセージ ミドルウェア コンポーネントは、Apache Kafka や RabbitMQ などのメッセージ ミドルウェアを統合し、バインダーを中間層として定義することで、アプリケーションとメッセージ ミドルウェアの分離を完全に実現します。統一されたチャネル チャネルをアプリケーションに公開することにより、アプリケーションは、さまざまなメッセージ ミドルウェアの実装を考慮する必要なく、メッセージを簡単に送受信できます。
春の雲探偵	Spring Cloud 分散リンク追跡コンポーネントは、Twitter の Zipkin を完全に統合できます。

2. Spring Cloud と Spring Boot の関連付け

SpringBoot は、個々のマイクロサービスの迅速で便利な開発に重点を置いています。

SpringCloud は、全体的な状況に焦点を当てたマイクロサービスの調整とガバナンスのフレームワークです.SpringBoot によって開発された個々のマイクロサービスを統合および管理し、構成管理、サービス検出、サーキット ブレーカー、ルーティング、マイクロエージェント、イベント バスなどの統合サービスを提供します。グローバル ロック、意思決定キャンペーン、分散セッションなど。

SpringBoot は個々のマイクロサービスの迅速で便利な開発に重点を置いており、SpringCloud はグローバル サービス ガバナンス フレームワークに重点を置いています。

Spring Boot は、Spring Cloud なしで独立して実行できるプロジェクトまたはモジュールを直接作成できます

Spring Cloud は Spring Boot をベースに実装されており、Spring Boot から独立して実行するどころか、プロジェクトやモジュールを独立して作成することはできません。

Spring CloudとSpring Boot対応バージョンの対応関係は以下の通りです（ Spring Cloud公式サイト参照）

3. Spring Cloud Netflix のアーキテクチャ図

サービス プロバイダー: サービスを公開するサービス プロバイダー

サービス コンシューマ: リモート サービスを呼び出すサービス コンシューマ。

EureKa Server: Service Registry および Service Discovery Center

参考記事

[Java] サービス アーキテクチャの進化のまとめ -- 「The Fenix Project」を読む - herrhu - 博客园

Phoenix Architecture: 信頼性の高い大規模分散システムの構築 | Phoenix Architecture