1. 背景
電流制限はマイクロサービス アーキテクチャ システムにとって非常に重要です。そうでないと、マイクロサービスの 1 つがシステム全体の隠れた雪崩要因になってしまいます。なぜそう言えるのでしょうか?
たとえば、特定の SAAS プラットフォームには 100 を超えるマイクロサービス アプリケーションがありますが、基になるアプリケーションの 1 つまたは複数が、すべての上位レベルのアプリケーションによって頻繁に呼び出されます。ピークの営業時間中、基になるアプリケーションがストリーム処理に制限されていない場合、アプリケーションは、特に頻繁に呼び出されるインターフェイスの場合、多大なプレッシャーに直面することになります。最も直接的なパフォーマンスは、後続の新しい受信リクエストがブロックされ、キューに入れられ、応答がタイムアウトになることです...最終的には、サービスが JVM リソースを使い果たすまで。
2. 電流制限の概要
ほとんどのマイクロサービス アーキテクチャの設計の開始段階 (テクノロジーの選択段階など) では、アーキテクトはグローバルな観点からテクノロジー スタックの組み合わせを計画します。それとも春雲？マイクロサービス ガバナンスの基礎となるフレームワークとして。迅速な立ち上げ、イテレーション、デリバリーに対応するためにも、開発のベースとして springboot を直接使用し、新しい技術スタックなどを導入します。
したがって、特定のビジネス シナリオに対する具体的な技術的ソリューションについて語る場合、それを一般化するのではなく、製品やサービスの現状を総合的に評価する必要があります。以下の異なる技術アーキテクチャも同じです。
2.1 ダボサービスガバナンスモデル
基本的なサービス ガバナンスとして dubbo フレームワークを選択することは、内部プラットフォームに偏ったアプリケーションに適しています。Dubbo は最下層で netty を使用します。http プロトコルと比較して、特定のシナリオでは依然として利点があります。dubbo を選択する場合は、選択する必要があります電流制限 プランでは次の参照を行うことができます。
2.1.1 ダボフレームレベルの電流制限
Dubbo は公式に包括的なサービス管理を提供しており、ほとんどの開発シナリオのニーズを満たすことができます。現在の制限シナリオについては、具体的には次のメソッドが含まれています。具体的な構成については、公式マニュアルを参照してください。
クライアントの電流制限<