基于 MQ 的分布式 Serverless 多租任务处理系统架构演进

本文主要是介绍基于 MQ 的分布式 Serverless 多租任务处理系统架构演进，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1 Serverless 异步任务处理系统诞生和挑战

无论是对于云的开发者，还是尝试业务升级的企业客户，Serverless的三个概念 “极致弹性、无服务器运维、 按需付费” 几乎已经深入人心；但关于 Serverless能做什么、怎么做，却仍然是围绕在大家身边最普遍的声音。

在Serverless研发的初始阶段，通常技术团队会更多聚焦于弹性，冷启动加速，希望通过弹性能力凸显产品技术竞争力，确立产品在市场上的领先地位，并依赖这些能力吸引开发者和企业客户使用Serverless，这个阶段，更多的是依靠技术影响力引导大家探索 Serverless。

随着我们对Serverless的不断深入理解，同时弹性能力的提升进入深水区，相对来说没有本质改变的情况下，我们将更多地思考触及Serverless弹性以外的其他价值，这个时候，弹性将作为系统的基础能力渗透在产品各个方面，需要更多的从系统性的角度考虑 Serverless能做什么，能给客户带来什么，如何让业务聚焦那些不得不需要定制化的部分？

系统性意味着我们需要从包括资源供给，弹性调度，应用框架，容量评估，运维观测等多个维度来考虑Serverless系统对于客户业务的价值， 哪些需要用户参与，或者少参与，哪些需要以服务化能力提供给客户；对于那些客户必须参与的，平台需要提供便利的开发工具满足开发阶段客户需求；在具体业务逻辑实现中，利用Serverless的灵活扩展性，尽可能快速的帮助开发者实现和其他云服务的快速连接，提供稳定高效访问是Serverless所能带给客户的核心价值。

面对实际的客户需求，产品需要考虑多种业务场景: 离线场景的耗时任务执行，在线场景的高并发请求处理，以及事件驱动场景的事件处理，如何将众多业务场景需求在一个计算平台上得到满足，是我们面临的最大挑战。

基于对 Serverless的不断深入理解，结合产品在弹性调度方面的不断积累，我们开始了基于多租架构的Serverless异步任务处理系统的构建，利用异步化的访问方式，帮助用户托管请求，以服务化的手段帮助用户快速执行任务，处理异常，提供可靠的执行保障，结合异步化的结果投递能力，希望能够面向事件驱动，在线业务处理，Serverless Job/Task 等复杂业务场景，为客户带来更多价值。

构建一个面向多租场景的Serverless异步任务处理系统需要面临各种挑战；这个时候我们需要化繁为简，分析任务系统到底要做什么：任务分发， 任务调度， 任务执行。

Serverless本质是一个多租分时复用的商业模式，关于Serverless异步任务处理系统的挑战，结合任务处理系统的功能需求，这些挑战可以总结归类为三个方面：

第一，多租架构本身带来的挑战：包括租户隔离问题，多租资源管理，以及如何权衡隔离性和成本之间的矛盾，最后还需要关注多租架构下自动诊断，快速定位问题的挑战；

第二，业务类型多样性和资源供给之间的矛盾带来的挑战：资源需求多样化，客户可能需要多种资源，比如面向 CPU密集型、IO密集型、内存密集型等；运行环境多样化，客户运行业务逻辑时，需要为任务提供与其对应的运行环境，需要面对多种运行环境；运行时长不确定性，面对离线和在线场景的不同业务特征，实际任务的执行时长差异巨大；最后，不同业务类型流量特征不同，流量不可预知等问题带来的请求处理，任务调度和流控策略方面的挑战；

第三，任务管理本身需要面临的挑战：包括任务生命周期管理，运行操作、 任务去重，任务执行状态追踪以及任务结果投递等相关问题带来的挑战。

以上挑战也是企业在构建分布式业务系统时所面临的最核心问题，站在产品的角度，我们希望能够通过异步任务系统的构建，帮助用户解决分布式系统中的这些共性的典型问题。客户只需要关注自己的业务请求提交和执行结果，从请求提交到执行的过程中涉及的Serverless弹性能力，资源调度，系统流控及可靠执行，错误重试等细节无需用户关心，真正实现 Serverless 倡导的几个核心理念：极致弹性，无服务器运维、按需付费，最终帮助兑现Serverless对于客户的业务价值。

在讨论了Serverless异步任务系统构建面临的多种挑战之后，通过上面的分析，Serverless异步任务处理系统功能可以简单概括为以下四个核心模块：

①　请求托管：负责多租架构的任务托管、用户请求存储、获取用户请求以及执行用户请求，如何在多组架构下选择合适的隔离粒度，更好的实现用户的请求隔离，如何在用户隔离需求的基础上更好的权衡隔离和成本之间的平衡。

②　流量控制：通常用户选择异步任务处理系统，大概率源于请求和消费之间存在矛盾。如何帮助客户解决用户请求以及后端资源供给之间的矛盾，更好地执行用户的任务请求，是异步系统核心所在，流量控制至关重要。

③　执行管理：执行管理主要分为两个层面。首先，如何更好地执行任务，与流量控制更好的联动，如何用更好的方式调度资源从而更好地执行任务，这也是对系统底层调度的挑战。其次，如何管理任务请求，比如可能需要在任务执行过程中进行暂停、删除或批量操作，也需要对执行的任务提供状态追踪，了解其执行情况，并提供任务去重的能力。

④　目标投递：也可以叫结果投递，需要将任务最终执行结果返回给用户。关于结果投递，这里有多个思考，一种是如何将结果投递；另一种是如何以更好的方式将结果投递；对于前者比较直观，而对于后者，我们希望对于任务执行结果，能够提供更灵活的再次处理能力，因此在实现上支持将结果投递到函数计算、MQ，EventBridge等更通用的产品上，用户可以基于这些产品再次利用事件驱动或相关能力对于任务执行结果进行后续的再次处理，包括发送短信、webhook 等，实现与异步任务系统进行上下游联动。

2 Serverless 异步任务处理系统多租户架构演进

下图展示了一个典型的异步任务处理系统的基本模型，通过 API 的方式进行任务提交、任务调度，任务执行，最后完成执行结果的投递。

传统的任务处理框架中，通常会基于服务网关进行任务调度、负载均衡和流控策略等能力的建设，这也是分布式系统构建中最基本、但又最核心，最复杂，最需要人力投入重点建设的部分；后端实现通常都是基于进程粒度的内存队列和运行时层面的线程池模型完成具体的任务派发和执行。

Serverless 异步任务处理系统流程为：用户通过 API 的方式进行任务分发，请求到达Serverless服务网关之后，被存储到异步请求队列中，Async Service将开始接管这些请求，然后请求调度获取后端资源，将这些请求分配给具体的后端资源进行执行。该架构图中 Async Service负责了传统架构中请求Dispatcher、负载均衡，流控策略和资源调度的实现，这时候函数集群相当于抽象的分布式线程池模型，在函数计算模型下，实例之间相互隔离，且资源具备水平伸缩的能力，可以避免传统应用架构下单机资源限制导致的线程池容量问题及资源调度瓶颈问题，同时任务的执行环境并不会受整体业务系统运行时的限制，这也是Serverless异步任务系统相比传统任务系统的价值所在。

从Serverless任务处理系统的架构来看，其处理逻辑非常简单，大部分分布式系统依赖的能力全部由Async Service系统角色透明化的进行了实现，对于用户而言更多的是通过函数化编程的方式提供任务处理的实现逻辑，整体架构避免了对基于语言运行时线程池的依赖，整个函数计算集群提供了一个“无限”容量的“线程池”，通过服务化的方式，用户只需提交请求，其他并发处理、流控以及积压处理全部由 Serverless平台负责完成。当然在实际的执行过程中，需要结合业务特征对异步任务处理的并发度，错误重试策略及结果投递进行一些配置。

标签：系统,安装,命令,方式,配置,QSL 来源：

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

这篇关于基于 MQ 的分布式 Serverless 多租任务处理系统架构演进的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！