Spring Cloud の 7 つの主要コンポーネント: 1. サービスの登録方法と登録場所を説明する Eureka コンポーネント; 2. リボン コンポーネント; 3. 宣言 Web サービス クライアントである Feign コンポーネント; 4. Hystrix コンポーネント; 5. 構成コンポーネント; 6. Zuul コンポーネント; 7. バスコンポーネント。
(1) Spring Cloud Eureka
マイクロサービスを使用しています。さまざまな API インターフェイスの呼び出しでは、これらのインターフェイスをどのように生成し、これらのインターフェイスを生成した後にどのように呼び出すのでしょうか?どのように管理すればよいでしょうか？ 答えは Spring Cloud Eureka です。独自に定義した API インターフェイスを Spring Cloud Eureka に登録できます。Eureka はサービスの登録と検出を担当します。Zookeeper を学習したことがある方ならよく理解できると思います。Eureka の役割Eureka システムを構成するコンポーネントには、サービス登録センター、サービス プロバイダー、およびサービス コンシューマが含まれます。
2. 次に、
サービスプロバイダー が登録センターに登録、更新、オフラインサービスなどを行います; 3.
サービスコンシューマー が に報告しますEureka 登録センター はサービス リストを取得し、ローカルに維持します (これは クライアント検出モード ! のメカニズムでもあります); 4. 次に
サービス コンシューマー に従ってEureka Service Registration Center 取得したサービス リストからサービス プロバイダーを選択して、サービスを利用します。
(2) Spring Cloud リボン
Spring Cloud Eureka では、サービスの登録方法、登録場所、サービス コンシューマがサービス プロデューサーからサービスを取得する方法について説明します。ただし、Eureka はサービス プロデューサー、登録センター、およびサービス コンシューマー間の関係を維持するだけであり、実際のサービス コンシューマーは、Spring Cloud リボンを通じてサービス プロデューサーによって提供されるデータを呼び出します。 (1)で、サービスコンシューマが登録センターからサービスプロデューサのサービスリストを取得し、ローカルに保持していると述べましたが、このようにクライアント発見モードを利用することで、サービスコンシューマは適切なものを選択することができます。ノードはサービス プロデューサーによって提供されたデータにアクセスし、適切なノードを選択するこのプロセスは Spring Cloud リボンによって完了します。 Spring Cloud リボン クライアント ロード バランサーはこれに由来します。(3) Spring Cloud Feign
上記(1)と(2)では、最も簡単な方法で登録の検出とサービスの呼び出しを実現しました。操作、特にリボンを使ってサービスを呼び出す場合、リボンの使い方がまだ少し複雑に感じられるため、Spring Cloud Feign が登場しました。 Spring Cloud Feign は、Web サービス クライアントの作成を容易にする宣言型 Web サービス クライアントです。Feign を使用して、インターフェイスを作成し、それに注釈を付けます。Feign アノテーションと JAX-RS アノテーションを含むプラグイン可能なアノテーション サポートがあり、Feign もプラグ可能なエンコーダとデコーダをサポートし、Spring Cloud は Spring MVC のアノテーションを追加し、Spring Web はデフォルトで HttpMessageConverters を使用し、Spring Cloud は、Ribbon と Eureka が提供する負荷分散された HTTP クライアント Feign を統合します。 これは簡単に理解すると、Spring Cloud Feign の登場により、Eureka と Ribbon が使いやすくなりました。(4) Spring Cloud Hystrix
(1)、(2)、(3)で、サービスの登録と検出に Eureka を使用する方法について学びました。サービスの呼び出しの負荷分散を実装しており、Feign を使用するとコーディングが簡素化できることもわかっています。ただし、これだけでは可用性の高いマイクロサービス アーキテクチャを実現するには十分ではありません。 例: サービスが失敗し、サービスの呼び出し元がサービスが失敗したことを認識していない場合、呼び出しによって発行されたリクエストの数が増加し続けると、最終的には失敗した依存サービスが待機することになります。バックログが最終的に自身のサービスの麻痺につながりました。 Spring Cloud Hystrix は、この状況を解決し、障害のあるサービスへの継続的なアクセスを防ぐように設計されています。 Hystrix の意味は: 回路ブレーカーです。回路ブレーカー自体は、過電流を防ぐために家庭で回路保護に使用されるスイッチング デバイスです。ライン内の電気機器が短絡した場合、回路ブレーカーは障害のある電気機器を切り替えることができます。過負荷、発熱、さらには火災などの重大な結果が発生する可能性があります。(5) Spring Cloud Config
マイクロサービスがそれほど多くなかったときは、さまざまなサービスの構成と管理は比較的単純でしたが、数百または数千のマイクロサービス ノードがある場合、立ち上がると、サービス構成の管理が複雑になります。
分散システムでは、膨大な数のサービスがあるため、サービス構成ファイルの統合管理とリアルタイム更新を容易にするために、分散構成センター コンポーネントが必要です。 Spring Cloud には、分散構成センター コンポーネント Spring Cloud Config があり、構成サービスのメモリ (つまりローカル) に配置される構成サービスをサポートし、リモート Git リポジトリに配置されることもサポートします。 Cpring Cloud Config コンポーネントには、Config Server と Config Client の 2 つの役割があります。
Config Server は、構成属性の保存に使用されます。保存場所には、Git ウェアハウス、SVN ウェアハウス、ローカル ファイルなどが使用できます。Config Client は、サービス属性の読み取りに使用されます。
(6) Spring Cloud Zuul
Spring Cloud Netflix の Eureka を使用して、サービス登録センターとサービス登録を実装します。ディスカバリー、サービス消費とロード・バランシングは、リボンまたはサービス間の Feign を介して実装され、複数のアプリケーション環境の外部構成とバージョン管理は、Spring Cloud Config を介して実装されます。サービス クラスターをより堅牢にするために、Hystrix の融合メカニズムを使用して、マイクロサービス アーキテクチャ内の個々のサービスの例外によって引き起こされる障害の拡大を回避します。
まず、このアーキテクチャで行う必要があるいくつかのこととその欠点について話しましょう:
1. まず第一に、これはステートレス機能を破壊します。サービスの。外部サービスのセキュリティを確保するためには、サービスへのアクセスに対する権限制御を実装する必要がありますが、オープン サービスの権限制御メカニズムは、オープン サービス全体のビジネス ロジックに侵入し、汚染してしまいます。これがもたらす最も直接的な問題は、クラスター内の REST API のステートレス特性。具体的な開発やテストの観点からは、作業中の実際のビジネスロジックを考慮することに加えて、インターフェースアクセスの追加の持続可能な制御処理も必要になります。
2. 次に、既存のインターフェイスを直接再利用することはできません。既存のクラスター アクセス インターフェイスから外部サービスにアクセスする必要がある場合、元のインターフェイスに検証ロジックを追加するか、プロキシ呼び出しを追加して権限制御を実装する必要があり、元のインターフェイスを直接再利用することはできません。
上記のような問題に直面した場合、どのように解決すればよいでしょうか?それでは、この記事のメイントピックであるサービスゲートウェイにいきましょう。
上記の問題を解決するには、サービス ユニットから権限制御などを抽出する必要がありますが、これらのロジックに最適な場所は外部アクセスのフロントエンドです。強力な負荷分散デバイスは、この記事で今後紹介するサービス ゲートウェイです。
サービス ゲートウェイは、マイクロサービス アーキテクチャの不可欠な部分です。サービスゲートウェイを介して外部システムにREST APIを一元提供する際に、サービスルーティングや負荷分散機能に加え、権限制御などの機能も備えています。 Spring Cloud Netflix の Zuul はそのような役割を果たし、マイクロサービス アーキテクチャにフロントドア保護を提供すると同時に、アクセス許可制御のより重い非ビジネス ロジック コンテンツをサービス ルーティング レベルに移行します。高い再利用性とテスト容易性。
(7) Spring Cloud Bus
(5) Spring Cloud Config では、既知の設定ファイルは Config Server を通じて Git やその他の場所に保存できます。 Config Client はそれを読み取りますが、構成ファイルは常に変更されないままであるとは限りません。構成ファイルが変更されたときに更新するにはどうすればよいですか?
最も簡単な方法は、Config Client を再取得することですが、Spring Cloud ではこれを行うことはできません。Spring Cloud Bus は、サービスをシャットダウンせずにサービスを再取得できる操作を提供します。私たちの構成。
Spring Cloud Bus 正式な意味: メッセージ バス。
もちろん、サービス構成を動的に更新することはメッセージ バスの 1 つの用途にすぎず、他にも多くの用途があります。
Spring Cloud にはこれら以外にも多くのコンポーネントがあります。上記の口頭での説明を通じて、おおよその内容を理解できるはずです。理解していますが、各コンポーネントの機能は上で紹介したものよりもはるかに多く、各コンポーネントには他にも多くの機能点があります。ここでの紹介が入門として役立ち、マイクロサービスのような大きな概念を恐れないようにしていただければ幸いです。
プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 ！
以上がSpring Cloud の 7 つの主要コンポーネントは何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
