企业应用从微服务架构向 Serverless（无服务器）架构演进，开启了无服务器时代，面向无服务器计算领域的 Serverless 工作流也应运而生。许多 Serverless 应用程序不是由单个事件触发的简单函数，而是由一系列函数多个步骤组成的，而函数在不同步骤中由不同事件触发。Serverless 工作流用于将函数编排为协调的微服务应用程序。

Serverless 工作流由于自身可编排、有状态、持久化、可视化监控、异常处理、云服务集成等特性，适用于大部分应用场景。

当前大部分 Serverless Workflow 平台更多关注控制流程的编排，忽视了工作流中数据流的编排和高效传输，由于数据流相对简单，所以各大平台支持都比较好，但是对于文件转码等存在超大数据流的场景，当前各大平台没有给出很好的解决方案。

华为云 FunctionGraph 函数工作流 针对该场景，提出了 Serverless Streaming 的流式处理方案，支持毫秒级响应文件处理。

以一个图片处理的场景为例，用户想要执行一个图片压缩并且加水印的任务。这个场景在典型的工作流系统中，图片压缩和图片加水印的结果都是二进制文件格式，但是当前主流的 Serverless Workflow 平台在多个步骤之间传输上下文都只能支持文本格式传输，所以图片压缩和加水印的结果都需要经过 BASE64 或者其他转码方式转成文本进行数据流传输。

但是这种方案的限制和使用成本都比较高：

1、函数的 Response Body 通常有大小限制，所以这种方式无法处理超大文件。

2、执行结果转换为文本，需要消耗大量内存，内存成本比较高。

如何简单高效的进行文件处理，业界也给出了其他解决方案，如通过云存储进行中间结果转储、AWS 的 Lambda Object 文件转换方案。下面给出了这两个方案的优缺点分析。

方案一：中间结果通过云存储进行转储  

两个步骤之间的文件流通过云存储去传递，这种方案支持大文件流的传输，但是由于中间多了一次到云存储的网络传输，如果业务对时延要求不高，该方案问题不大， 但是对于时延敏感类业务，这种多出的时延是无法接受的。另外云存储转储需要额外的成本，如果调用量比较大，使用成本较高。

方案二：AWS Lambda Object 

AWS 对于这种文件处理场景，提出了基于 S3 和 Lambda 的 Lambda Object 的方案，参考 [1]，简单来说，是支持为 S3 文件桶的 getObject API 提供 Access Point，AccessPoint 可以指向某一个 Lambda 函数，在函数中可以对原来的桶数据文件进行修改，比如可以将原始视频转码，得到转码后的结果返回到客户端。虽然解决了时延和大文件处理的问题，但是这个方案强依赖 S3 的 API，用户无法进行流程编排，也无法通过事件触发，不是一个真正通用的方案。

总结

当前业界提供的各个方案或多或少存在一些局限性，没有办法在同时满足 低时延 的情况下支持 可编排 的文件处理。然而低时延和可编排都是大量客户所追求的关键能力，如何解决这些关键痛点，提升客户体验，成为了当前我们重点想要攻克的难题。

针对当前业界缺少高效，可编排的文件处理方案的痛点，华为云 FunctionGraph 函数工作流提出 Serverless Streaming 的流式可编排的文件处理解决方案，步骤与步骤之间通过数据流驱动，更易于用户理解。本章通过图片处理的例子解释该方案的实现机制。

如果需要驱动一个工作流执行，工作流系统需要处理两个部分：

1、控制流：控制工作流的步骤间流转，以及步骤对应的 Serverless 函数的执行。确保步骤与步骤之间有序执行。

2、数据流：控制整个工作流的数据流转，通常来说上一个步骤的输出是下一个步骤的输入，比如上述图片处理工作流中，图片压缩的结果是打水印步骤的输入数据。

在普通的服务编排中，由于需要精准控制各个服务的执行顺序，所以控制流是工作流的核心部分。然而在文件处理等流式处理场景中，对控制流的要求并不高，以上述图片处理场景举例，可以对大图片进行分块处理，图片压缩和加水印的任务不需要严格的先后顺序，图片压缩处理完一个分块可以直接流转到下一个步骤，而不需要等待图片压缩把所有分块处理完再开始加水印的任务。

在 Serverless Streaming 的流程中，弱化控制流中步骤之间的先后执行顺序，允许异步同时执行，步骤与步骤之间的交互通过数据流驱动。其中数据流的控制通过 Stream Bridge 组件来实现。

同时函数 SDK 增加流式数据返回接口，用户不需要将整个文件内容返回，而是通过 gRPC Stream 的方式将数据写入到 Stream Bridge，Stream Bridge 用来分发数据流到下一个步骤的函数 Pod 中。

这种方式存在如下优点：

1、由于控制流的弱化，完全通过数据流来驱动流程执行，不需要再强限制步骤之间完成的先后顺序，如图片处理场景中，压缩和加水印的步骤可以做到完全并行执行，这样可以加速整个流程的执行速度。

2、每次请求都开辟独立缓冲区，缓冲区限制大小，数据流仅在内网传输，保证整体数据传输的可靠性和安全性。

3、不依赖其他外部服务，使用成本低。

4、对于开发人员来讲，只需要关注数据流的处理，而不需要关心数据流如何转发，如何存储，降低开发难度。

5、底层流式传输通过 gRPC 进行，整体数据传输效率高。

在函数工作流 FunctionGraph 中开发文件处理工作流  当前函数工作流 FunctionGraph 已经基于上述方案支持了在函数工作流中进行数据流处理，并且将结果通过流数据的方式返回到客户端，以构建一个图片处理工作流为例：

1、首先创建一个图片压缩的函数，其中代码在处理返回数据通过 ctx.Write() 函数将结果以流式数据的形式返回。

说明：函数工作流 FunctionGraph 通过 ctx.Write() 函数提供了流式返回的能力，对开发者来说，只需要将最终结果通过流的方式返回，而不需要关注网络传输的细节。

2、在函数控制台中启用该函数的流式返回能力。

3、用上面的方式完成其他函数的编写，最后在 FunctionGraph 的函数流控制台完成工作流编排。

4、调用工作流的同步执行接口，获取最终结果的文件流，数据将以 chunked 流式返回的方式返回到客户端。

点击此处前往详情→

针对图片处理的具体场景，我们测试对比了不同大小图片（333k、1m、4m、7m、10m、12m）进行图片切割和图片压缩的场景，由于 BASE64 转码方案无法支持大文件，AWS Lambda Object 方案无法支持编排，所以这里只对比使用 OBS 转储方案和基于流式返回的 Servlerss Streaming 方案的时延数据。

从测试数据可以看出，响应时延和端到端时延使用流式返回方案后都得到了不同程度的降低。其中响应时延降低幅度较大，OBS 转储方案响应时延随着图片大小增大，响应时延呈线性上升，超过 4M 的图片响应时延就达到秒级，使用流式返回方案后，响应时延持续稳定在毫秒级的水平。从中可以发现，基于 Serverless Streaming 的流式返回方案不仅具备流式处理和可编排 的能力，并且在文件处理场景中可以 显著降低时延 ，从多个方面提升了用户使用体验。

点击此处前往效果详情→