サービスの自動拡張、および電流制限ヒューズ：マイクロサービスの製品ラインは、独自のビジネスロジックに集中し、外部インタフェースを提供するために、各サービスは、実際には、のような考慮すべき多くのものがある、非常に明確なようです事業の拡大に伴い、サービスの数が増加し、より複雑なロジックになり、サービスのロジックは完了するために、他のサービスの数に依存する必要があります。依存性は、サービスを提供することはできません後はアクセスできないサービス全体につながる、アバランシェ効果を有する可能性があります。
RPCまたはHTTPはマイクロサービス間で呼び出した場合、我々は一般的にタイムアウトを呼び出すように設定しますが、失敗は成功の実装サービスを確保するための仕組みを再試行してくださいあなたはヒューズやサービスを制限することを検討していない場合には、美しく見える、雪崩の発生源です。
我々はサービスのC及びDの両方に依存して、それぞれ、サービスAとBのより大きな量にアクセスするために2つがあると仮定し、C及びDは、依存サービスのサービスEであります
AとBはC、Dハンドル顧客の要求を呼び出し、必要なデータを返すように続けています。Eサービスは、サービスを提供するタイムアウト機構C及びDを再試行することができないときに実行されます
常に新しい呼び出しを生成するには、バックログCとD Eサービスへの呼び出しの数が多い、待機中の呼び出しの数が多いにつながるとのコールを再試行します、それはゆっくりと、その後もダウンし、メモリやCPUなどのリソースCとDが不足し、かつますアウト。
AとB、CとDは、最終的に全体のサービスにアクセスできない、資源の枯渇、サービス操作を繰り返し、その後、落下されます。
一般的な原因雪崩の状況は次のとおりです。
- プログラムのバグは、サービスが利用できないか、遅くなる原因
- キャッシュ破壊、落下につながる、サービスコールへのフルアクセスにつながります
- トラフィックが急増。
- ハードウェアの問題は、この感覚は、そのポイントバック⊙︿⊙だけを言うことができます。
千万のアバランシェ効果が、サービスがハングアップし、スムーズに動作していないことを保証することは私たちの責任、対応するアバランシェ効果で多くの保護スキームが残っています。
サービスの横展開
今、私たちは、その後の流れが比較的大きい場合、サービスがハングアップしないであろうことを保証するためのツールの多くを使用することができ、横方向に円滑な運営を確保するためのサービスを拡張することができます。たとえば、私たちが最も頻繁にK8Sを使用し、サービスの動作状態を確保することができ、サービスは、自動水平展開することができます。このプロセスへのユーザートラフィックの急増のためにまだ非常に良いですが、横方向の拡張の終わりには、特定の環境Eサービスにおける応答時間が長すぎる場合は、まだアバランシェ効果につながる可能性があり、またそこにあります。
限定的
実際の電流リミットに到達するためのクライアントの呼び出しは非常に一般的で制限し、例えば、我々は、二つ以上の受注が直接要求を拒否し、最大処理毎秒200件のリクエストを制限します。そのようなトークンバケットアルゴリズムなどの一般的なアルゴリズム
バケットトークンに入れて一定の速度では、クライアントがサービスを要求したとき、最初のバケットは、アクセスが拒否されたトークンの不足した場合は、処理するためには、バケットからトークンを取得する必要があります。
ヒューズ
呼び出しは、もはや直接、エラー、またはダウングレードを返すされていない場合、クライアントに依存し、依存性へのアクセスを制御しますが、コールは使用できません。以下のようなオープンソースのライブラリのライブラリのソースコード解析hystrixは-行くが、また、私は書くつもりです。良いヒューズとダウングレードの機能を達成するために。彼の主なアイデアは、例えば、同時誤り率の割合の最大数は、回復時間を融合しようとするいくつかのしきい値を設定することです。ステータスヒューズこれらのしきい値を変換することができ：
- オフ、コールを可能に頼ります
- オープン状態では、直接依存しない、呼び出し側は、エラー、またはコールのフォールバックを返します。
- 呼び出しが成功した場合、それを開くために続けてクローズに失敗しました半開状態は、ヒューズによると、呼び出し側は依存できます、回復時間を開こう
この記事では、記事を楽しみに役立つと見て友人のように！以上です！ありがとう！！！
Javaの学習、インタビュー、ドキュメント、ビデオリソースへの無料アクセス
ます。https：//juejin.im/post/5cfe59f46fb9a07ebb0528e5で再現