导读：快聘业务快速发展情况下，图文/AIGC 模板生产人力紧缺，技术借助码灵 D2C 和增长合图能力搭建伏羲工作台，助力实现业务模板快速自动化生产，推动了业务形态发展。

一、背景介绍

业务背景

“快聘”是快手于 2022 年推出覆盖蓝领群体的短视频平台蓝领招聘业务。通过构建以信任为中心的蓝领招聘关系和直播带岗模式，为用工企业和蓝领用户搭建就业平台。快手“快聘”早期叫“快招工”，进行品牌升级后叫“快聘”，自推出后，已为比亚迪、宁德时代、理想汽车、中航锂电、歌尔股份、立讯集团、海信集团等众多制造企业进行“直播带岗”。2022 年，快手“快聘”，引领直播带岗新模式，为招聘企业和蓝领用户搭建了沟通桥梁，每月吸引 2.5 亿人次的劳动者参与，全年直播场次超 500 万场，合作企业超 24 万家。

传统的商家缺乏内容经营的能力，所以快聘业务中，平台提供的 AIGC 和图文都是帮助商家提供账号经营矩阵的能力，辅助商家开播、发作品，运营内容生态，这也使得 AIGC 和图文是商家线索的重要来源。

图文/AIGC 模板生产过程中的问题

图文视频、AIGC 视频、直播贴图都是辅助快聘商家快速冷启的重要手段，其相似度很高，模板生产流程类似，生产过程比较耗费人力，效率低下。从不同视角出发，大家的痛点各不相同：

1.模板管理模糊，走查耗时长：生产过程为纯研发操作，模板管理比较模糊、走查交付流程不够便捷，在大量模板生产和交付场景下，由于缺少规范化操作，易出现返工或者重复工作。

2.研发生产效率低下：每次新增模板，即便是替换图片、移动位置、放大缩小等简单需求，都需要前端手动进行开发、压缩、上传等操作。由于缺少自动化能力，每新增一个模板约平均占用 0.3pd ~ 0.5pd，生产效率低下，在需求茂盛的情况下，极易出现人力短缺情况。

3.缺少自定义能力：商家对于图文工具的诉求点，除流量扶持以外，商家着重希望“可提供多样的海报模版”、“生成的海报可展示更多的文字信息”以及“编辑海报里的文字信息”。当前能力不能完全满足用户诉求，需要有更友好、更便捷的产品形式为用户服务。

二、业务目标

为有效解决上述问题，提升图文/AIGC 模板的生产效率与质量，特制定以下整体目标：

1.提供高效、规范化的 AIGC、图文模板生产 &消费方案，解决模板管理模糊、走查耗时长的问题。

2.通过 D2C 实现研发侧单个模板分钟级生产，解决模版生产效率问题。

3.通过通用 DSL 实现模版编辑和生图，解决模板自定义生产瓶颈。

三、解决方案：伏羲工作台

整体设计

结合业务目标，构建起以服务端-用户端为架构的伏羲工作台。整体设计如下：

关键的技术方案和挑战

01 搭建模板自动化生产流程

「实现方案」

• D2C 转码：通过自定义码灵插件实现 D2C 转码逻辑，根据设计稿以及打标信息完成 HTML 生成；

• 模板编辑：实现 HTML 模板的预览、二次编辑和发版；

• 模板生产：基于发版后的模板生成 ZIP，并通过当前后置的 server 链路生成最终的 AIGC、图文视频产物；

• 模板管理：实现模板的分类、查找、上下线等管理能力；

「成果（1.0 版本）」

1.0 版本上线后效果明显：

• 模版开发效率提升 95%：单模板开发到走查平均耗时从 0.5pd 降至 5 分钟；

• 规范了模板交付上线流程：模板生产、管理链路线上化，降低了设计 &产品的走查和运营成本。

02 缩短模板生产链路、提升模板生产性能

1.0 版本上线后，给业务带来了可观的收益，但也发现了一些问题：

• 图文生产链路长：爆款内容具有时效性，而图文模板生产需要走完整的需求开发测试流程，会因生产链路过长导致错失时机；

• 图文作品发布耗时长：手工链路目前的生图速度约 3~5s，发布耗时较长是当前手工图文发布量增长的一大阻碍；

• 可拓展性不强：当图文重新修改 UI 后，重新生成的模板会覆盖历史的代码修改，会造成返工的情况；同时 1.0 版本的描述产物为 html，不利于移动端模板自定义。

于是，我们探索基于增长生图的能力，拓展编辑器实现 NoCode 生产模板；同时切换底层链路将 Puppeteer 生图替换成 SVG 生图，加快生图速度；提高生图/二次编辑的可拓展性：

「快聘侧」

• 模板编辑：基于增长编辑器实现快聘图文自定义编辑器

• 模板生产：协同 server 切换生图链路，保障生图链路稳定性

编辑器设计

生图方案演变

「增长侧」

增长侧作为快聘生图服务的提供方，面临确保服务稳定性和高性能的挑战。为此，我们设定了明确的服务目标：

• 在高性能方面，希望能缩短生图任务的耗时，并充分利用机器资源；

• 在稳定性方面，我们关注内存和 CPU 的稳定性，采取了重试机制和多种兜底策略以提高生图的成功率。

服务流程

以上是服务经过多次优化升级后的最终流程图。下面简单描述一下：

1. 业务接入：申请租户 biz，新增租户；

2. 业务发送同步 rpc 请求，API 服务会先读取租户表判断是否有权限，有则继续流程，否则拒绝请求；

3. 然后请求进入 redis 流控中间件。通过中间件的请求继续流程，通过 rpc 调用将请求发送到调度引擎服务上。未通过的（即超出 qps 的）拒绝请求；

4. 进入调度引擎，会为任务新建批次、任务数据并写入数据库，并对参数进行预处理，而后通过 rpc 调用将请求发送到渲染服务上；

5. 渲染服务收到请求后，首先预下载相关资源，而后将 dsl 中的内容进行动态替换生成 svg，然后通过 rust 构造的二进制 svg 渲染器生产出最终的图片，而后上传 BS，并将结果返回。

分层架构

我们通过分层架构实现了一套渲染服务，显著提高了机器利用率。将 CPU 密集型任务（如渲染任务）与普通任务（如请求接收、发送、业务逻辑处理、参数预处理、数据库任务状态流转操作等）进行了分离。这种分离不仅有助于优化资源分配，还能确保每个任务都能在最适合的环境中高效运行。具体来说，分为以下三层：

• API 服务：负责处理网络请求，确保业务方与服务之间的高效通信。

• 调度服务：负责业务逻辑、数据预处理、数据库任务状态流转等任务，确保任务的顺畅运行。

• 渲染服务：专门处理 CPU 密集型的渲染任务。这些服务实例配置小、数量多，任务单一，能够快速处理复杂的渲染任务。

这种分层架构还带来了以下好处：

• 扩缩容便利：可以更方便地实现服务的横向扩展和收缩，确保系统的稳定性和可靠性。

• 资源预估准确：能够通过 QPS 较为准确地预估所需的核心渲染服务实例数，避免了机器资源的浪费。

性能保障

房聘生图链路场景需实时渲染大字报，因此对生图速度有一定的要求。我们采用 svg 方案，通过使用 rust 编译的高性能 svg 渲染器，可以将纯渲染耗时控制在毫秒级。同时为了构造渲染可用的 svg，我们提供了标准的 DSL 及动态化 svg 构造器。

并且相比于渠道旧生图链路，我们进行了以下升级优化：

• 异步转同步：旧生图链路通过 kafka 队列进行异步任务生产通知。新链路中，服务内部全部升级为 rpc 同步通信。

• 渲染集群配置升级：由几台大机器起多进程渲染，改为多台小机器主进程渲染。避免起杀子进程产生的额外时间消耗，大大节约了生图时间。

稳定性保障

在快聘生图链路服务的稳定性优化中，确保系统可靠性和持续可用性是满足用户需求的关键。随着业务量增加，服务面临内存管理、流量控制等挑战。接下来将介绍服务在内存稳定、流量控制及其他稳定性手段方面所实施的具体措施，以提升系统稳定性，降低故障风险，并在高并发场景下提供优质的生图服务体验。

【内存稳定】

resvg 存在堆内存不释放的问题：

https://github.com/thx/resvg-js/issues/216

在 staging 环境下压测（一台 2 核 6G 实例），生图 180 张左右会发生 OOM，导致服务不可用。由于业务优先级较高，采用了短期方案和长期方案。短期方案是快速满足业务的诉求以及服务的稳定性、成功率。长期方案是从根本上解决内存泄漏的问题。

短期方案：短期方案使用 pm2 进程管理器，预设进程内存阈值，当内存达到阈值时会自动重启服务。重启过程中会导致任务失败或请求丢失。为了降低失败率，我们在调度服务中加了失败重试逻辑并接入 KNGX 进行服务探活和流量分发。当服务重启时，当前任务会自动重试，并由 KNGX 转发到正常运行的实例上执行图片渲染任务。最终，失败率控制在了 0.05%以内。

该方案虽然可以满足业务需求稳定的提供生图服务，但还有两个缺陷：

• 未从根本解决内存泄露问题。

• 服务重启导致当前任务生图耗时偏高。

长期方案：短期方案上线后，秉承着“最高标准”，我们排查了全链路内存泄露问题。

• 修复了开源方案 resvg 堆内存不释放的问题，发布了 @killusion/resvg-js 修复版本的包。

• 主动回收了动态化 svg 构造器内占用的内存空间。

• 并排查服务全链路其他可能存在内存泄露，确保了内存的有效管理和及时回收。

去掉 pm2 自动重启策略，在预发环境，总计生图 18000 张，qps 30 持续 10 分钟发压，CPU、内存平稳结果无异常，生图成功率 100%。CPU 及内存使用率如下：

该方案解决了大流量情况下集群 OOM 风险导致服务可用性降低的风险。相同 QPS 配置机器资源，同比临时方案节省 33.33%的 CPU 和 77.78%的内存。

【流量控制】

我们在 API 服务中实现了基于 Redis 滑动窗口的流量控制中间件。

具体实现如下：

• 流量控制：以租户 biz 与请求名为 key，计算当前的请求量。当 QPS 在登记值范围内时，API 服务会均匀地将请求分发到调度服务上，进行业务逻辑处理、参数预处理、数据库读写等操作，然后再将请求均匀地分发到渲染服务上执行生图的任务。

• 流量保护：当 QPS 超过登记值时，超过部分的请求会被拒绝，以保护后续的核心集群，提高服务的稳定性。如有需要，可以配置流量预警通知。

• 扩缩容便利：在分层架构的基础上，可以轻松地对核心渲染服务进行扩缩容操作，能够有效应对 QPS 的变化，并且不会对其他服务造成影响，且不影响其他服务。

通过这种方式，我们不仅实现了高效的流量控制，还确保了系统的稳定性和可靠性。

【其他稳定性手段】

• Redis 降级策略：当 Redis 遇到异常时，实施降级策略，确保请求不经过 API 服务流控中间件，以避免所有请求被拒绝。

• 支持数据库动态切换：在服务内部动态监听 Mysql 数据库切换事件，事件触发后能自动执行重连接。避免了由于底层数据库切换，而连接不上数据库，导致服务不可用的问题。

• 容错策略：

• 内置兜底字体包：为了确保在任何情况下都能正常显示文本，我们内置了兜底字体包。这样即使在某些字体缺失的情况下，系统也能自动切换到备用字体，提高了生图成功率。

• 重试逻辑：在生图的过程中，如遇偶发异常，会自动触发重试机制。通过多次重试，也可提高生图成功率。

• 健全日志、告警体系：在服务全链路，关键节点进行了日志打点并按信息等级进行了上报，配置了 error 日志相关告警，以便及时发现问题、追溯问题、解决问题。

「成果（2.0 版本）」

2.0 版本上线后：

• 生图链路缩短，产品运营可以不经过 UI + 研发直接生成模板；

• 发布耗时缩短，相比较快聘图文生成旧链路平均耗时 4 秒左右，生图服务全链路耗时优化至 1 秒左右。

• 增加移动端自定义模板可用能力，描述产物将 html 替换成了标准 DSL。

四、总结与展望

经过近一年的建设，带来的变化和收益非常显著：

• 模板管理清晰：模板生产、管理链路线上化，降低了设计 &产品的走查和运营成本。

• 模板生产提效：模板生产无需研发介入，能节省研发 100% 人力；单次模板需求生产周期从一周缩短值 0.5 天，生产效率提升 95%。

• 可拓展性增强：生成的模板可快速修改重新上线；同时增加了移动端自定义模板可用能力；

在生产效率显著提升的条件下，我们的业务也突破瓶颈，伏羲工作台，我们的模板数量从百级别提升到万级别，在这个数量级前提下，至少节省了前端 1000+pd 的人力成本，带来的技术和业务收益相当客观！

码灵生产

合图生产

随着伏羲工作台和基础能力的完善，可以支持的业务场景更全面，模板自定义等功能已有较为完善的方案，相关的能力会跟随业务一起逐步成长迭代。