導讀：快聘業務快速發展情況下，圖文/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的人力成本，帶來的技術和業務收益相當客觀！

碼靈生產

合圖生產

隨著伏羲工作臺和基礎能力的完善，可以支持的業務場景更全面，模板自定義等功能已有較為完善的方案，相關的能力會跟隨業務一起逐步成長迭代。