I.はじめに

オンラインではサービス間の呼び出しに遅延が発生しており、リンクトラッキングからXサービスがリクエストを送信し、Yサービスがリクエストを約1秒で受信していることがわかりますが、最終的にはTCPパケットであることが判明しましたロスリトライ、その過程にはまだ多くの問題があり、段階的に方向性を確認し、最終的に結論を決めるパケットキャプチャ実験も非常に興味深いです。

二、調査

1、ヒストリックス

疑わしい最初の方向は、Hystrix スレッドプールがいっぱいで、実行時間が比較的長く、キューが待機しているため、遅延が発生していることです。

この現象をよく考えてみると、x を送信してから y を受信するまでの直接の間隔は 1 秒なので、キューで待機することはありません。また、スレッドプールが実際にいっぱいで、キューが長時間待機する場合、この高い確率により後続のリクエストが融合され、警告が発せられます。

ハイストリックスは除外。

2、エウレカ

Eurkea による対象 IP の取得も疑われており、x-cache レジストリの有効期限が切れており、eurkea から IP を取得するのは遅いですが、Hystrix と同様に可能性は否定できません。

3. サービスグリッド

現時点では、パケットをキャプチャすることしかできず、これには運用と保守の操作が必要ですが、パケットのキャプチャはまだローリングによってカバーされているため、開発者はリンクの追跡に常に注目し、運用と保守が適切なタイミングでファイルをコピーできるようにする必要があります。それが起こったとき。

コードとミドルウェアの次元で理由が特定できる場合は、基本的に面倒なパケットのキャプチャを選択することはなくなります。

サービスメッシュは、サービス間の通信のコントローラーです。Istio は、Google、IBM、Lyft によって作成されたサービスメッシュのオープンソース実装です。

Istio でできること: トラフィック管理。サービス間の依存関係とサービス呼び出しのフロー方向を取得します。サービスの ID を認証し、サービスへのトラフィックを保護する機能を提供します。

x から 127.0.0.1 ローカルまでは、実際には通信サービスグリッドのプロセスです。

つまり、サービスリクエスト x->y は実際には x-> x. Istio-> y. Istio->y なので、サービスグリッド間の通信、またはサービスとローカルグリッド間の通信に問題がある可能性はありますか。しかし、tcpパッケージからはそうではないように見えます。次のステップでは、TCP メッセージを注意深くチェックして理由を見つけます。