2

Azure クラウドでサービスをホストしていますが、明らかな理由もなく "BackendConnectionFailure" が発生することがあります。調査の結果、ほとんどの場合、この例外と自動スケーリング (スケールダウン) の間に相関関係があることがわかりました。

ドキュメントによると、デフォルトの終了猶予期間は 30 秒です。ポッドは終了とマークされ、ロードバランサーはこれ以上考慮しないため、それ以上のリクエストは受信されません。これによれば、サービスの所要時間が 30 秒よりもはるかに短い場合、アプリケーションに prestop フックや特別な実装は必要ありません (間違っている場合は修正してください)。

前の段落が正しい場合、この例外が比較的頻繁に発生するのはなぜですか? 私の考えは、ポッドが終了とマークされ、ロードバランサーがポッドにリクエストを転送する必要があるときに、それ以上リクエストを転送しない場合です。

編集1：

アーキテクチャは単純にこのようなものです

クライアント -> ファイアウォール (Azure) -> API (Azure APIM) -> マイクロサービス (Spring Boot) -> サービスに応じてバックエンド (サード パーティ) または Azure RDB

例外は APIM から来ていると思います。この例外には 2 つのパターンが見つかりました。

  1. Message The underlying connection was closed: The connection was closed unexpectedly. Exception type BackendConnectionFailure Failed method forward-request

Response time 10.0 s

  1. Message The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. Exception type BackendConnectionFailure Failed method forward-request

Response time 3.6 ms

4

3 に答える 3

0

アプリケーションがSIGTERM(Pod の終了から) を受け取ると、最初に準備ができていることの報告を停止する必要があります ( に失敗しますreadinessProbe) が、クライアントからのリクエストは引き続き処理されます。一定時間後 (readinessProbe設定によって異なります)、アプリケーションをシャットダウンできます。

Spring Boot には、まさにそれを行う小さなライブラリがあります: springboot-graceful-shutdown

于 2020-02-18T12:24:53.217 に答える