淄博亿泰网站建设推广,app开发公司有哪些,组建做网站的团队,关键词是网站seo的核心工作在上篇文章《解密函数计算异步任务能力之「任务的状态及生命周期管理」》中#xff0c;我们介绍了任务系统的状态管理#xff0c;并介绍了用户应如何根据需求#xff0c;对任务状态信息进行实时的查询等操作。在本篇中我们将会进一步走进函数计算异步任务#xff0c;介绍异…在上篇文章《解密函数计算异步任务能力之「任务的状态及生命周期管理」》中我们介绍了任务系统的状态管理并介绍了用户应如何根据需求对任务状态信息进行实时的查询等操作。在本篇中我们将会进一步走进函数计算异步任务介绍异步任务的调度方案以及系统在可观测性方面所支持的各项功能。
一、任务调度
任务调度多指系统根据当前负载情况将不同任务放到合适的计算资源中去执行的相关操作。一个完善的调度系统往往需要平衡不同特点的任务间的隔离以及效率最优这两个需求。函数计算异步任务采用了独立队列模型及自动负载均衡策略具备在不影响处理性能的前提下进行多租隔离的能力。
Serverless Task 任务调度模型
当用户提交一次任务后系统会将该任务转换为一条消息并通过异步下发的方式放入到内部队列中。一条消息的处理流程如下图所示 图 1
整个系统在任务调度方面的多租隔离及消息积压控制方面主要依赖的是 Scheduler 对于队列的消费及控制。我们事先会为每一位用户划分一个账号级别的队列该用户的所有函数的异步调用包括任务调用会共享该队列。
这样的模型结构会保证每个用户的异步执行请求包括任务调用均不会受到其他用户的调用情况的影响。但是在一些大规模应用场景如一个用户的函数很多并且每个函数的调用量都很大的情况下所有的异步消息共用一个队列难免造成调用间的相互影响。部分长尾调用可能会过多的消耗队列的资源导致其他函数的执行出现饥饿的现象。
为了避免这种情况影响重要函数的执行函数计算提供了更细力度的队列 - 函数级别的队列。可以通过对每个不同函数设置单独的队列确保高优先级函数的消费情况不会受同账号下的其他函数执行的影响。队列间的关系如下图所示: 图 2
典型的应用场景
假设某用户 A 具有 2 个不同的任务函数。其中一个任务 A 由于下游服务的限制需要一个消息一个消息的执行而另外一个任务 B 是大并发任务并且希望尽快执行完。在默认模式下任务 A 和 B 共享同一个用户队列这时会出现如下场景任务 A 由于具有并发度限制函数计算侧会对整个任务队列进行出队速率控制。这就导致了任务 B 的任务迟迟无法出队。
而当任务 A 执行完后任务 B 得到了出队机会此时并发度升高任务 B 的消息抢占了资源池进行执行任务 A 又变得难以出队很长时间也无法开始一次执行。这样的结果就是无论 A 还是 B 都受到了对方业务的严重干扰。
当进行队列调整后任务 A 和 B 分别独占队列。在这种情况下任务 A 和 B 的消费速度不受对方影响都可以达到自身的诉求。
目前 Serverless Task 提供了任务积压大盘您可以在任务界面获取目前已经积压的任务数综合分析是否需要开启函数的独占队列。
Serverless Task 任务队列负载均衡模型
上面介绍了如何通过函数级别队列来避免出现 “Noisy Neighbour” 问题。但是在一些场景下如果任务的并发量级过大即便对该任务划分了单队列也会导致任务的积压。这个问题的解决需要引入 Serverless Task 的负载均衡策略。
函数计算的任务处理模块具有 Partition 的概念。每个用户默认属于一个 Partition负责该 Partition 的 Scheduler 会监听用户对应的任务队列。当出现严重积压时我们会为用户按照负载情况分配多个 Partition并交由不同的 Scheduler 负责消费来提升任务整体的消费速度。 图 3
可以看到阿里云函数计算在任务队列管理方面默认做到了多租及隔离的能力可以适用于绝大多数场景。针对一些重负载、长执行、并发量大的场景函数计算还支持横向扩容加快消费速度。在任务隔离方面函数计算支持针对不同优先级的函数进行单独隔离避免出现 Noisy Neighbour 的问题。
二、可观测性
任务的可观测能力是任务系统必不可少的能力之一。强大的可观测性将有助于业务方减少在任务运行的各个阶段所需要额外进行的工作量。
开发阶段任务的在线调试能力、运行结果的 Debug 能力将直接影响业务上线进度
业务常规运行阶段各种监控、流量情况的统计以及运行时日志将协助用户快速了解业务的发展、变化以及出现故障时的快速定位 处理
阶段性审计任务的历史记录存储及保留将为用户提供良好的可追溯能力可以根据历史信息进行后续的业务规划。
ServerlessTask 可观测性支持 - 开发测试阶段
业务的开发阶段最主要的诉求就是快速调试并定位问题。在对该阶段的支持中ServerlessTask 提供了登录实例及实时日志的能力。当代码开发并上传后测试 - debug - 修改代码 - 再次测试的流程可以全部在控制台完成极大的提高了研发效率。如果有需要性能调试、第三方 Binary 调试如音视频处理领域的 FFmpeg 调试等可以借助登录实例功能完成。操作流程如下图所示
选择想登录实例的任务点击实例链接。 会进入到实例监控页面点击右上角的登录实例功能即可登录到对应的实例上。
ServerlessTask 可观测性支持 - 业务上线后运行阶段
当业务上线后经常容易出现因容量预估不足导致下游系统无法承载压力导致故障。因此 ServerlessTask 提供了运行时指标即一段时间内的任务提交数、完成数及执行情况。用户可以根据这张指标图快速了解当前业务的负载情况。当用户任务的下游消费较慢可能造成任务积压这种情况也很容易在指标图中反映出进而快速做出相应的反应。目前 ServerlessTask 所提供的相关指标如下 任务监控大盘提供以下任务监控数据
监控指标说明提交的任务数在过去 1 分钟内所提交的任务总数包括运行中的、已完成的及未出队的数量。完成的任务数在过去 1 分钟内提交的任务所完成的任务数包括执行成功或失败的。排队中的任务数在过去 1 分钟内提交的任务还在排队中的数量。如果该数量不为 0则说明任务有积压。运行中的任务数在过去 1 分钟内提交的任务处于运行中的任务数。运行失败任务数在过去 1 分钟内提交的任务处于运行失败的任务数。运行已占用实例数在过去 1 分钟内提交的任务处于运行成功的任务数。
在快速定位问题方面函数计算支持实时查看函数日志及实例指标。您可以进入到任务的列表页面找到实际执行失败的任务进入日志页面及实例页面进行问题定位 ServerlessTask 可观测性支持 - 阶段性审计
当线上任务运行一段时间后往往需要进行一系列的阶段性审计工作比如上一周的执行总任务数执行失败的任务数及执行失败的时间。目前除了控制台以外函数计算提供了丰富的 API 能力来进行任务的审计工作。主要包括以下几方面能力
根据状态进行过滤只查询某一个状态的执行
根据触发时间进行过滤如查询过去某一段时间内发起的任务
根据任务名称查询。如果您的任务具有业务上下游的 TraceID您可以在触发任务时指定一个有意义的任务ID。后续可以根据 ID 前缀进行范围查询
上面的几个过滤方式可以组合达到更便捷的需求。控制台所支持的过滤条件如下图所示 更多参数内容可参考 ListStatefulAsyncInvocation 。
ServerlessTask 可观测性支持 - 死信队列及业务补偿
在消息领域有一个非常重要的概念 - 死信队列。当一些消息无法被消费时这些消息往往需要存储到一个地方以便后续人为的介入处理避免因未进行处理而造成业务损失。Serverless Task 也支持了这样一类功能。您可以对 Serverless Task 设置目标功能当任务执行失败后函数计算支持自动将执行失败的上下文信息推送到消息队列等消息服务中以便后续处理。如果您的处理逻辑支持自动化函数计算还支持将失败任务的上下文信息推送回函数计算执行一段您的自定义业务逻辑来实现业务补偿。
您可以在异步调用配置页面配置成功及失败目标。 更多配置内容请参考PutFunctionAsyncInvokeConfig。
综上所述Serverless Task 所提供的可观测能力可以有效支持任务全生命周期的监测需求。所有控制台能力均可以使用开放 API 进行定制化开发来满足更多的需求。Serverless Task 的目标功能除了可以做到任务失败补偿以外还可以作为 Event-Driven 模式的数据源自动的将处理后的事件投递到下游服务中。
原文链接
本文为阿里云原创内容未经允许不得转载。
