アプリケーションの高可用性を確保するための4つの一般的な電流制限の実践|クラウド効率エンジニアガイド

はじめに:4つの一般的な電流制限プラクティスにより、アプリケーションの高可用性が保証されます。この記事では、AHAS電流制限プラクティスガイドを要約します。システムが悪意のあるユーザーに攻撃されるリスクがある場合、またはシステム内のアプリケーションが異常である場合、なだれ効果。その後、この記事はあなたを助けます。

みなさん、こんにちは。私の名前は黄博文、ニックネームはヤンメイです。現在、ユンシャオの製品であるフローパイプラインの設計と開発を担当しています。マイクロサービスアーキテクチャでは、サービスがますます増え、サービス間の呼び出しはますます複雑になります。サービスの高可用性を確保する方法が課題になっています。以前参加した製品の1つに障害が発生しました。その理由は、特定のAPI呼び出しが突然数十回増加し、サービスの負荷が高くなり、ユーザーの使用に影響を与えたためです。その時点で、この異常なAPIをすばやく制限または融合するメカニズムがあれば、サービスが不安定な状態になるのを防ぐことができます。Yunxiao自体は、Alibaba Cloud AHAS(Application High Availability Service)を使用して、アプリケーションの高可用性を確保しています。この記事では、AHASの現在の制限プラクティスガイドをまとめています。システムが悪意のあるユーザーに攻撃されるリスクがある場合、またはシステム内のアプリケーションが表示される場合異常は雪崩効果を引き起こす可能性があるため、この記事が役立ちます。

完全なアプリケーション高可用性ソリューションは、最初にアプリケーションインターフェイスを監視する必要があり、現在のアプリケーションインターフェイスのQPS状況をリアルタイムでカウントできます。次に、APIやシナリオごとにさまざまな電流制限と融合のルールを設定できる必要があります。たとえば、APIのQPSが300を超える場合は、超過した呼び出しに対して電流制限処理を実行する必要があります。電流制限を提供できるツールはたくさんありますが、人気のあるツールはguava RateLimiter、Hystrixなどです。ただし、これらのツールは開始するのに多くの費用がかかり、システム全体を構築するのは簡単ではありません。

アプリケーションの電流制限システムをすばやく確立するにはどうすればよいですか?ここでは、Alibaba Cloudが提供するアプリケーション高可用性サービスAHAS(アプリケーション高可用性サービス)を紹介します。AHASは、Alibabaの内部高可用性システムによって長年にわたって生み出されたクラウド製品です。Alibabaのオープンソースフロー制御およびダウングレードコンポーネントSentinelに基づいて、フロー制御、不安定なコールアイソレーション、サーキットブレーカーからのエントリポイントとしてトラフィックとフォールトトレランスを採用しています。ダウングレード、ホットスポットトラフィック保護、システム適応型過負荷保護、クラスターフロー制御、サービスアンチジッターなどの複数の側面により、サービスとゲートウェイの安定性が確保され、第2レベルのトラフィック監視および分析機能が提供されます。AHASは、アリの淘宝網や天猫Tmallなどの電子商取引分野で広く使用されているだけでなく、インターネットファイナンス、オンライン教育、ゲーム、生放送業界、その他の大規模な政府や中央企業でも多くの実績があります。

現在の制限は何ですか

電流制限の目的は、過剰なトラフィックが原因でシステムが使用できなくなるのを防ぐことです。では、このトラフィックはどこから来るのでしょうか?

アクセス方法に応じて、次のように分類できます。

  1. HTTPへの同期呼び出し。たとえば、ブラウザを介してサイトのページにアクセスすると、この種のトラフィックが生成されます。
  2. バックグラウンドタスク呼び出し。これはビジネスフォームによって異なります。たとえば、サイトでユーザーが定期的にタスクを実行できるようになっている場合、ユーザーが追加のタスクを構成するたびに、システムへのトラフィックが増加します。

アクセスの目的に応じて、次のように分類できます。

  1. 通常のビジネスの成長。例えば、利用者や営業活動等の増加は、全体の取引量の増加につながります。
  2. 悪意のあるユーザーによる悪意のあるアクション。たとえば、ユーザーがWebサイトに対してDDOS攻撃を行ったり、タスクを定期的に実行する機能を提供する上記のWebサイトに対して、悪意を持って多数の時間指定タスクを構成し、間接的にシステムに大きな負荷をかけたりします。オン。

アクセス元に応じて、次のように分類できます。

  1. 利用者。これらのユーザーはエンドユーザーであり、通常のビジネスではトラフィックの合計が増加します。
  2. システムコール。たとえば、他のシステムが自分の機能に基づいて独自の製品を構築する場合、アクセスの最大頻度についてこれらのシステムと合意し、現在の制限戦略にこれらの頻度の値を実装する必要があります。

トラフィックがどこから来ているかを理解すると、何を制限するかがわかります。

  1. システム全体の使用頻度を制限します。実際の使用では、これは通常、単一のマシンの使用頻度に変換され、単一のマシンが圧倒されないようにします。同時に、アラームと連携し、ボトルネックが発生した場合、緊急拡張により問題を解決することができます。
  2. 単一のユーザー(またはビジネスフォームによっては単一のテナント)による使用の頻度を制限します。
  3. さまざまなアップストリームシステムコールの使用頻度を制限します。
  4. 针对上述的限制,都需要能够支持HTTP的同步调用和后台任务调用。

接下来我们从保证系统整体可用性、防止个别用户滥用、隔离上游系统异常调用以及全方位限流4个方面,具体讲解如何使用阿里云AHAS实现限流。

保证系统整体可用性

配置限流时,我们需要建立一个通用的限流规则保障核心接口的稳定性,避免单点瓶颈引发全局问题。

一个流控规则包含以下内容:

  • 接口名称:即对哪个接口进行流控。
  • 来源应用:设置为default,即对所有调用方都一视同仁,对整个系统的调用进行限流。关于这个配置的用法,会在后面的“针对其他上游系统调用的限流”部分展开讨论。
  • 单机QPS阈值:单机的QPS容量,超过阈值后会被限流
  • 流控效果:当接口调用超过QPS阈值后的处理措施

我们也可以配置触发限流后的接口返回值。对于Web接口而言,通常被限流的接口会返回429 Too Many Requests错误码,告知调用方请求太频繁。

对一个接口进行限流时,难点是填写具体的QPS阈值。我们可以在性能测试环境对应用进行压测,压出单机下某个接口的QPS极限值,然后将阈值定为极限值的某个比例,比如极限值的90%。比如某个接口单机可承受极限为200QPS,那么阈值可定为200*90%= 180。

防止个别用户滥用

这个场景下,需要先梳理出来系统的核心业务入口,通常是service层的一个入口函数,针对每个入口函数预设单个用户合理的使用频率,然后就可以利用AHAS的热点参数流控能力,来并进行限制。

在入口函数上添加注解:

@SentinelResource(value = "biz1")
public Result doBussinessLogic(String uid, int type) {
    // uid参数索引为0,type参数索引为1。
    // some logic here...
}
复制代码

代码中需要做两件事情

  1. 从请求中提取出需要防护的维度,比如上面代码中的uid,即用户的标识。并保证该标识作为业务入口函数的入参传入。
  2. 给该函数添加@SentinelResource注解。其中的value="biz1"为这个资源的标识,会用在控制台配置中进行引用。

然后在控制台进行配置。假设我们希望,在服务级别每分钟单用户最多调用20次,服务共有5个实例。则可以进行如下配置。意思是在第0个参数,也就是用户,这个维度上进行限流,单机最多每60s进行4次调用,则集群维度就是每分钟最多20次调用。

目前AHAS还不支持直接进行集群维度的配置,实际使用中需要简单的换算下。

详细说明,请参考:
help.aliyun.com/document\_d…

隔离上游系统异常调用

对于一个应用的接口来说,通常会被上游多个系统调用。上面虽然介绍了如何对单个接口进行整体限流,但实际场景中,我们会需要对不同的上游系统采用不同的限流阈值。比如上游调用方A是主链路,希望QPS阈值能高一些,上游调用方B为旁支链路,QPS阈值可以低一些。那么我们需要在Web容器启动时注入抽取租户特征值的拦截器。根据来源应用标识来对不同来源给予不同的阈值。

@Configuration
public class InterceptorConfiguration extends WebMvcConfigurerAdapter {
    
    @PostConstruct
    public void setOriginParser() {
        WebCallbackManager.setRequestOriginParser(httpServletRequest -> httpServletRequest.getHeader("income"));
    }
}
复制代码

WebCallbackManager.setRequestOriginParser 接受一个参数为HttpServletRequest的回调,我们需要通过HttpServletRquest对象中的内容来区分调用方A和B。比如应用A和B在调用接口时会传入不同的header income,那么就可以通过该header来区分来源应用A和B。最后在流控规则中建立起对A和B不同限流阈值。如下图所示。

全方位限流,不限于HTTP

AHAS可以快速的把Web接口纳入到流控之中。但如果我们应用的一些代码不属于Web接口,但也想启用流控,那么仍然可以使用AHAS提供的热点规则的能力。以下是个示例。

    @SentinelResource(blockHandler = "blockHandlerExecuteTask")
  public Boolean executeTask(Long taskId) throws Exception {
    return taskService.executeTask(taskId);
    }


    public Boolean blockHandlerExecuteTask(Long taskId, BlockException ex) {
        throw new RuntimeException("execute task exceed");
    }
复制代码

重启应用后,在接口详情页的自定义埋点tab中,就可以看到AHAS收集的自定义埋点接口数据,接口名称组成为类名:方法名的格式。

接着可以给这个埋点接口配置限流规则,开启防护。

以上就是我们使用AHAS服务时配置限流的常用实践,希望对大家有所帮助。

原文链接

本文为阿里云原创内容,未经允许不得转载。

おすすめ

転載: juejin.im/post/7078866799906783239