Spring Cloud: Spring Cloud のマイクロサービスとコアコンポーネント

モバイル 2023-08-02 01:33:07 訪問数: null

Spring Cloud: Spring Cloud のマイクロサービスとコアコンポーネント

記事ディレクトリ

マイクロサービス フレームワークの概要

Spring Cloud フレームワークに入る前に、いくつかの基本概念を学ぶ必要があります。まず、マイクロサービスとは何かを知る必要があります。次に、日常生活でマイクロサービス内のサービスにリモート呼び出しを行うにはどうすればよいかを理解する必要があります。

マイクロサービス

序章：

マイクロサービス アーキテクチャは、一連の小規模サービスを使用して単一のアプリケーションを開発する方法またはアプローチです。各サービスは、単一のビジネス機能に基づいて構築され、独自のプロセスで実行され、軽量のメカニズム (通常は HTTP API) を使用して通信します。 pass 独立してデプロイするための自動デプロイメント メカニズム。これらのサービスは、さまざまなプログラミング言語やさまざまなデータ ストレージ テクノロジを使用して実装でき、集中管理を最小限に抑えることができます。

構造図:

ここに画像の説明を挿入

注: API ゲートウェイはサーバーであり、システムへの唯一の入り口です。ゲートウェイは、RESTful/HTTP アクセス サービスを提供します。サーバーは、サービス登録センターを通じてサービスを登録および管理します。

特徴：

  • 単一の責任: マイクロサービス内の各サービスは固有のビジネス機能に対応し、単一の責任を実現します。
  • サービス指向: サービス指向とは、各サービスがサービス インターフェイス API を外部に公開する必要があり、サービスの技術的な実装を気にしないため、プラットフォームと言語が独立しており、内容に制限がないことを意味します。 REST インターフェースが提供されている限り、実装にはテクノロジーが使用されます。
  • 自律性: サービスは互いに独立しており、互いに干渉しません。
    • チームの独立性: 各サービスを独立した開発チームにすることができます。
    • テクノロジーの独立性: サービス指向であるため、対応する REST インターフェイスが提供されている限り、どのテクノロジーを使用するかは重要なポイントではありません
    • フロントエンドとバックエンドの分離: フロントエンドとバックエンドを個別に開発し、統一された REST インターフェイスを提供し、バックエンドは PC とモバイル用に異なるインターフェイスを開発する必要がありません。
    • データベースの分離: 各サービスは相互に干渉することなく独自のデータ ソースを使用します。

要約:

マイクロサービスの特性を通じて、端末がマイクロサービス プロジェクトにアクセスすると、マイクロサービス プロジェクトは API ゲートウェイを介して対応する REST インターフェイスと照合し、対応するサービスに入り、機能を実現することがわかります。マイクロサービス内の各サービスは独立して独自の処理を行います。マイクロサービス フレームワークは、さまざまなサービスをプロジェクトに統合してさまざまな機能を実現するアグリゲーターに相当し、各機能は互いに干渉することなく比較的独立しています。疎結合開発標準であるだけでなく、プロジェクトの拡張と保守も容易になります。

リモート通話方法

マイクロサービスでは、サービスはリモート呼び出しを通じて全体として接続されます。

一般的なリモート呼び出し方法は次のとおりです。

  • RPC: Remote Procedure Call リモート プロシージャ コール。RMI に似ています。ネイティブ TCP 通信に基づくカスタム データ形式、高速かつ効率的。初期の Web サービスと人気のある Dubbo は RPC の典型です。
  • HTTP: HTTP は実際には、データ伝送の形式を指定する TCP に基づくネットワーク伝送プロトコルです。現在、クライアントのブラウザとサーバーは基本的に通信に HTTP プロトコルを使用します。リモート サービス呼び出しにも使用できます。欠点は、メッセージ パッケージが肥大化することです。現在、人気の REST スタイルが HTTP プロトコルを通じて実現できるようになりました。

RPC

RPC、またはリモート プロシージャ コール (リモート プロシージャ コール) は、コンピュータ通信プロトコルです。このプロトコルを使用すると、プログラマがこの対話のために追加のプログラムを作成することなく、あるコンピュータ上で実行されているプログラムが別のコンピュータ上のサブルーチンを呼び出すことができます。もっと簡単に言うと、コンピュータ A はサービスを提供し、コンピュータ B はローカル サービスを呼び出すのと同じようにコンピュータ A のサービスを呼び出すことができます。

RPC リモート呼び出しのフローチャートは次のとおりです。

ここに画像の説明を挿入

ここに画像の説明を挿入

概要:
上の 2 つの図からわかるように、RPC リモート呼び出しでは、クライアントとサーバーは通信する必要があるデータをシリアル化し、Socket を介してネットワーク経由で通信し、結果データを受信して​​返します。逆シリアル化による結果です。

HTTP

HTTP は実際には、TCP に基づいたネットワーク伝送プロトコルであり、アプリケーション層で動作し、データ伝送の形式を指定します。現在、クライアントのブラウザとサーバーは基本的に通信に HTTP プロトコルを使用しており、リモート サービスの呼び出しにも使用できます。欠点は、メッセージ パッケージが肥大化することですが、利点は、サービス プロバイダーと呼び出し元に技術的な制限がなく、自由で柔軟であり、マイクロサービスの概念により近いことです。現在、人気の REST スタイルが HTTP プロトコルを通じて実現できるようになりました。

ここに画像の説明を挿入

述べる：

  • RPC はネットワークに基づくアプリケーションではなく、言語の API に従って定義されるためです。したがって、マイクロサービス アーキテクチャ全体が実装に同じテクノロジ スタック (例: Java) を使用する場合、Dubbo は優れたマイクロサービス アーキテクチャになる可能性があります。
  • 使用されるテクノロジー スタックが均一でない場合は、マイクロサービス アーキテクチャを構築するのに Spring Cloud が適しています。現時点では、サービス間の呼び出しの実装には HTTP が使用されます。

Spring Cloud の概要

序章：

Spring CloudはSpring傘下のプロジェクトの一つで、主にマイクロサービスの機能を提供する。

Spring が最も得意とするのは統合であり、世界最高のフレームワークを採用し、それを独自のプロジェクトに統合します。

同じことが Spring Cloud にも当てはまります。Spring Cloud は、いくつかの非常に人気のあるテクノロジーを統合し、構成管理、サービス検出、インテリジェント ルーティング、負荷分散、ヒューズ、制御バス、クラスター ステータスなどの機能を実装します。

関係する主なコンポーネントは次のとおりです。

ネットフリックス

  • エウレカ：レジストリ
  • ズール: サービス ゲートウェイ
  • リボン: 負荷分散
  • Feign: サービス呼び出し (動的プロキシ)
  • ハイストリックス: ヒューズ

春の雲

  • ゲートウェイ: Spring ファミリによって自社開発され、フレームワークに統合されたサービス ゲートウェイ
  • 構成: 分散構成センター

アーキテクチャ図は次のとおりです。

ここに画像の説明を挿入

バージョン：

Spring Cloud には複数のバージョンがあり、各バージョンは異なる SpringBoot バージョンに対応するため、プロジェクトで Spring Cloud を使用するときは、原因による不要なエラーを避けるために、pom.xml ファイル内の対応する SpringBoot バージョンに注意する必要があります。バージョンの不一致の間違い。

Spring Cloud のバージョン名は、主にイギリスのロンドンの地下鉄駅の名前に対応しています。

ここに画像の説明を挿入

Spring Cloud と Spring Boot のバージョンの対応:

リリーストレイン ブートバージョン
ホクストン 2.2.x
グリニッジ 2.1.x
フィンチリー 2.0.x
エッジウェア 1.5.x
ダルストン 1.5.x

Spring Cloud コアコンポーネント

Spring Cloud には、登録センター、ロード バランシング、サーキット ブレーカー、サービス ゲートウェイ、分散コンフィギュレーション センターの 5 つのコア コンポーネントがあり、このうちサービス ゲートウェイは、例として Spring Cloud フレームワークのゲートウェイによって主に導入されます。

レジストリ- Netflix エウレカ

負荷分散- Netflix リボン

サーキットブレーカー- Netflix Hystrix

サービスゲートウェイ- Spring Cloud Gateway (Netflix Zuul)

分散構成センター- Spring Cloud Config

さらに、さらに 2 つの重要なコンポーネントが追加されています。

動的プロキシ- Feign
Service Bus - Spring Cloud Bus

レジストリエウレカ

序章：

各サービスが開始されると、Eureka Client はそのサービスを Eureka Server に登録します。Eureka Client は、他のサービスがどこにあるかを知るために、Eureka Server から順番にレジストリを取得することもできます。Eureka クライアントにはサービス プロバイダーとサービス呼び出し元が含まれており、Eureka はサービス プロバイダー情報の管理と記録を担当します。サービスの発信者は自分でサービスを探す必要はなく、自分のニーズをエウレカに伝えると、エウレカがニーズに合ったサービスを教えてくれます。

同時に、サービスプロバイダーとEurekaは「ハートビート」メカニズムによって監視されており、サービスプロバイダーに問題が発生すると、Eurekaはサービスリストからそのサービスを自然に削除します。

これにより、サービスの自動登録、検出、ステータス監視が可能になります。

回路図:

ここに画像の説明を挿入

  • ユリイカ: これはサービス レジストリ (クラスターの場合もあります) であり、そのアドレスを外部に公開します。
  • プロバイダー：起動後にエウレカに自身の情報（住所、提供するサービス）を登録
  • 消費者: Eureka に登録すると、Eureka は対応するサービスのすべてのプロバイダー アドレスのリストを消費者に送信し、定期的に更新します。
  • ハートビート (更新): プロバイダーは、HTTP 経由で定期的にステータスを Eureka に更新します。

インフラストラクチャー：

Eureka アーキテクチャにおける 3 つの中心的な役割:

  • サービスレジストリ

    サービスの登録と検出機能を提供する Eureka のサーバー アプリケーションは、今回設立した eureka-server です

  • サービスプロバイダー

    サービスを提供するアプリケーションは、外部に REST スタイルのサービスを提供する限り、Spring Boot アプリケーションにすることも、他のテクノロジで実装することもできます。

  • サービス消費者

    消費者アプリケーションは、各サービス プロバイダーの情報を知り、どこにサービス プロバイダーに電話すればよいかを知るために、登録センターからサービス リストを取得します。

高可用性 Eureka サーバー:

序章：

  • Eureka は単一の Eureka またはクラスターになります。Eureka がクラスターの場合、それを高可用性 Eureka センターと呼びます。
  • いわゆる高可用性登録センターは、実際には EurekaServer 自体をサービスとして登録するため、複数の EurekaServer が相互に検出してクラスターを形成できます。
  • Eureka Server は、Eureka Server の高可用性を確保するために複数のインスタンスを起動 (異なるポートを構成) できる Web アプリケーションです。

サービスの同期:

複数の Eureka Server もサービスとして相互に登録されます。サービス プロバイダーが Eureka Server クラスター内のノードに登録すると、そのノードはクラスター内の各ノードにサービス情報を同期して、データ同期を実現します。したがって、クライアントが Eureka Server クラスター内のどのノードにアクセスしても、完全なサービス リスト情報を取得できます。

クライアントとして各エウレカに情報を登録する必要があります

Eureka が 3 つある場合、各 EurekaServer を他のいくつかの Eureka サービスに登録する必要があります。

たとえば、それぞれ 10086、10087、10088 が 3 つある場合、次のようになります。

10086は10087と10088に登録する必要があります

10087は10086と10088に登録する必要があります

10088は10086と10087に登録する必要があります

高可用性エウレカ抽象マップ:
ここに画像の説明を挿入

実際のアプリケーションのレンダリング:

ここに画像の説明を挿入

Eureka クライアントとサーバーの構成:

  • エウレカクライアントプロジェクト
    • ユーザーサービスサービスプロバイダー
    • サービスアドレスはip方式を使用します
  • 更新するために
    • 消費者向けデモサービスの利用
    • サービスのアドレスを取得する頻度
  • エウレカサーバープロジェクト eureka-server
    • 失敗の拒否
    • 自己防衛

サービス提供者は、EurekaServerにサービスを登録し、サービスの更新などの作業を行う必要があります。

サービス登録

サービス プロバイダーが起動すると、構成プロパティのパラメーター eureka.client.register-with-erueka=true が true であるかどうかが検出されます。実際、デフォルトでは true です。値が実際に true の場合、独自のメタデータ情報を使用して EurekaServer に対する REST リクエストが開始され、EurekaServer はこの情報を 2 層の Map 構造に保存します。

  • Map の最初の層のキーはサービス ID です。これは通常、構成、user-service 内の spring.application.name 属性です。
  • 2 番目のレイヤーのマップのキーは、サービスのインスタンス ID です。一般的なホスト + サービス ID + ポート (例: localhost:user-service:8081)
  • 値はサービス、つまりサービスのインスタンス オブジェクトであるため、複数の異なるインスタンスを同時に起動してクラスターを形成できます。

デフォルトでは、登録にはホスト名またはローカルホストが使用されますが、IP で登録したい場合は、次のように user-service に設定を追加できます。

eureka: 
  instance: 
    ip-address: 127.0.0.1 # ip地址 
    prefer-ip-address: true # 更倾向于使用ip，而不是host名

サービスのリニューアル：

登録サービスが完了すると、サービス プロバイダーはハートビートを維持し (定期的に EurekaServer への REST リクエストを開始します)、EurekaServer に「私はまだ生きています」と伝えます。これをサービスの更新 (更新) と呼びます。

サービス更新の動作を変更するには 2 つの重要なパラメータがあり、次の構成項目を user-service に追加できます。

eureka: 
  instance: 
    # 服务续约(renew)的间隔，默认为30秒 
    lease-expiration-duration-in-seconds: 90
    # 服务失效时间，默认值90秒 
    lease-renewal-interval-in-seconds: 30

つまり、デフォルトでは、サービスは 30 秒ごとにハートビートをレジストリに送信して、サービスがまだ生きていることを証明します。90 秒以上ハートビートが送信されない場合、EurekaServer はサービスがダウンしていると判断し、サービス リストから削除されます。これら 2 つの値は本番環境では変更しないでください。デフォルトのままで問題ありません。

サービスリストの取得

サービス コンシューマが起動すると、eureka.client.fetch-registry=true パラメータの値が検出され、それが true の場合、Eureka Server サービスのリストから読み取り専用のバックアップが取得され、ローカルにキャッシュされます。 。データは 30 秒ごとに再取得され、更新されます。これは、consumer-demo プロジェクトの次のパラメーターによって変更できます。

eureka: 
  client: 
    # 重新拉取服务的时间
    registry-fetch-interval-seconds: 30

失敗の拒否と自己保護

次の構成は、Eureka Server サーバー側で実行されます。

オフラインサービス

サービスが通常のシャットダウン操作を実行すると、サービスをオフラインにするための REST リクエストが Eureka Server に対してトリガーされ、サービス登録センターに「オフラインになります」と通知されます。リクエストを受信した後、サービス センターはサービスをオフラインにします

失敗の拒否

メモリ オーバーフローやネットワーク障害により、サービスが正常に動作しない場合がありますが、サービス登録センターは「サービス オフライン」リクエストを受信して​​いません。サービス プロバイダーの「サービス更新」操作と比較すると、サービス レジストリは起動時に時間指定タスクを作成し、現在のリストのタイムアウト (デフォルトでは 90 秒) はデフォルトでは更新されません。無効化カリングと呼ばれます。これは、eureka.server.eviction-interval-timer-in-ms パラメーターによってミリ秒単位で変更できます。

自己防衛

サービスをシャットダウンすると、Eureka パネルに赤い文字の警告が表示され、Eureka の自己保護メカニズムがトリガーされます。サービスが時間どおりにハートビートを更新できない場合、Eureka は、過去 15 分間にハートビートが失敗したサービス インスタンスの割合が 85% を超えているかどうかをカウントします。EurekaServer ノードが短期間に多くのクライアントを失った場合 (ネットワークの分断)、故障の可能性があります）。運用環境では、ネットワークの遅延やその他の理由により、ハートビート障害インスタンスの割合が標準を超える可能性がありますが、サービスが停止していない可能性があるため、現時点でサービスをリストから削除するのは適切ではありません。Eureka は現在のインスタンスの登録情報を保護し、削除しません。これは実稼働環境でもうまく機能し、ほとんどのサービスが引き続き利用できるようになります。

開発中は、自己テストを容易にするために、通常、自己保護はオフになります。

負荷分散リボン

序章：

  • サービス間でリクエストが発生した際に、リボンに基づいて負荷分散を行い、サービスを構成する複数のマシンの中から適切なマシンを選択してサービスを実行することを負荷分散といいます。
  • リボンは主にクライアント側のソフトウェア イコライゼーション アルゴリズムを提供します。
  • リボン クライアント コンポーネントは、接続タイムアウト、再試行、再試行アルゴリズムなどの一連の包括的な構成オプションを提供します。リボンには、プラグイン可能でカスタマイズ可能な負荷分散コンポーネントが組み込まれています。

回路図:
ここに画像の説明を挿入

負荷分散戦略:

  • シンプルなラウンドロビン負荷分散
  • 加重応答時間負荷分散
  • ゾーン対応のラウンドロビン負荷分散 (デフォルトではラウンドロビン戦略が使用されます)
  • ランダムな負荷分散

実現方法：

リボンはすでに Eureka に統合されているため、新しい依存関係を導入する必要はありません。@LoadBalanced アノテーションを RestTemplate の構成メソッドに直接追加します。

@Bean 
@LoadBalanced 
public RestTemplate restTemplate() { 
	return new RestTemplate(); 
}

負荷分散ポリシーを変更する方法:

# 默认为轮询负载均衡，修改为随机负载均衡
user-service: 
  ribbon: 
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

ブレイカー・ヒストリックス

序章：

Hystix は、Netflix がオープンソース化した遅延およびフォールト トレランス ライブラリであり、リモート サービスへのアクセスを分離し、連鎖的な障害を防ぐために使用されます。

リクエストは Hystrix のスレッド プールを通じて開始され、異なるサービスは異なるスレッド プールを使用するため、異なるサービス呼び出しの分離が実現され、サービス雪崩の問題が回避されます。

原理：

基本的に、サービス呼び出し間の関係は次のとおりです (マイクロサービスでは、ビジネス リクエストは 4 つのサービス A、H、I、P を呼び出します)。

すべてのマイクロサービスが正常に実行されている場合、応答の受信後にリクエストは正常に終了し、スレッドが解放されます。

ここに画像の説明を挿入

この時点で、マイクロサービス I に問題があり、リクエストが応答されなくなりました。

ここに画像の説明を挿入

マイクロサービス I で例外が発生し、リクエストはブロックされ、ユーザー リクエストは応答されないため、Tomcat のスレッドは解放されず、ますます多くのユーザー リクエストが到着し、ブロックされるスレッドが増えます。

ここに画像の説明を挿入

サーバーによってサポートされるスレッドの数と同時実行性は制限されており、リクエストは常にブロックされるため、サーバーのリソースが枯渇し、他のすべてのサービスが利用できなくなり、雪崩現象が発生します。

解決：

Hystrix が雪崩問題を解決する手段は主に次のとおりです。

  • スレッドの分離
  • サービスのダウングレード

スレッドの分離

回路図:

ここに画像の説明を挿入

分析します:

  • Hystrix は、依存するサービス コールごとに小さなスレッド プールを割り当てます。スレッド プールがいっぱいの場合、呼び出しはすぐに拒否されます。デフォルトでは、障害判定時間を短縮するためにキューは使用されません。
  • ユーザーのリクエストはサービスに直接アクセスすることはなくなり、スレッド プール内のアイドル スレッドを通じてサービスにアクセスします。スレッド プールがいっぱいになるかリクエストがタイムアウトになると、サービスは低下します。

サービスのダウングレード

利点:
コアサービスを最初に保証できる

ユーザーのリクエストが失敗した場合でも、リクエストはブロックされず、延々と待機したり、システムがクラッシュしたりすることはなく、少なくとも実行結果 (わかりやすいプロンプト メッセージが返されるなど) を確認できます。サービスの低下によってリクエストは失敗しますが、ブロッキングは発生しません。影響を受けるのは、依存するサービスに対応するスレッド プール内のリソースだけであり、他のサービスには応答しません。Hystrix サービスのダウングレードを引き起こす状況:

  • スレッドプールがいっぱいです
  • リクエストはタイムアウトしました

リクエストのタイムアウトのデフォルト時間は 1 秒です。次のコードを使用して構成ファイル内で変更できます。

# 默认超时时长为1S，修改为2S
hystrix:
  command:
    default: 
      execution: 
        isolation:
          thread:
            timeoutInMilliseconds: 2000

サービスサーキットブレーカー

原理：

サービスヒューズにおいて使用されるヒューズはサーキットブレーカーとも呼ばれ、英語ではCircuit Breakerとなります。分散システムでアプリケーション サービスを融合した後、サービスの呼び出し元は、どのサービスの応答が遅いか、またはタイムアウトが多いかを判断し、これらのサービスを積極的に融合してシステム全体のダウンを防ぐことができます。

Hystrix のサービス融合メカニズムは、柔軟なフォールト トレランスを実現でき、サービス リクエストの状況が改善すると、自動的に再接続できます。サーキット ブレーカーによって、フォローアップ リクエストは直接拒否され、一定期間 (デフォルトは 5 秒) の後に一部のリクエストの通過が許可されます。呼び出しが成功すると、サーキット ブレーカーはクローズ状態に戻ります。は引き続きオープンし、要求されたサービスを拒否します。

回路図:

ここに画像の説明を挿入

ステート マシンの 3 つの状態:

  • Closed : クローズ状態 (サーキットブレーカーが閉じている)、すべてのリクエストに正常にアクセスできます。
  • オープン: オープン状態 (サーキット ブレーカーが開いている) では、すべてのリクエストがダウングレードされます。Hystrix はリクエストのステータスをカウントし、一定時間内に失敗したリクエストの割合がしきい値に達すると、ヒューズが作動し、サーキット ブレーカーが完全に開きます。デフォルトの失敗率のしきい値は 50% で、リクエストの数は少なくとも 20 である必要があります。
  • 半開: 半開状態。永続的ではなく、サーキットブレーカーが開いた後、スリープ時間に入ります (デフォルトは 5 秒)。サーキットブレーカーは自動的に半開状態になります。この時点で、いくつかのリクエストが解放されて通過します。これらのリクエストが正常であればサーキット ブレーカーは閉じられ、そうでない場合は開いたままとなり、スリープ タイマーが再度実行されます。

ヒューズのパラメータを設定します。これは構成ファイルで変更できます。

hystrix: 
  command: 
    default:
      circuitBreaker: 
        errorThresholdPercentage: 50 		# 触发熔断错误比例阈值，默认值50% 
        sleepWindowInMilliseconds: 10000 	# 熔断后休眠时长，默认值5秒 
        requestVolumeThreshold: 10			# 熔断触发最小请求次数，默认值是20

動的プロキシ偽装

序章：

  • Feign は宣言型 Web サービス クライアントであり、コントローラーがサービスを呼び出す方法と同様に、マイクロサービス間の呼び出しを簡単にします。

  • Feign の動的プロキシ メカニズムに基づいて、アノテーションと選択されたマシンに従って、リクエスト URL アドレスを結合し、リクエストを開始し、URL アドレスの動的プロキシ機能を実現します。

  • Feign はリボン負荷分散と Hystrix を自動的に統合しているため、Feign ダイナミック プロキシを構成するときに、構成ファイルを直接変更して次のことを実現できます。

Feign の依存関係を導入することで、Ribbon と Hystrix を使用できるようになります。

<dependency> 
	<groupId>org.springframework.cloud</groupId> 
	<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

実装原則:

@FeignClient (value="user-service") アノテーションを付けてクライアント client を作成し、コントローラー クラスでクライアント client を呼び出し、コントローラー クラスを呼び出してユーザーを実装するときに、コントローラー クラスでカスタム リクエスト アドレスを使用します。サービス機能を使用する場合、ダイナミックプロキシ機能を使用する場合。

つまり、実際のアクセスアドレスを使用せずに所望のサービスにアクセスすることができ、プロキシアドレスを使用することで動的にサービスにアクセスする機能が実現される。

Feign での負荷分散

Feign にはデフォルトでリボン負荷分散機能が組み込まれており、設定ファイルを通じて負荷分散機能を実現できます。

# 当我们要针对某个服务进行负载均衡的时候，仅需要在ribbon的上级目录中添加相应的服务名即可
ribbon:
  ConnectTimeout: 1000 # 连接超时时长 
  ReadTimeout: 2000 # 数据通信超时时长 
  MaxAutoRetries: 0 # 当前服务器的重试次数
  MaxAutoRetriesNextServer: 0 # 重试多少次服务
  OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试

フェインのヒストリックスを融合する

Feign はヒューズ Hystrix も継承しているため、ヒューズを使用する必要がある場合は、設定ファイルでヒューズ サービスを有効にするだけで済みます。

feign: 
  hystrix:
    enabled: true # 开启Feign的熔断功能

リクエストの圧縮

Spring Cloud Feign は、通信中のパフォーマンス損失を軽減するために、リクエストとレスポンスの GZIP 圧縮をサポートしています。リクエストとレスポンスの圧縮機能は、次のパラメータで有効にできます。

feign: 
  compression: 
    request: 
      enabled: true 	# 开启请求压缩 
      mime-types: text/html,application/xml,application/json 	# 设置压缩的数据类型 
      min-request-size: 2048 	# 设置触发压缩的大小下限
    response：
      enabled: true 	# 开启响应压缩

サービスゲートウェイ ゲートウェイ

序章：

  • Spring Cloud Gateway は、フィルター チェーンに基づいた基本的なゲートウェイ機能 (セキュリティ、監視/埋め込みポイント、電流制限など) を提供します。
  • Spring Cloud Gateway は、マイクロサービス アーキテクチャ向けのシンプルかつ効果的で統合された API ルーティング管理方法を提供します。
  • Spring Cloud Gateway は、Netflix Zuul を置き換えるソリューションのセットです。
  • Spring Cloud Gateway コンポーネントの核となるのは一連のフィルターであり、クライアントから送信されたリクエストはこれを介して対応するマイクロサービスに転送 (ルーティング) できます。Spring Cloud Gateway は、マイクロサービス全体の最前線に追加されるファイアウォールとプロキシであり、マイクロサービス ノードの IP ポート情報を隠し、セキュリティ保護を強化します。Spring Cloud Gateway 自体もマイクロサービスであり、Eureka サービス レジストリに登録する必要があります。

ゲートウェイの役割を簡単に理解すると、フロントエンドがバックエンド システムを呼び出したい場合、すべてのフロントエンド リクエストがゲートウェイから受信され、ゲートウェイはフィルタリング後にリクエストを対応するサービスに転送します。

ゲートウェイの中核機能は次のとおりです: フィルタリングとルーティング

回路図:

ここに画像の説明を挿入

核となるアイデア:

  • ルーティング ( route ) ルーティング情報の構成: ID、宛先 URL、アサーション ファクトリのセット、およびフィルターのセットで構成されます。ルート アサーションが true の場合、リクエスト URL は設定されたルートと一致します。
  • アサーション ( Predicate ) Spring Cloud Gateway のアサーション関数の入力タイプは、Spring 5.0 フレームワークの ServerWebExchange です。Spring Cloud Gateway のアサーション機能を使用すると、開発者はリクエストヘッダーやパラメータなど、HTTP リクエストからの任意の情報に一致するものを定義できます。
  • Filter ( Filter ) 標準の Spring WebFilter。Spring Cloud Gateway のフィルターは、ゲートウェイ フィルターとグローバル フィルターの 2 種類のフィルターに分かれています。フィルター フィルターはリクエストとレスポンスを変更します

コードを直接使用して、ゲートウェイの機能を表示します。

spring：
  application: 
    name: api-gateway 
  cloud: 
    gateway: 
      routes: 
        # 路由id，可以随意写 
        - id: user-service-route 
        # 代理的服务地址（lb表示负载均衡）
        uri: lb://user-service 
        # 路由断言，可以配置映射路径 
        predicates: 
          - Path=/api/user/** 
        filters: 
        # 添加请求路径的前缀 
        - PrefixPath=/user
        # 表示过滤1个路径，2表示两个路径，以此类推 
          - StripPrefix=1
          # 自定义过滤器 
          - MyParam=name 
        # 默认过滤器，对所有路由都生效 
        default-filters: 
          - AddResponseHeader=X-Response-Foo, Bar 
          - AddResponseHeader=myname
        # 跨域配置
        globalcors: 
          corsConfigurations: 
            '[/**]': 
            #allowedOrigins: * # 这种写法或者下面的都可以，*表示全部
            allowedOrigins: - "http://docs.spring.io" 
            allowedMethods: - GET

分析します:

  • ルートIDは自由に記述可能
  • プロキシのサービス アドレスのlb は LoadBanlance を表し、サービス名は負荷分散構成に使用されます。
  • ルーティング アサーション: コードの例を取り上げます。つまり、パス内の /api/user/** で始まるリクエストは、サービス名 user-service と user-service/api の対応するポートにプロキシされます。 /user/** リクエストサービスが実行されます
  • フィルタ(プレフィックス パスの追加と削除): PrefixPath=/user。これは、リクエスト アドレスのフロントエンドにユーザー パス プレフィックスを追加することを意味します。つまり、リクエスト アドレスが user-service/1 の場合、実際にアクセスされるアドレスは次のようになります。 user-service/user/ 1; StripPrefix=1、これは、/api/user/** で始まるリクエストを使用するときに、リクエスト パスの最初のパスを除外することを意味します。たとえば、この例では、 API パスを指定して user-service/user /** service を実行します
  • カスタムフィルターとグローバルフィルター: この例の場合は主に、対応する識別情報をリクエストヘッダーデータに追加します。
  • クロスドメイン構成: allowedOrigins はアクセスを許可されるリクエスト アドレスを示し、allowedMethods はアクセスを許可するリクエスト メソッドを示します。上記のコードと同様に、ゲートウェイは、アドレスが http://docs.spring.io で、リクエスト メソッドが GET であるリクエストの通過のみを許可します。

ゲートウェイ ゲートウェイ フィルターの一般的なアプリケーション シナリオは次のとおりです。

  • 認証の要求: 一般に、GatewayFilterChain がフィルター メソッドを実行する前に、アクセス権がないことが判明した場合は、直接空を返します。
  • 例外処理: 通常、GatewayFilterChain はフィルター メソッドを実行した後、例外を記録して返します。
  • サービスコール期間の統計: GatewayFilterChain は、フィルター メソッドの実行前後の時間に基づいて統計を実行します。

分散構成センターの構成

概要:
構成ファイルを構成サービスのローカルまたはリモートのウェアハウスに配置して集中管理する分散構成コンポーネント。たとえば、application.yml などの構成ファイルをリモート Git ウェアハウスに配置して管理できます。
概略図:
ここに画像の説明を挿入
config 主な構成情報:

spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        #  此处使用的远程仓库为git
        git:
          uri:  				# 仓库地址，根据项目的地址来导入对应的项目
          # 因为仓库为私有，所以此处需要配置用户名和密码
          username:      # 仓库用户名
          password:       # 仓库密码

分散構成センターもマイクロサービスであるため、登録センターに登録する必要があります。
構成センターをセットアップした後、構成ファイルをリモート ウェアハウスに配置する必要がある他のマイクロサービス構成ファイルも変更する必要があります。
手順:

  1. application.yml 構成ファイルをリモート ウェアハウスに転送します。命名形式は application-profile.yml です。
  2. ローカルの application.yml 構成ファイルを削除します。
  3. bootstrap.yml という新しい構成ファイルを作成します。

bootstrap.yml 設定:

# 采用bootstrap.yml配置文件，从git仓库的配置中心中获取对应配置文件，而不在本地进行配置
# bootstrap.yml相较application.yml：bootstrap.yml更常用于系统配置，即基本不进行修改，application.yml更常用于动态调整的配置
spring:
  cloud:
    config:
      # 与git仓库中配置文件的application名一致
      name: user
      # 与git仓库中配置文件的profile名一致
      profile: dev
      # 与git仓库中配置文件存放的分支一致
      label: master
      discovery:
        # 使用配置中心
        enabled: true
        # 配置中心服务名，项目中连接配置中心模块的名称
        service-id: config-server
# 同样需要在注册中心进行注册
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

上記の設定により、Spring Cloud Config 設定センターの設定が完了しました。この設定方法により、リモート ウェアハウスから必要な設定パラメータを静的に取得でき、設定ファイルが毎回変更される場合、変更されたデータを取得できます。ローカルサービスを再起動しないと取得できないため、まだ少し不便です。
リモートウェアハウスで構成ファイルの動的な取得を実現するには、サービスバス Bus と

サービスバス Spring Cloud Bus

序章：

  • Spring Cloud Bus は軽量のメッセージ ブローカーを使用して分散ノードを接続し、構成ファイルの変更やサービスの監視と管理をブロードキャストするために使用できます。つまり、メッセージ バスはマイクロサービスを監視し、アプリケーション間で相互に通信できます。Spring Cloud Bus のオプションのメッセージ ブローカーには、RabbitMQ と Kafka が含まれます。
  • Spring Cloud Busの最下層はRabbitMQをベースに実装されており、デフォルトではローカルメッセージキューサービスが使用されるため、利用する場合はメッセージ形式での情報の動的な更新を実現するために事前にRabbitMQサービスを有効にしておく必要があります。行列。

Spring Cloud Bus バス関数を導入した後のサービス呼び出しの概略図は次のようになります
ここに画像の説明を挿入
。

  • config 構成センター: Spring Cloud Bus と RabbitMQ の依存関係を導入し、構成ファイルを変更し、RabbitMQ パラメーターを追加してメッセージ キュー機能を実現し、メッセージ バスをトリガーするアドレスを公開します。
  • マイクロサービス (ユーザー サービス): Spring Cloud Bus、RabbitMQ、および Spring Boot Actuator の依存関係をインポートし、bootstrap.yml 構成ファイルを変更し、RabbitMQ パラメーターを追加してメッセージ キュー関数のインポート コードを実装します
    。
# config配置文件

spring:
  # 配置rabbitmq信息；如果是都与默认值一致则不需要配置，rabbitmq访问地址为127.0.0.1:15672，此处使用的port只有后四位5672即可
  # 以下配置即为默认配置，可删
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest
management:
  endpoints:
    web:
      exposure:
        # 暴露触发消息总线的地址
        include: bus-refresh

# user-service配置文件

spring：
  # 配置rabbitmq信息；如果是都与默认值一致则不需要配置，rabbitmq访问地址为127.0.0.1:15672，此处使用的port只有后四位5672即可
  # 以下配置即为默认配置，可删
  rabbitmq:
    host: localhost
    port: 5672
    username: guest
    password: guest

上記の設定により、Spring Cloud Bus バス サービスの導入が成功し、メッセージ キュー機能を使用してリモート ウェアハウス内の設定ファイルの動的な取得が実現されました。

Spring Cloud の完全なアーキテクチャ図

ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/xiri_/article/details/113185899
おすすめ
ランキング
Python 描画 3D 動的ヒストグラム コード チュートリアル
[vue3 共通エラー 5] Uncaught (in Promise) TypeError: xxx は関数ではありません
シンプルアップロードExcelファイルやデータベースにデータを追加
springboot における import アノテーションの役割
numpy 多维矩阵的维度交换
WMS システム - ウェーブ管理
Redis（7）マスター/スレーブレプリケーション
三北斗七星星座コアグローバルシステムの導入は完了です！グローバルネットワークを推進するために、
sql server语法——排序查询
続行することはできません立ち往生
アーカイブ
もっと
2024-05-16(24)
2024-05-15(5)
2024-05-14(9)
2024-05-13(8)
2024-05-12(27)
2024-05-11(31)
2024-05-10(33)
2024-05-09(30)
2024-05-08(18)
2024-05-07(34)

コードワールド

© 2018 codetd.com