前言

随着互联网与软件的发展，除了程序员，架构师也是越来越火的职业。他们伴随着项目的整个生命过程，他们更像是传统工业的设计师，将项目当做生命一般细心雕琢。

目前对于项目架构而言，基本都会需要设计的几个架构。

1、业务架构

项目或者产品的市场定位、需求范围、作用场景都是需要在项目启动初期进行系统性分析的。在设计业务架构中，架构师还需要明确角色。我看过很多关于架构的文章，谈到角色的很少。

什么是角色？

例如：商场作为一个整体系统，角色就有消费者、店员、收费员、保安等等。各个角色完成好自己角色所需要承担的任务，整体系统就能完美的运行。

对应到软件系统中，根据产品的定位和需求，也会有着对照的角色，比如：用户、数据审核者、产品制作者、运维人员等。在项目启动初期，架构师需要对项目中的每个角色做好职责定位，我相信在这点上，大部分开发同学在工作中，或多或少都有过职责不明确带来的困扰。

2、技术架构

在软件项目研发过程中，我们会用到许多外部组件。在使用组件中，架构师必须结合业务需求合理的选择各个组件。项目是个生命，她会成长，架构师需要明白如果一开始就选择重量级组件会让还是个孩童的项目不受重负，架构师也需要明白如果技术架构的设计不具备拓展性，那么这个孩子无法茁壮成长。所以技术架构尤为重要。

3、物理架构

物理架构又叫做部署架构，项目产品如果要在生产环境稳定运行，一个稳定又高效的物理架构是必不可少的。而且往往物理架构和技术架构是相辅相成的，性能监控、异常告警、业务日志等等设计，都是为了让项目做更好的自己。

高并发任务执行架构

在我十年的工作中，业务相关、中间件、大数据都有做过。本文主要分享一下高并发任务执行框架设计，会由浅入深的讲述一下设计演化过程。如果你不只是想做业务后端开发，那么本文会给你一个全新的视野。

需求场景

我们列一下该项目的需求场景，看看工作中是否遇到过。

1、有个复杂的数据需要制作，而且制作的时间很长，无法让请求方持续等待。所以请求方只能给你个回调地址，需要你完成这个制作后将产物通知他。

2、复杂的制作过程需要消耗资源，而且资源有限，无法无限量提供。如果你有接触过AI，就会比较了解资源有限的感受。除了ASR、TTS这类识别类型的AI功能能做到近实时的反馈，大部分的算法在运行的时候都会消耗整张显卡，而且耗时很长。

初看场景，很多后端可能会第一时间想到elastic-job（一个分布式任务调度框架）。即便你熟悉使用elastic-job，一开始就选择重框架是不是有种杀鸡用牛刀的感觉。不着急，我们一步步分析，一步步设计。

业务架构设计

高度抽象一下我们的业务，对产品设计者而言，貌似是个简单的不能再简单的东西。等到了技术架构，我们深入分析其中演化的功能点，就会发现这是个庞大的机器。我们先给他起个简单的名字：Task Execution Engine（缩写:TEE）

技术架构设计

下面我们开始进行核心模块的技术架构设计，按照我们的初始需求开始我们的设计旅程。

初始设计

设计说明：

1、业务后端发出q1请求，我们首先需要对该请求的参数做矫正，为了可用性考虑。

2、参数校验过后，给到执行引擎模块。执行引擎主要的职责有从资源表获取资源数据、将任务参数与资源参数封装到任务对象内、将任务提交线程池。有一点要说明执行引擎最好使用队列模式，任务先进队列，可以通过while循环方式或者定时线程池都可以，后面会推荐更好的。

3、任务执行的状态与结果需要同步到数据库中，建议使用mysql。

小结：

按照初始需求，该设计相对比较简单，完全够用了。但是按照产品的迭代，业务方的需求不会仅限于此。继续演化。

演化阶段一

随着业务的上线，业务端会马上迎来新的问题。

1、由于提交的任务太多了，排在后面的任务迟迟无法等到自己获取到资源执行任务。当然我们可以完全靠增加资源来解决，但是资源的数量在产品前期是不可知的。所以需要有一些策略，比如让用户可以取消自己任务，而不是一直等待。

2、任务的种类开始增加，业务端不满足于单一制作，开始要求多样化。

3、任务的执行过程开始需要用到其他资源，不再是一个资源对一个任务的模式了。

4、任务的整体执行情况不可知，需要一定的量化分析，至少让业务组知道每天的任务成功率。

按照需求进行第二版的设计，在尽量不改变原来整体设计的情况下，补充功能。

设计说明：

1、为了解决排队问题，增加了双队列算法来解决。用图解的方式解释一下双队列。

逻辑简单说明一下，任务优先提交至执行队列，引擎的定时读取队列的顺序优先为等待队列。如果等待队列中的任务可以获取所需资源，则立即启动线程执行，否则原封不动回到等待队列。引擎其次读取执行队列，如果无法获取资源则进入等待队列，如获取资源，则立即启动线程执行。

那么取消队列，则只需要将队列中的任务踢出队列即可。在送回队里的过程中，一定要保证队列的有序性。

2、创建了任务池，增加了任务封装层，在任务池中挑选需要执行的任务类。

3、增加了策略机模块，添加资源调度策略，由资源调度策略堆任务所需资源合理分配。可以由业务方提供分配方案，尽可能保证任务的公平性。

4、数据库增加统计表，可以考虑使用定时任务，将任务表的数据统计存入统计表。

小结：

现在看上去已经比较完善了，合理了任务调度、增加了任务种类、合理的资源调度，好像还不错。但是产品总会有新要求的，那么继续演化。