节省前端1000+pd人力成本！快手快聘「伏羲工作台」技术实践全解析

导读：快聘业务快速发展情况下，图文/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的人力成本，带来的技术和业务收益相当客观！

码灵生产

合图生产

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