[解決済み] Spring Cloud Eureka Server の自己保存と更新閾値を理解する

質問

マイクロサービスについては、SpringのドキュメントとNetflixのドキュメントの両方を読んで、しばらく研究してきましたが、私はマイクロサービスを開発するのは初めてです。

私は簡単なプロジェクトを開始しました Githubで公開されている . 基本的にはEurekaサーバ（Archimedes）と3つのEurekaクライアントマイクロサービス（1つはパブリックAPI、2つはプライベートAPI）になっています。詳細な説明はgithubのreadmeを参照してください。

ポイントは、すべてが実行されているときに、プライベートなマイクロサービスの1つが殺された場合、Eurekaサーバーがそれを認識してレジストリから削除することです。

I Stackoverflowでこの質問を見つけました。 で、解決策は enableSelfPreservation:false を使うことで解決しました。これを実行すると、しばらくして期待通り殺されたサービスが消えます。

しかし、以下のようなメッセージが表示されます。

自己保存モードはオフになっています。 の有効期限を保護できない可能性があります。

1. 自己保存の目的は何ですか？その doc に自己保存があることを明記しています。 "client can get the instances that no exist anymore" . では、どのような場合にオン/オフを切り替えるのが望ましいのでしょうか？

さらに、自己保存がオンになっていると、Eureka Serverのコンソールの警告に未解決のメッセージが表示されることがあります。

エマージェンシー! Eureka はインスタンスが稼働しているにもかかわらず、誤って稼働していると主張している可能性があります。 していません。更新がしきい値より少ないため、安全のため 更新が閾値より少ないため、念のため期限切れにならないようにしています。

さて、Spring Eureka Consoleのほうはというと。

Lease expiration enabled    true/false
Renews threshold    5
Renews (last min)   4

Eureka Server単体で起動すると閾値が1になってしまうという、閾値カウントの奇妙な挙動に出くわしたことがあります。

2. Eurekaサーバは1台で、以下の構成になっています。 registerWithEureka: false を使用して、他のサーバに登録できないようにしています。では、なぜ閾値のカウントに表示されるのでしょうか？

3. 私がクライアントを開始するごとに、閾値のカウントが+2増加します。これは、1 分間に 2 つの更新メッセージを送信するためだと思いますが、正しいでしょうか?

4. Eurekaサーバーは更新を送信しないので、最後の最小更新数は常に閾値以下です。これは正常なのでしょうか？

renew threshold 5
rewnews last min: (client1) +2 + (client2) +2 -> 4

サーバーのcfgです。

server:
  port: ${PORT:8761}

eureka:
  instance:
    hostname: localhost
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
  server:
    enableSelfPreservation: false
#   waitTimeInMsWhenSyncEmpty: 0

クライアント1のcfgです。

spring:
  application:
    name: random-image-microservice

server:
  port: 9999

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8761/eureka/
    healthcheck:
      enabled: true

どのように解決するのですか？

私も@codependentさんと同じ質問を受け、いろいろと調べたり実験したりしましたが、ここではEurekaサーバとインスタンスの仕組みについて少し貢献したいと思います。

各インスタンスは、30秒に1回の頻度でEurekaサーバへのリースを更新する必要があります。 eureka.instance.leaseRenewalIntervalInSeconds .

ニュース (最終更新日) : 直前に Eureka インスタンスから受け取った更新の数を表します。

更新の閾値 : Eureka サーバが 1 分間に Eureka インスタンスから受け取ることを期待する更新回数です。

例えば registerWithEureka に設定されている場合 false , eureka.instance.leaseRenewalIntervalInSeconds を30に設定し、Eurekaインスタンスを2台起動します。2台のEurekaインスタンスは 4 の更新を行い、Eurekaサーバの最小閾値は 1 (コードで書かれている)ため、閾値は 5 (となります（この数値に係数 eureka.server.renewalPercentThreshold を掛けたもので、後述します）。

自己保存モード : もし 更新(最終分) が 更新のしきい値 を下回ると、自己保存モードが有効になります。

つまり、上の例では、閾値は5ですが、Eurekaサーバは4更新/分しか受信できないので、SELF PRESERVATION MODEが有効になります。

1. 質問1:

SELF PRESERVATION MODEは、ネットワークの接続不良を回避するために設計されています。EurekaインスタンスAとBの接続は良好だが、BがEurekaサーバへのリース更新に短期間で失敗した場合、EurekaサーバはインスタンスBを簡単に追い出すことができません。これがSELF PRESERVATION MODEの目的であり、ONにしておいた方が良いということです。

1. 質問2:

最小限の閾値1がコードに書かれています。 registerWithEureka が false に設定されているため、Eureka インスタンスの登録はなく、閾値は 1 になります。

本番環境では、一般的に2台のEurekaサーバと registerWithEureka がtrueに設定されます。そのため、閾値は2であり、Eurekaサーバは自分自身に対して2回/分のリース更新を行うので RENEWALS ARE LESSER THAN THRESHOLD は問題ないでしょう。

1. 質問3:

はい、その通りです。 eureka.instance.leaseRenewalIntervalInSeconds は 1 分間にどれだけの更新がサーバに送られるかを定義しますが、その際に係数として eureka.server.renewalPercentThreshold を掛けたもので、デフォルトは 0.85 です。

1. 質問4:

はい、正常です。閾値の初期値は1に設定されているので、もし registerWithEureka がfalseに設定されている場合、更新は常に閾値以下になります。

これには2つの提案があります。

1. 2台のEurekaサーバーを導入し registerWithEureka .
2. デモ/デブ環境にデプロイするだけなら eureka.server.renewalPercentThreshold を 0.49 に設定すると、Eureka サーバを単独で立ち上げたときに、閾値が 0 になります。