導(dǎo)讀：快聘業(yè)務(wù)快速發(fā)展情況下，圖文/AIGC模板生產(chǎn)人力緊缺，技術(shù)借助碼靈D2C 和增長合圖能力搭建伏羲工作臺(tái)，助力實(shí)現(xiàn)業(yè)務(wù)模板快速自動(dòng)化生產(chǎn)，推動(dòng)了業(yè)務(wù)形態(tài)發(fā)展。

一、背景介紹

業(yè)務(wù)背景

“快聘”是快手于2022年推出覆蓋藍(lán)領(lǐng)群體的短視頻平臺(tái)藍(lán)領(lǐng)招聘業(yè)務(wù)。通過構(gòu)建以信任為中心的藍(lán)領(lǐng)招聘關(guān)系和直播帶崗模式，為用工企業(yè)和藍(lán)領(lǐng)用戶搭建就業(yè)平臺(tái)?？焓帧翱炱浮痹缙诮小翱煺泄ぁ?，進(jìn)行品牌升級后叫“快聘”，自推出后，已為比亞迪、寧德時(shí)代、理想汽車、中航鋰電、歌爾股份、立訊集團(tuán)、海信集團(tuán)等眾多制造企業(yè)進(jìn)行“直播帶崗”。?2022年，快手“快聘”，引領(lǐng)直播帶崗新模式，為招聘企業(yè)和藍(lán)領(lǐng)用戶搭建了溝通橋梁，每月吸引2.5億人次的勞動(dòng)者參與，全年直播場次超500萬場，合作企業(yè)超24萬家。

傳統(tǒng)的商家缺乏內(nèi)容經(jīng)營的能力，所以快聘業(yè)務(wù)中，平臺(tái)提供的 AIGC 和圖文都是幫助商家提供賬號經(jīng)營矩陣的能力，輔助商家開播、發(fā)作品，運(yùn)營內(nèi)容生態(tài)，這也使得AIGC和圖文是商家線索的重要來源。

圖文/AIGC模板生產(chǎn)過程中的問題

圖文視頻、AIGC視頻、直播貼圖都是輔助快聘商家快速冷啟的重要手段，其相似度很高，模板生產(chǎn)流程類似，生產(chǎn)過程比較耗費(fèi)人力，效率低下。從不同視角出發(fā)，大家的痛點(diǎn)各不相同：

1.模板管理模糊，走查耗時(shí)長：生產(chǎn)過程為純研發(fā)操作，模板管理比較模糊、走查交付流程不夠便捷，在大量模板生產(chǎn)和交付場景下，由于缺少規(guī)范化操作，易出現(xiàn)返工或者重復(fù)工作。

2.研發(fā)生產(chǎn)效率低下：每次新增模板，即便是替換圖片、移動(dòng)位置、放大縮小等簡單需求，都需要前端手動(dòng)進(jìn)行開發(fā)、壓縮、上傳等操作。由于缺少自動(dòng)化能力，每新增一個(gè)模板約平均占用 0.3pd ~ 0.5pd，生產(chǎn)效率低下，在需求茂盛的情況下，極易出現(xiàn)人力短缺情況。

3.缺少自定義能力：商家對于圖文工具的訴求點(diǎn)，除流量扶持以外，商家著重希望“可提供多樣的海報(bào)模版”、“生成的海報(bào)可展示更多的文字信息”以及“編輯海報(bào)里的文字信息”。當(dāng)前能力不能完全滿足用戶訴求，需要有更友好、更便捷的產(chǎn)品形式為用戶服務(wù)。

二、業(yè)務(wù)目標(biāo)

為有效解決上述問題，提升圖文/AIGC 模板的生產(chǎn)效率與質(zhì)量，特制定以下整體目標(biāo)：

1.提供高效、規(guī)范化的AIGC、圖文模板生產(chǎn)&消費(fèi)方案，解決模板管理模糊、走查耗時(shí)長的問題。

2.通過D2C實(shí)現(xiàn)研發(fā)側(cè)單個(gè)模板分鐘級生產(chǎn)，解決模版生產(chǎn)效率問題。

3.通過通用DSL實(shí)現(xiàn)模版編輯和生圖，解決模板自定義生產(chǎn)瓶頸。

三、解決方案：伏羲工作臺(tái)

整體設(shè)計(jì)

結(jié)合業(yè)務(wù)目標(biāo)，構(gòu)建起以服務(wù)端-用戶端為架構(gòu)的伏羲工作臺(tái)。整體設(shè)計(jì)如下：

關(guān)鍵的技術(shù)方案和挑戰(zhàn)

01 搭建模板自動(dòng)化生產(chǎn)流程

「實(shí)現(xiàn)方案」

• D2C轉(zhuǎn)碼：通過自定義碼靈插件實(shí)現(xiàn)D2C轉(zhuǎn)碼邏輯，根據(jù)設(shè)計(jì)稿以及打標(biāo)信息完成HTML生成；
• 模板編輯：實(shí)現(xiàn)HTML模板的預(yù)覽、二次編輯和發(fā)版；
• 模板生產(chǎn)：基于發(fā)版后的模板生成ZIP，并通過當(dāng)前后置的server鏈路生成最終的AIGC、圖文視頻產(chǎn)物；
• 模板管理：實(shí)現(xiàn)模板的分類、查找、上下線等管理能力；

「成果（1.0版本）」

1.0版本上線后效果明顯：

• 模版開發(fā)效率提升95%：單模板開發(fā)到走查平均耗時(shí)從0.5pd降至5分鐘；
• 規(guī)范了模板交付上線流程：模板生產(chǎn)、管理鏈路線上化，降低了設(shè)計(jì)&產(chǎn)品的走查和運(yùn)營成本。

02 縮短模板生產(chǎn)鏈路、提升模板生產(chǎn)性能

1.0版本上線后，給業(yè)務(wù)帶來了可觀的收益，但也發(fā)現(xiàn)了一些問題：

• 圖文生產(chǎn)鏈路長：爆款內(nèi)容具有時(shí)效性，而圖文模板生產(chǎn)需要走完整的需求開發(fā)測試流程，會(huì)因生產(chǎn)鏈路過長導(dǎo)致錯(cuò)失時(shí)機(jī)；
• 圖文作品發(fā)布耗時(shí)長：手工鏈路目前的生圖速度約3~5s，發(fā)布耗時(shí)較長是當(dāng)前手工圖文發(fā)布量增長的一大阻礙；
• 可拓展性不強(qiáng)：當(dāng)圖文重新修改UI后，重新生成的模板會(huì)覆蓋歷史的代碼修改，會(huì)造成返工的情況；同時(shí)1.0版本的描述產(chǎn)物為html，不利于移動(dòng)端模板自定義。

于是，我們探索基于增長生圖的能力，拓展編輯器實(shí)現(xiàn)NoCode生產(chǎn)模板；同時(shí)切換底層鏈路將Puppeteer生圖替換成SVG生圖，加快生圖速度；提高生圖/二次編輯的可拓展性：

「快聘側(cè)」

• 模板編輯：基于增長編輯器實(shí)現(xiàn)快聘圖文自定義編輯器
• 模板生產(chǎn)：協(xié)同server切換生圖鏈路，保障生圖鏈路穩(wěn)定性

編輯器設(shè)計(jì)

生圖方案演變

「增長側(cè)」

增長側(cè)作為快聘生圖服務(wù)的提供方，面臨確保服務(wù)穩(wěn)定性和高性能的挑戰(zhàn)。為此，我們設(shè)定了明確的服務(wù)目標(biāo)：

• 在高性能方面，希望能縮短生圖任務(wù)的耗時(shí)，并充分利用機(jī)器資源；
• 在穩(wěn)定性方面，我們關(guān)注內(nèi)存和CPU的穩(wěn)定性，采取了重試機(jī)制和多種兜底策略以提高生圖的成功率。
  

服務(wù)流程

以上是服務(wù)經(jīng)過多次優(yōu)化升級后的最終流程圖。下面簡單描述一下：

1. 業(yè)務(wù)接入：申請租戶biz，新增租戶；

2. 業(yè)務(wù)發(fā)送同步rpc請求，API服務(wù)會(huì)先讀取租戶表判斷是否有權(quán)限，有則繼續(xù)流程，否則拒絕請求；

3. 然后請求進(jìn)入redis 流控中間件。通過中間件的請求繼續(xù)流程，通過rpc調(diào)用將請求發(fā)送到調(diào)度引擎服務(wù)上。未通過的（即超出qps的）拒絕請求；

4. 進(jìn)入調(diào)度引擎，會(huì)為任務(wù)新建批次、任務(wù)數(shù)據(jù)并寫入數(shù)據(jù)庫，并對參數(shù)進(jìn)行預(yù)處理，而后通過rpc調(diào)用將請求發(fā)送到渲染服務(wù)上；

5. 渲染服務(wù)收到請求后，首先預(yù)下載相關(guān)資源，而后將dsl中的內(nèi)容進(jìn)行動(dòng)態(tài)替換生成svg，然后通過rust構(gòu)造的二進(jìn)制svg渲染器生產(chǎn)出最終的圖片，而后上傳BS，并將結(jié)果返回。

分層架構(gòu)

我們通過分層架構(gòu)實(shí)現(xiàn)了一套渲染服務(wù)，顯著提高了機(jī)器利用率。將CPU密集型任務(wù)（如渲染任務(wù)）與普通任務(wù)（如請求接收、發(fā)送、業(yè)務(wù)邏輯處理、參數(shù)預(yù)處理、數(shù)據(jù)庫任務(wù)狀態(tài)流轉(zhuǎn)操作等）進(jìn)行了分離。這種分離不僅有助于優(yōu)化資源分配，還能確保每個(gè)任務(wù)都能在最適合的環(huán)境中高效運(yùn)行。具體來說，分為以下三層：

• ?API服務(wù)：負(fù)責(zé)處理網(wǎng)絡(luò)請求，確保業(yè)務(wù)方與服務(wù)之間的高效通信。
• 調(diào)度服務(wù)：負(fù)責(zé)業(yè)務(wù)邏輯、數(shù)據(jù)預(yù)處理、數(shù)據(jù)庫任務(wù)狀態(tài)流轉(zhuǎn)等任務(wù)，確保任務(wù)的順暢運(yùn)行。
• 渲染服務(wù)：專門處理CPU密集型的渲染任務(wù)。這些服務(wù)實(shí)例配置小、數(shù)量多，任務(wù)單一，能夠快速處理復(fù)雜的渲染任務(wù)。

這種分層架構(gòu)還帶來了以下好處：

• 擴(kuò)縮容便利：可以更方便地實(shí)現(xiàn)服務(wù)的橫向擴(kuò)展和收縮，確保系統(tǒng)的穩(wěn)定性和可靠性。
• 資源預(yù)估準(zhǔn)確：能夠通過QPS較為準(zhǔn)確地預(yù)估所需的核心渲染服務(wù)實(shí)例數(shù)，避免了機(jī)器資源的浪費(fèi)。

性能保障

房聘生圖鏈路場景需實(shí)時(shí)渲染大字報(bào)，因此對生圖速度有一定的要求。我們采用svg方案，通過使用 rust 編譯的高性能svg渲染器，可以將純渲染耗時(shí)控制在毫秒級。同時(shí)為了構(gòu)造渲染可用的svg，我們提供了標(biāo)準(zhǔn)的DSL及動(dòng)態(tài)化svg構(gòu)造器。

并且相比于渠道舊生圖鏈路，我們進(jìn)行了以下升級優(yōu)化：

• 異步轉(zhuǎn)同步：舊生圖鏈路通過kafka隊(duì)列進(jìn)行異步任務(wù)生產(chǎn)通知。新鏈路中，服務(wù)內(nèi)部全部升級為rpc同步通信。
• 渲染集群配置升級：由幾臺(tái)大機(jī)器起多進(jìn)程渲染，改為多臺(tái)小機(jī)器主進(jìn)程渲染。避免起殺子進(jìn)程產(chǎn)生的額外時(shí)間消耗，大大節(jié)約了生圖時(shí)間。

穩(wěn)定性保障

在快聘生圖鏈路服務(wù)的穩(wěn)定性優(yōu)化中，確保系統(tǒng)可靠性和持續(xù)可用性是滿足用戶需求的關(guān)鍵。隨著業(yè)務(wù)量增加，服務(wù)面臨內(nèi)存管理、流量控制等挑戰(zhàn)。接下來將介紹服務(wù)在內(nèi)存穩(wěn)定、流量控制及其他穩(wěn)定性手段方面所實(shí)施的具體措施，以提升系統(tǒng)穩(wěn)定性，降低故障風(fēng)險(xiǎn)，并在高并發(fā)場景下提供優(yōu)質(zhì)的生圖服務(wù)體驗(yàn)。

【內(nèi)存穩(wěn)定】

resvg存在堆內(nèi)存不釋放的問題：

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

在staging環(huán)境下壓測（一臺(tái)2核6G實(shí)例），生圖180張左右會(huì)發(fā)生OOM，導(dǎo)致服務(wù)不可用。由于業(yè)務(wù)優(yōu)先級較高，采用了短期方案和長期方案。短期方案是快速滿足業(yè)務(wù)的訴求以及服務(wù)的穩(wěn)定性、成功率。長期方案是從根本上解決內(nèi)存泄漏的問題。

短期方案：短期方案使用pm2進(jìn)程管理器，預(yù)設(shè)進(jìn)程內(nèi)存閾值，當(dāng)內(nèi)存達(dá)到閾值時(shí)會(huì)自動(dòng)重啟服務(wù)。重啟過程中會(huì)導(dǎo)致任務(wù)失敗或請求丟失。為了降低失敗率，我們在調(diào)度服務(wù)中加了失敗重試邏輯并接入KNGX進(jìn)行服務(wù)探活和流量分發(fā)。當(dāng)服務(wù)重啟時(shí)，當(dāng)前任務(wù)會(huì)自動(dòng)重試，并由KNGX轉(zhuǎn)發(fā)到正常運(yùn)行的實(shí)例上執(zhí)行圖片渲染任務(wù)。最終，失敗率控制在了0.05%以內(nèi)。

該方案雖然可以滿足業(yè)務(wù)需求穩(wěn)定的提供生圖服務(wù)，但還有兩個(gè)缺陷：

• 未從根本解決內(nèi)存泄露問題。
• 服務(wù)重啟導(dǎo)致當(dāng)前任務(wù)生圖耗時(shí)偏高。
  
  

長期方案：短期方案上線后，秉承著“最高標(biāo)準(zhǔn)”，我們排查了全鏈路內(nèi)存泄露問題。

• 修復(fù)了開源方案resvg堆內(nèi)存不釋放的問題，發(fā)布了@killusion/resvg-js修復(fù)版本的包。
• 主動(dòng)回收了動(dòng)態(tài)化svg構(gòu)造器內(nèi)占用的內(nèi)存空間。
• 并排查服務(wù)全鏈路其他可能存在內(nèi)存泄露，確保了內(nèi)存的有效管理和及時(shí)回收。

去掉pm2自動(dòng)重啟策略，在預(yù)發(fā)環(huán)境，總計(jì)生圖18000張，qps 30持續(xù)10分鐘發(fā)壓，CPU、內(nèi)存平穩(wěn)結(jié)果無異常，生圖成功率100%。CPU及內(nèi)存使用率如下：

該方案解決了大流量情況下集群OOM風(fēng)險(xiǎn)導(dǎo)致服務(wù)可用性降低的風(fēng)險(xiǎn)。相同QPS配置機(jī)器資源，同比臨時(shí)方案節(jié)省33.33%的CPU和77.78%的內(nèi)存。

【流量控制】?

我們在API服務(wù)中實(shí)現(xiàn)了基于Redis滑動(dòng)窗口的流量控制中間件。

具體實(shí)現(xiàn)如下：

• 流量控制：以租戶biz與請求名為key，計(jì)算當(dāng)前的請求量。當(dāng)QPS在登記值范圍內(nèi)時(shí)，API服務(wù)會(huì)均勻地將請求分發(fā)到調(diào)度服務(wù)上，進(jìn)行業(yè)務(wù)邏輯處理、參數(shù)預(yù)處理、數(shù)據(jù)庫讀寫等操作，然后再將請求均勻地分發(fā)到渲染服務(wù)上執(zhí)行生圖的任務(wù)。
• 流量保護(hù)：當(dāng)QPS超過登記值時(shí)，超過部分的請求會(huì)被拒絕，以保護(hù)后續(xù)的核心集群，提高服務(wù)的穩(wěn)定性。如有需要，可以配置流量預(yù)警通知。
• 擴(kuò)縮容便利：在分層架構(gòu)的基礎(chǔ)上，可以輕松地對核心渲染服務(wù)進(jìn)行擴(kuò)縮容操作，能夠有效應(yīng)對QPS的變化，并且不會(huì)對其他服務(wù)造成影響，且不影響其他服務(wù)。

通過這種方式，我們不僅實(shí)現(xiàn)了高效的流量控制，還確保了系統(tǒng)的穩(wěn)定性和可靠性。

【其他穩(wěn)定性手段】?

• Redis 降級策略：當(dāng)Redis遇到異常時(shí)，實(shí)施降級策略，確保請求不經(jīng)過API服務(wù)流控中間件，以避免所有請求被拒絕。
• 支持?jǐn)?shù)據(jù)庫動(dòng)態(tài)切換：在服務(wù)內(nèi)部動(dòng)態(tài)監(jiān)聽Mysql數(shù)據(jù)庫切換事件，事件觸發(fā)后能自動(dòng)執(zhí)行重連接。避免了由于底層數(shù)據(jù)庫切換，而連接不上數(shù)據(jù)庫，導(dǎo)致服務(wù)不可用的問題。
• 容錯(cuò)策略：

• 內(nèi)置兜底字體包：為了確保在任何情況下都能正常顯示文本，我們內(nèi)置了兜底字體包。這樣即使在某些字體缺失的情況下，系統(tǒng)也能自動(dòng)切換到備用字體，提高了生圖成功率。
  
• 重試邏輯：在生圖的過程中，如遇偶發(fā)異常，會(huì)自動(dòng)觸發(fā)重試機(jī)制。通過多次重試，也可提高生圖成功率。

• 健全日志、告警體系：在服務(wù)全鏈路，關(guān)鍵節(jié)點(diǎn)進(jìn)行了日志打點(diǎn)并按信息等級進(jìn)行了上報(bào)，配置了error日志相關(guān)告警，以便及時(shí)發(fā)現(xiàn)問題、追溯問題、解決問題。

「成果（2.0版本）」

2.0版本上線后：

• 生圖鏈路縮短，產(chǎn)品運(yùn)營可以不經(jīng)過UI + 研發(fā)直接生成模板；
• 發(fā)布耗時(shí)縮短，相比較快聘圖文生成舊鏈路平均耗時(shí)4秒左右，生圖服務(wù)全鏈路耗時(shí)優(yōu)化至1秒左右。
• 增加移動(dòng)端自定義模板可用能力，描述產(chǎn)物將html替換成了標(biāo)準(zhǔn)DSL。

四、總結(jié)與展望

經(jīng)過近一年的建設(shè)，帶來的變化和收益非常顯著：

• 模板管理清晰：模板生產(chǎn)、管理鏈路線上化，降低了設(shè)計(jì)&產(chǎn)品的走查和運(yùn)營成本。
• 模板生產(chǎn)提效：模板生產(chǎn)無需研發(fā)介入，能節(jié)省研發(fā) 100% 人力；單次模板需求生產(chǎn)周期從一周縮短值0.5天，生產(chǎn)效率提升 95%。
• 可拓展性增強(qiáng)：生成的模板可快速修改重新上線；同時(shí)增加了移動(dòng)端自定義模板可用能力；

在生產(chǎn)效率顯著提升的條件下，我們的業(yè)務(wù)也突破瓶頸，伏羲工作臺(tái)，我們的模板數(shù)量從百級別提升到萬級別，在這個(gè)數(shù)量級前提下，至少節(jié)省了前端1000+pd的人力成本，帶來的技術(shù)和業(yè)務(wù)收益相當(dāng)客觀！

碼靈生產(chǎn)

合圖生產(chǎn)

隨著伏羲工作臺(tái)和基礎(chǔ)能力的完善，可以支持的業(yè)務(wù)場景更全面，模板自定義等功能已有較為完善的方案，相關(guān)的能力會(huì)跟隨業(yè)務(wù)一起逐步成長迭代。