springcloud--簡単な方法でのeurekaサービスガバナンス

現在、分散はインターネットアーキテクチャの最初の選択肢です。分散型では、CAPと呼ばれる三者理論があります

略語	フルネーム	説明
C	一貫性	データの整合性
A	可用性	可用性、パフォーマンス
P	パーティションの許容範囲	パーティションの許容範囲

今日は、分散型のサービスガバナンスのサービスについて見ていきます。

サービスガバナンスとは

• 複数のサービスが相互に呼び出すと、それらは断片化され、管理が面倒になります。呼び出し先が変更を加える場合、呼び出し元の変更が含まれる場合があります。そのため、サービスガバナンスが生まれました。

• Spring CloudのEurekaは、サービス登録、サービス呼び出し、負荷分散、およびフォールトトレランスを実装しています。これは、サービス管理モジュールの一般的な機能でもあります。

• eurekaの見解では、サービス登録とサービス呼び出しはどちらもクライアントです。eurekaサービスはサーバー側です。つまり、彼は典型的なCSアーキテクチャです。eurekaクライアントは、eurekaサービスでハートビートメカニズムを維持する必要があります。このように、eurekaサービスは、クライアントがダウンしていないと見なします。

• 上記のアーキテクチャ図は、eurekaサーバーをクラスター化でき、サービスプロバイダーをクラスター化できることを明確に示しています。クライアントをクラスター化する必要はありません。クラスタリングでさえ、eurekaサービスのスタンドアロンコンシューマーです。

ユーレカ通話プロセス

• サービスプロバイダーが起動すると、独自のサービスの情報がカプセル化され、eurekaレジストリに登録されます。サービス利用者はプロバイダーの名前を登録し、登録センターに行って実際の住所を見つけて電話をかけます。

• サービスプロバイダーの管理者は、サービスコンシューマーのためにサービスプロバイダーの特定の情報を知る必要はありません。あなたはサービスプロバイダーの登録名を知っている必要があるだけです。クラスター化された後は、プロバイダーの特定の呼び出し元アドレスについて心配する必要はありません。負荷分散もeurekaによって配布されています。私たちのクライアントは、インターフェースの呼び出しにのみ責任があります。

ユーレカスタンドアロン登録

Eurekaスタンドアロンスタートアップ

• ここでは、他の春の説明は行いません。詳細については、gitブランチの詳細なコードを参照してください。

ソースコードをダウンロードするには、私をクリックしてください

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

• 新しく作成したプロジェクトのpomファイルに上記のgvaを追加します。Eurekaサーバー機能が注入されます。以下では、それを開始するためにいくつかの構成を追加する必要があるだけです。

• 依存関係を追加した後、springbootプロジェクトのymlに次の構成を追加します

eureka:
  instance:
    hostname: localhost
  client:
    register-with-eureka: false #表示该模块作为eureka服务，自己是不需要想自己注册的，注册了只是徒增烦恼
    fetch-registry: false # 表示自己就是注册中心。自己是管理者不是被管理者。
    service-url:
      defaultZone: http://${
    
    eureka.instance.hostname}:${
    
    server.port}/eureka/

• 最後に、spiringbootスタートアップクラスでeurekaserverを起動します。@EnableEurekaServer

• アクセスできるということは、ユーレカサービスが正常に開始されたことを示しています。現在、クライアントは登録されていません。これで、DSレプリカリストが空であることがわかります。

スタンドアロン登録

• 上記では、スタンドアロンマシンでeurekaサービスを開始しました。サービス登録が可能かどうか見てみましょう。例として支払いモジュールを取り上げました。

• pomにクライアント座標を追加する

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

• アドレスをymlで入力します

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://localhost:7001/eureka

• メインのスタートアップクラスにアノテーションを追加する@EnableEurekaClient

クラスター登録

• 今、私たちは登録するためにさらにいくつかの支払いを開きます

• 私たちはアイデアで開発しているからです。jarパッケージとしてマークされていません。また、ここのアイデアを通じて直接コピーされた支払いプロジェクトをデバッグするのに便利です。

• それでは、地元のアイデアスタートアッププロジェクトの状況を見てみましょう。すでに8001、8002の2つの支払いがあります。

• これで、eurekaサービスに8001,8002が表示されます。

カスタマーコール

• 機能/クラウドの注文モジュールがどのように支払いを呼び出すかを覚えていますか？はい、resetTemplateを介してhttp経由で呼び出します。今でも彼を介して電話をかけていますが、発信先はユーリカでの支払いで登録されたサービス名です。

• ここでクライアントを登録する方法は、支払い構成と同じです。支払いは注文によって呼び出されますが、支払いと注文は両方ともeurekaのクライアントであるためです。したがって、構成は同じです。

• スタンドアロンのeurekaに、スタンドアロンの注文サービスとクラスター支払いサービスが表示されます。以下では、注文が支払いを呼び出す場所に次の変更を加えます

• 通話と住所のみが変更されています。もちろん、restTemplateが負荷分散をサポートしていることが前提です。

• 読者は以下の結果をテストできます。http://localhost/order/getpayment/123このインターフェースを複数回呼び出します。返された結果のサービスポートは、常に8001と8002の間で切り替わることがわかります。restTemplateはデフォルトでポーリングされるためです。ここで、支払いは2つのサービスを提供します。ここで、eurekaスタンドアロンバージョンのサービス登録と呼び出しを実現しました

ユーレカクラスター登録

• 上記はスタンドアロンのユーロクです。eurokeクラスターを構成する方法を見てみましょう。eurekaクライアントがeurekaクラスターに登録するのは非常に簡単です。

eureka:
  client:
    register-with-eureka: true
    fetch-registry: true
    service-url:
      defaultZone: http://localhost:7001/eureka,http://www.eureka2/eureka

• 上記のようにdefaultZoneの直後にeurekaサービスを追加するだけです。通常のクラスターは、異なるマシンに配置されます。したがって、ドメイン名またはIPは異なります。リーダーが1台のマシンにデプロイする場合、nginxを介して異なるドメイン名に異なるサービスを割り当てることができます。eurekaサーバーでの設定にはドメイン名が必要なためです。

• クライアントは直接追加されます。eurekaサーバーへの変更はそれほど多くありません。ホスト名を一意に構成するだけで済みます。

eureka:
  instance:
    hostname: www.zxhtom1.com    #eureka服务端的实例名字
  client:
    register-with-eureka: false    #表识不向注册中心注册自己
    fetch-registry: false   #表示自己就是注册中心，职责是维护服务实例，并不需要去检索服务
    service-url:
      defaultZone: http://eureka7002.com:7002/eureka/ 

• したがって、スタンドアロンのデプロイメントクラスターの場合は、nginxを介して転送する必要があります。ここでは詳しく説明しません

同じプロジェクトを複数回開始する方法を考えます

• クラスターをデプロイする際のデモンストレーションの便宜のために、今だけです。アイデアの助けを借りて、複数のインスタンスを開始します。その中に異なるポートを割り当てます。ただし、eurekaクラスターをデプロイすることはできません。構成ファイルの内容を変更する必要があるためです。起動時に外部設定ファイルを指定できます

ユーレカの自己防衛

なぜ身を守るのか

• 上記では、8002回の支払いが2回あることがわかりました。なぜそんな奇妙な問題があるのですか？調査の結果、私は最初のアイデアから8001、8002を始めたことがわかりました。次に、外部構成ファイルを導入して8002を再起動しました。この時点で、元の8002インスタンスは実際に停止しています。この時点で、eurekaは、クライアントの50％が時間どおりにハートビートを送信していないと考えます。50 <85現時点では、eurekaは、ネットワークの変動により、多数のクライアントが時間内に応答しない可能性があると考えています。eurekaは自己防衛メカニズムを開きます。
• 上記は否定的な例ですが。また、自己保護が必要な理由についても正確に説明しています。現時点では、ネットワークの遅延のために8002が他のマシンで追い出され、不当、誤った、間違ったケースが発生します。したがって、これは、上記の8002が2つある理由も説明しています。

自己防衛をオンにする方法

• 自己保護機能はデフォルトでオンになっています。eureka.server.enable-self-preservation: falseこのプロパティでfalseを設定して、自己保護をオフにします。

自己防衛をアクティブにする方法

• 実際、上記の2つの8002は事故です。誤って自己防衛を引き起こしました。

• 自己保護メカニズムの条件：最後の1分間に受信されたハートビートの数は、スレッド全体の85％未満です。

• 85％未満は、ハートビート回復用の指定されたアクティブな番号がないことを意味するため、ネットワークが変動していると見なされます。

• 自己防衛のしきい値=更新（最後の分）/更新（しきい値）

• 計算により、75％であることがわかります。通常の8002を数えない場合。それは50％です。したがって、何があっても、それは自己防衛を引き起こします。

• 自己防衛は、冒頭で述べたCAP定理の理論Aも満たしています。eurekaは高可用性の原則を満たしています。クライアントがダウンしている場合でも滞在します。殺すよりも長く滞在するほうがいいです。これにより、データの不整合が発生します。

上記のソースコード

ダウンロードするには私をクリックしてください