为了在Yelp上将整体应用程序分解为微服务，我们一直在使用AWS Step Functions将多个业务流程迁移到现代架构。

亚马逊宣布发布的AWS Step Functions集成，包括他们的计算、数据库、消息传递、分析和机器学习服务，这使得用户可以把这些服务作为状态机工作流中的步骤。借助AWS Step Functions，亚马逊提供了一种抽象的方法来连接和协调活动，充分利用高度可伸缩的运行时，可视化工作流表示，并且内置了重试、监控和日志机制。

由于Yelp的交易订购涵盖了多种垂直领域，包括食品（送货/外卖订单），订票，上门服务等等。这些订单通过“Step Functions”进行处理，其中每个步骤都表示工作流的执行实例，如下所示：

AWS Step Functions提供了建立完整工作流的功能

上述工作流程中的每个步骤都是一个“活动”，Yelp将这些活动实现为批处理守护程序，这些守护程序通过API集成与AWS Step Functions进行交互，该API集成可获取任务并提交活动执行结果。我们运行这些批处理守护程序的多个实例，并通过内部部署平台PaaSTA进行部署。

要知道，每个工作流程执行（即订单处理）都是有时间限制的。为此，我们启用了“Step Functions”提供的超时功能。工作流中的每个活动都需要在指定的时间内完成，以使工作流中的所有活动所花费的时间总和在工作流超时的限制内。另外，我们还使用活动重试（可针对每个活动进行配置），来实现间歇性可恢复故障情况下的弹性。

SubmitOrder活动执行的放大视图（步骤功能的内部步骤以蓝色显示）

如果我们放大每个工作流程执行的特定活动（本例中为SubmitOrder），每个执行都将以ActivityScheduled状态排队，直到由一个“activity workers”选择为止。由于每个活动的总时间(包括执行和等待时间)是有限制的，所以等待时间较长的任务得到的执行时间较少。这些任务可能需要重试，来自多个活动的级联效应可能会达到工作流超时阈值。由于AWS提供了有关这些任务的等待时间（ActivityScheduleTime）的汇总指标，为了保持工作流处理所需的成功率和延迟，我们需要有一个正常的“activity workers” 指标。

为什么活动实例需要自动伸缩

Yelp上的交易流在一天和一周的过程中都会经历重复的流量模式，在使用新的自动伸缩系统之前，我们使用了Amazon CloudWatch 指标来调整活动实例计数，以满足服务级别的目标。在本文的案例中，我们预配置了静态的活动工作人员数以处理高峰流量，这导致在非高峰时段剩余了大量未使用的计算能力，从而使事务流成为自动扩展的理想用例。

PaaSTA的自动伸缩基于金字塔uwsgi度量标准和CPU使用情况，而Step Functions（SFN）工作流依赖于活动的及时执行（ActivityScheduleTime度量标准）。步进功能Autoscaler可在这两个系统之间架起桥梁，以管理和控制活动实例。

什么是 Amazon CloudWatch？

Amazon CloudWatch 实时监控你的 Amazon Web Services (AWS) 资源以及你在 AWS 中运行的应用程序。你可以使用 CloudWatch 收集和跟踪指标，这些指标是你可衡量的相关资源和应用程序的变量。

CloudWatch 主页自动显示有关你使用的每项 AWS 服务的指标。此外，你还可以创建自定义控制面板，以显示有关自定义应用程序的指标，并显示你选择的指标的自定义集合。

你可以创建警报，这些警报监视指标，当超出阈值时，它们会发送通知或者对你所监控的资源自动进行更改。例如，你可以监控你的 Amazon EC2 实例的 CPU 使用率以及磁盘读写情况，然后使用此数据确定你是否应启动其他实例来处理增加的负载。你还可以使用此数据停止未完全利用的实例以节省开支。

你可通过使用 CloudWatch 全面地了解资源使用率、应用程序性能和运行状况。Amazon CloudWatch 控制台的链接： https://console.amazonaws.cn/cloudwatch/。

Autoscaler架构

CA（ cluster-autoscaler）是用来弹性伸缩kubernetes集群的。我们在使用kubernetes集群经常问到的一个问题是，我应该保持多大的节点规模来满足应用需求呢？ cluster-autoscaler的出现解决了这个问题，它可以自动的根据部署的应用所请求的资源量来动态的伸缩集群。

CA由以下几个模块组成：

autoscaler：核心模块，负责整体扩缩容功能

Estimator：负责评估计算扩容节点

Simulator：负责模拟调度，计算缩容节点

CA Cloud-Provider：与云交互进行节点的增删操作。社区目前仅支持AWS和GCE，其他云厂商需要自己实现CloudProvider和NodeGroup相关接口。 

Autoscaler的不同组件以及与AWS服务和PaaSTA的交互

Autoscaler系统由三个组件组成：AWS服务，Autoscaler服务和PaaSTA系统。在较高级别上，Autoscaler首先获取伸缩配置，然后从AWS端收集伸缩需求，计算伸缩决策，最后调用PaaSTA api来调整实例计数。

AWS组件

我们利用Step Functions Metrics（ActivityScheduleTime度量标准）和Cloudwatch警报来检测任何值得扩展的事件，并利用SNS和SQS服务来中继扩展消息。

更具体地说，每个活动有两个cloudwatch警报：放大和缩小。当警报检测到违反条件时，它会发出“ALARM”通知，由自动呼叫器轮询。当ActivityScheduleTime指标恢复正常时，它将发送一个“OK”通知。

伸缩大脑（Scaling Brain）

收到伸缩消息后，Autoscaler将验证消息，解析和理解请求，然后为特定活动计算具体的伸缩决策。它考虑了用于伸缩决策的两个主要因素：伸缩配置（例如，最小/最大计数和伸缩梯度）和伸缩记录（例如，最后的警报时间和最后的伸缩时间）。

放大过程中涉及的步骤，突出显示了重复的伸缩过程

设计注意事项

不断扩展

当流量增加时，扩展警报发出一个“警报”通知，Autoscaler不断扩展活动工作者，直到ActivityScheduleTime指标回到正常阈值。当流量稳定下来后，cloudwatch会发出一个“OK”通知。有了“OK”消息，autoscaler将开始清理以前的“ALARM”通知，并结束该活动的扩展周期。

避免Scale Flapping

对于任何自动伸缩系统来说，Flapping（放大和缩小事件的连续变化）都是一个典型的挑战。以下是我们为应对这一挑战而提出的一些想法：

1.我们支持按比例缩小的冷却时间，以防止在一定时间内连续两次按比例缩小操作，此值可由服务所有者配置。

2.我们会验证传入的扩展信号，以防止任何恶意的，延迟的或重复的扩展通知。这是通过限定警报名称、维护最后的警报时间以及在每次扩展操作之前检查扩展配置来实现的。

3.保守的缩减是基于历史数据的缩减警报，因此它们不易触发，在高峰时段也不会发生。

具体示例

我们已经在我们的交易订单的85％中推出了Step Functions Autoscaler，并且在开始的几个月中已经取得了积极的成果。

该图显示了过去7天中给定活动的activity workers数量，蓝线表示在Autoscaler集成之前的工作人员静态计数

上图显示了一个生产活动在一周内发生数量变化的情况，蓝线是没有Autoscaler时的实例号，橙色线是具有Autoscaler的实例号。你可以清楚地看到，在某些情况下，某个活动可以使用更少的实例，而且即使保守地缩减规模，我们每周也可以节省约34％的每项活动计算成本。

我们已为约11个步进功能活动启用了自动伸缩功能，这些活动在一周内处理了约200万个任务。整个部署过程耗时约2周，其中不包括活动的停机时间。以下是此部署过程中的一些建议和经验教训：

1. 重新访问历史数据以设置cloudwatch警报阈值，我们使用历史数据作为按比例放大和按比例缩小阈值的初始值，并在推出阶段相应地进行了调整。注意：即使在非高峰时段也将有非零的活动等待时间（ActivityScheduleTime指标），因此应该相应地设置一个按比例缩小的报警阈值。

2. 以较大的递增增量逐步达到理想的最小实例数，为了安全地进行部署，我们在开始时将最小实例边界和最大实例边界固定下来，并逐渐扩大了整个范围。高比例的渐变可以避免突发流量期间的性能下降，同时实例数保持最少。

3. 积极地扩大规模，保守地缩减规模我们使用冷却时间，较小的规模缩减梯度和较大的评估期来进行保守的规模缩减，而不是使用较大的规模递增梯度和较小的评估期来进行积极的规模扩大。

本文翻译自：https://engineeringblog.yelp.com/2019/06/autoscaling-aws-step-functions-activities.html如若转载，请注明原文地址： https://www.4hou.com/web/21392.html