マイクロサービスアーキテクチャ - 雪崩
サービスの自動拡張、および電流制限ヒューズ：マイクロサービスの製品ラインは、独自のビジネスロジックに集中し、外部インタフェースを提供するために、各サービスは、実際には、のような考慮すべき多くのものがある、非常に明確なようです事業の拡大に伴い、サービスの数が増加し、より複雑なロジックになり、サービスのロジックは完了するために、他のサービスの数に依存する必要があります。サービスを提供することができない依存関係が生成する可能性があるしたら雪崩效应、アクセスできないサービス全体につながります。
マイクロサービスとの間で行われ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-go，也是我接下来要写的源码分析的一个库。很好的实现了熔断和降级的功能。他的主要思想是，设置一些阀值，比如，最大并发数，错误率百分比，熔断尝试恢复时间等。能过这些阀值来转换熔断器的状态：
- 关闭状态，允许调用依赖
- 打开状态，不允许调用依赖，直接返回错误，或者调用fallback
- 半开状态，根据
熔断尝试恢复时间来开启，允许调用依赖，如果调用成功则关闭失败则继续打开
具体的实现方式和对hystrix-go源码的分析，我在后续的帖子会详细给大家介绍。