springcloudヒューズHystrixの具体的な使用
springcloudの溶断というと、去年の株式市場の中の溶断を思い出しました。何度も痛い悟りを得て、勝手に実施した溶断はシステム全体に影響が災難的でした。
ヒューズ
雪崩効果
マイクロサービスアーキテクチャでは通常、複数のサービス層の呼び出しがあり、基本サービスの障害がカスケード障害を引き起こし、システム全体が利用できなくなることがある。この現象はサービス雪崩効果と呼ばれる。サービス雪崩効果は、「サービス提供者」の利用不可によって「サービス消費者」が利用できなくなり、利用できなくなり次第に拡大する過程である。
Aがサービスプロバイダとして、BはAのサービス消費者、CとDはBのサービス消費者である。Aは利用できなくてBの利用不可を引き起こし、雪だるま式にCとDに拡大できない場合、雪崩効果が発生します。
ヒューズ（Curcuit Breaker）
ヒューズの原理は簡単で、電気過負荷保護器のようです。これは急速な失敗を実現することができます。多くの類似のエラーがしばらくの間検出されると、その後の複数の呼び出しが急速に失敗し、リモートサーバにアクセスしないように強制されます。したがって、アプリケーションが失敗する可能性のある動作を継続的に試行することを防止します。あるいはCPU時間を無駄にして、長時間のタイムアウトが発生するまで待ちます。ヒューズは、エラーが修正されたかどうかをアプリケーションに診断させてもいいです。修正されたら、アプリケーションは再度起動操作を試みることができます。
ヒューズモードはエラーを招きやすい動作の代理のようです。このようなブローカは、最近の呼び出しでエラーが発生した回数を記録し、使用許諾操作を継続するか、または直ちにエラーを返すかを決定することができる。
ヒューズスイッチの相互変換の論理は以下の図の通りである。
ヒューズとは保護サービスが利用できる最後の防御線です。
Hystrix特性
1.遮断器の仕組み
遮断器がよく分かります。Hystrix Commandバックエンドサービスの失敗数が一定の割合を超えていることを要求すると、遮断器は開路状態（Open）に切り替わります。この時、すべての要求は直接失敗してバックエンドサービスに送られません。遮断器は開路状態のしばらくの間（デフォルト5秒）を維持します。自動的に半開路状態（HALF-OPEN）に切り替わります。この時に次の要求の戻り状況が判断されます。もし要求が成功したら、遮断器は閉路状態（CLOED）に戻ります。そうしないと、再び開路状態（OPEN）に切り替わります。Hystrixの遮断器は私達の家庭回路の中の保険糸のようです。バックエンドサービスが使えないと、遮断器は直接に要求チェーンを切断します。大量無効要求を送信してシステムスループットに影響を与えないようにし、遮断器は自己検査と回復の能力を有する。
2.Fallback
Fallbackは相当していますので、レベルを下げて操作します。クエリー操作に対して、バックエンドサービスに異常が発生した場合、fallback方法で戻ります。fallback方法の戻り値は、一般的に設定されたデフォルトまたはキャッシュからの戻り値です。
3.資源分離
Hystrixでは、主にスレッド池を通じてリソース分離を実現します。通常は、呼び出した遠隔サービスによって複数のスレッドプールを分割します。例えば、製品サービスを呼び出すCommandをAスレッドプールに入れます。アカウントサービスを起動したCommandはBスレッドのプールに入れます。このようにする主な利点は、運行環境が離れていることです。このようにサービスを呼び出すコードがバグがあっても、あるいは他の原因で自分のオンラインのプログラムが消耗された場合、システムの他のサービスに影響はありません。しかし、複数のスレッドプールを維持することは、システムに追加の性能オーバーヘッドをもたらします。性能に厳しい要求があり、自分でサービスを呼び出すクライアントコードに問題がないと確信しているなら、Hystrixの信号モード（Semaphores）を使ってリソースを分離することができます。
Feign Hystrix
溶断はサービスコールの端にしか作用しないので、前編の例コードによってspring-cloud-consumerプロジェクト関連コードを変更すればいいです。FeignはHystrixに依存していますので、mavenの配置には何の変更もありません。
1、プロファイル
appication.propertiesはこれを追加します。
ハローRemoteHystrix類の継承とハローRemoteを作成し、フィードバックを実現する方法
ハローRemote類に指定fallback類を追加し、サービスが溶断された時にfallback類に戻る内容です。
4、テスト
効果を試してみましょう。
spring-cloud-eurka、spring-cloud-producer、spring-cloud-consumerの3つの項目を順次起動します。
ブラウザに入力:http://localhost:9001/hello/neo
返します：hello neo、this first message
溶断に関する情報を入れると正常なアクセスに影響しないことを説明します。次に私達は手動でspring-cloud-producerプロジェクトを停止して再度テストします。
ブラウザに入力:http://localhost:9001/hello/neo
返します：hello neo、this message send failed
戻りの結果から溶断が成功したと説明します。
サンプルコード
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。
ヒューズ
雪崩効果
マイクロサービスアーキテクチャでは通常、複数のサービス層の呼び出しがあり、基本サービスの障害がカスケード障害を引き起こし、システム全体が利用できなくなることがある。この現象はサービス雪崩効果と呼ばれる。サービス雪崩効果は、「サービス提供者」の利用不可によって「サービス消費者」が利用できなくなり、利用できなくなり次第に拡大する過程である。
Aがサービスプロバイダとして、BはAのサービス消費者、CとDはBのサービス消費者である。Aは利用できなくてBの利用不可を引き起こし、雪だるま式にCとDに拡大できない場合、雪崩効果が発生します。
ヒューズ（Curcuit Breaker）
ヒューズの原理は簡単で、電気過負荷保護器のようです。これは急速な失敗を実現することができます。多くの類似のエラーがしばらくの間検出されると、その後の複数の呼び出しが急速に失敗し、リモートサーバにアクセスしないように強制されます。したがって、アプリケーションが失敗する可能性のある動作を継続的に試行することを防止します。あるいはCPU時間を無駄にして、長時間のタイムアウトが発生するまで待ちます。ヒューズは、エラーが修正されたかどうかをアプリケーションに診断させてもいいです。修正されたら、アプリケーションは再度起動操作を試みることができます。
ヒューズモードはエラーを招きやすい動作の代理のようです。このようなブローカは、最近の呼び出しでエラーが発生した回数を記録し、使用許諾操作を継続するか、または直ちにエラーを返すかを決定することができる。
ヒューズスイッチの相互変換の論理は以下の図の通りである。
ヒューズとは保護サービスが利用できる最後の防御線です。
Hystrix特性
1.遮断器の仕組み
遮断器がよく分かります。Hystrix Commandバックエンドサービスの失敗数が一定の割合を超えていることを要求すると、遮断器は開路状態（Open）に切り替わります。この時、すべての要求は直接失敗してバックエンドサービスに送られません。遮断器は開路状態のしばらくの間（デフォルト5秒）を維持します。自動的に半開路状態（HALF-OPEN）に切り替わります。この時に次の要求の戻り状況が判断されます。もし要求が成功したら、遮断器は閉路状態（CLOED）に戻ります。そうしないと、再び開路状態（OPEN）に切り替わります。Hystrixの遮断器は私達の家庭回路の中の保険糸のようです。バックエンドサービスが使えないと、遮断器は直接に要求チェーンを切断します。大量無効要求を送信してシステムスループットに影響を与えないようにし、遮断器は自己検査と回復の能力を有する。
2.Fallback
Fallbackは相当していますので、レベルを下げて操作します。クエリー操作に対して、バックエンドサービスに異常が発生した場合、fallback方法で戻ります。fallback方法の戻り値は、一般的に設定されたデフォルトまたはキャッシュからの戻り値です。
3.資源分離
Hystrixでは、主にスレッド池を通じてリソース分離を実現します。通常は、呼び出した遠隔サービスによって複数のスレッドプールを分割します。例えば、製品サービスを呼び出すCommandをAスレッドプールに入れます。アカウントサービスを起動したCommandはBスレッドのプールに入れます。このようにする主な利点は、運行環境が離れていることです。このようにサービスを呼び出すコードがバグがあっても、あるいは他の原因で自分のオンラインのプログラムが消耗された場合、システムの他のサービスに影響はありません。しかし、複数のスレッドプールを維持することは、システムに追加の性能オーバーヘッドをもたらします。性能に厳しい要求があり、自分でサービスを呼び出すクライアントコードに問題がないと確信しているなら、Hystrixの信号モード（Semaphores）を使ってリソースを分離することができます。
Feign Hystrix
溶断はサービスコールの端にしか作用しないので、前編の例コードによってspring-cloud-consumerプロジェクト関連コードを変更すればいいです。FeignはHystrixに依存していますので、mavenの配置には何の変更もありません。
1、プロファイル
appication.propertiesはこれを追加します。
feign.hystrix.enabled=trueハローRemoteHystrix類の継承とハローRemoteを作成し、フィードバックを実現する方法
@Component
public class HelloRemoteHystrix implements HelloRemote{
@Override
public String hello(@RequestParam(value = "name") String name) {
return "hello" +name+", this messge send failed ";
}
}
ハローRemote類に指定fallback類を追加し、サービスが溶断された時にfallback類に戻る内容です。
@FeignClient(name= "spring-cloud-producer",fallback = HelloRemoteHystrix.class)
public interface HelloRemote {
@RequestMapping(value = "/hello")
public String hello(@RequestParam(value = "name") String name);
}
4、テスト
効果を試してみましょう。
spring-cloud-eurka、spring-cloud-producer、spring-cloud-consumerの3つの項目を順次起動します。
ブラウザに入力:http://localhost:9001/hello/neo
返します：hello neo、this first message
溶断に関する情報を入れると正常なアクセスに影響しないことを説明します。次に私達は手動でspring-cloud-producerプロジェクトを停止して再度テストします。
ブラウザに入力:http://localhost:9001/hello/neo
返します：hello neo、this message send failed
戻りの結果から溶断が成功したと説明します。
サンプルコード
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。