導讀：短視頻在如今已經是非常重要的內容載體，在短視頻播放時如給予用戶進行如相關視頻、商品、遊戲、活動等優質內容的推薦，不僅能提升用戶的使用粘性，也能極大的豐富內容的生態，本文會詳細介紹在短視頻 APP 相關頁面做內容推薦入口位置的設計實踐。

一、背景

1.1 推薦產品的流量精細化運營

搜索行爲的用戶通常較爲明確自己的需求和問題，技術的重心是針對問題返回準確的答案。推薦產品則反之，用戶消遣時間是主要的目的，技術的重心是幫助用戶挖掘潛在需求，需要通過與用戶的交互逐步瞭解用戶的喜好，給予用戶提供相應的內容、服務等。如果說用戶觀看完當前視頻再次請求，我們給予推薦新的視頻主要是基於用戶緯度進行內容推薦，那在當前視頻播放時我們在本頁面及時推薦一些內容服務就是細化到用戶 + 視頻維度，這就是短視頻相關資源推薦位的意義和價值。

1.2. 資源位示例

1.3 這個位置要具備怎樣的能力

通用性： 由於短視頻內容可能在多個 APP 或者產品中都會進行分發，並且主要分發形式都是視頻列表頁、視頻落地頁等，所以這個位置是共性需求。再此基礎上如果每個產品獨立去開發這個位置就是重複勞動，成本高昂，所以我們需要一個通用的能力來解決這個問題。

穩定性： 短視頻的分發的量級是非常大的，並且經常出現在 APP 首頁這樣關鍵的位置，那麼服務的穩定性無疑是非常重要的一環，極端情況下服務徹底不可用也不能影響視頻播放本身。

擴展性： 如示例所示這個位置除了提供視頻、文章等內容服務外，還會提供活動推廣、遊戲下載、商品掛載等服務，這些內容及服務可能來自於各個產品線，怎麼快速、低成本的接入管理這些產品線的內容和服務是快速豐富這個位置能力的關鍵因素。

智能性： 這個位置接入的內容和服務足夠多後，更重要的就是給予用戶推薦更合適的內容和服務，以及在一些服務的性能出現問題進行降級，讓這個位置充分的發揮其價值。

二、設計與實踐

2.1 抽象化、標準化解決通用性問題

資源位最核心的能力就是：

1. 給誰分發展示

2. 分發什麼內容

由此可以抽象出以下位置分發能力和卡片內容定義兩個部分。

產品側只需要定義好卡片的樣式內容和決定分發的位置和人羣等就可以將自身內容、服務輸出給指定用戶，這就是第一個階段，提供通用性內容服務 -> 用戶的通路。

2.2 高併發下保證可用性、降低平響

作爲一個面向多個產品線的基礎服務，應用場景如首頁、活動頁等，qps 的量級將至少以 10w 爲單位計數，設計上響應時間需要穩定控制在 50ms 內，從而避免對產品本身的性能造成影響。

2.2.1 降級策略保證整體可用性

1. 降級的定義

因流量或服務器壓力劇增，可能引發服務宕機或級聯性崩潰。在有限資源的情況下，服務端不得不按優先級區分處理業務，即優先保證核心業務的正常運行，而對非核心業務用做簡單折中處理，如快速失敗，或返回緩存數據等等，避免佔用更多資源，稱之爲服務降級。降級的目的是在服務自身性能達到瓶頸，或網絡硬件應用等依賴的資源出現異常時，儘可能保證核心業務正常運行，進一步保證系統整體的可用性和穩定性。

2. 降級的特點

• 降級是服務的自我保護機制，爲了整體不被拉跨，放棄部分服務的可用性，丟車保帥。

• 因非核心任務被降級處理，從用戶角度來看，現象就是可能服務變的不可訪問，或者數據過期，因此一定上程度降低了用戶體驗。

3. 常用策略

限流 (拒絕, 緩存), 熔斷 (快速失敗, 緩存)

• 限流：從一定程度上來說，大流量是增加服務器壓力的萬惡之源，短時間內的高併發，服務器會啓用大量線程池，CPU 切換壓力增大，如果線程池達到上限，更多請求會阻塞在內存空間，各服務接口都會受影響。如果同步訪問數據庫，或遠程服務，磁盤讀寫性能和網絡延遲會成爲性能瓶頸，影響 TPS，加上高併發請求，服務器容易宕機。

• 熔斷

• 降級開關

4. 選取策略

資源卡片的內容和服務大多由內容服務團隊提供，所以我們需要實時監測這些服務，避免由於某個服務的問題導致整體服務出現問題。

• 設置熔斷開關，如調用服務可用性低於設定閾值，直接熔斷斷開調用，直至後續多時間片監測確認服務恢復。

• 制定性能分發權重，可用性較差、平均響應時長較長的服務降低其分發權重。

2.2.2 存儲優化，提升平響、穩定性

1. 業務需求和特徵

業務數據特點：

• 物料和視頻或者用戶強相關

分發側需求：

• 平響要低，不能影響自己的核心業務。

• 穩定性要高，可用性不能低於 99.9%。

業務進行分類：

• 要求和某些視頻綁定需要穩定下發的

• 要求高優下發的

• 需要實時請求下游服務進行計算的

用戶使用特徵：

• 用戶都是就近請求服務，通常非機房級別故障，不會產生跨機房請求

• 絕大部分的內容是我們推薦給用戶，用戶對於大部分內容的一致性的要求沒有那麼高。

2. 基於以上需求特徵確定存儲方案如下

• 根據業務數據特點和分發側需求我們可以選取 key value 型存儲，變更性能好。

• 根據業務進行分類和用戶使用特徵，我們對不同地區之間的數據一致性要求不高，在不考慮降級策略以及拋卻一些需要實時請求的下游業務情況下，如果想通過平臺進行性能優化，那變動不是很頻繁的業務我們只能儘可能的讓他們把數據存到我們這裏統一管理，增加一些本地緩存作爲二級緩存來進一步提高可用性。

2.2.3 多路數據獲取，性能優先

併發多路請求下游服務，設定超時時間，將最終未超時返回的數據進行後續策略處理確定最終分發數據。由於受限與機器連接數，核心要點是要平衡好併發的數量和超時時間，二則呈負相關。

我們的目的是儘可能的請求更多的服務來獲取內容和服務以便給出用戶最佳推薦，達成這個目的依賴於我們對於服務的精細化管理。

2.3 平臺工具化保證快速業務接入

1. 設計背景：

• 條件繁雜：資源位已接入數以十計的業務且持續增加，每種業務都涉及業務數據的組裝，分發端、版本、位置的控制，各種小流量實驗的加入等需求，重複性工作較多，且質量把控成本高。

• 業務變更頻繁：日常迭代中經常收到諸如某業務跳轉地址更、物料信息、小流量實驗號、業務優先級、下發版本的變更需求，經常面臨開發五分鐘，上線幾小時。

• 業務逐漸複雜：隨着業務的大量接入，每次上線的迴歸測試將變得成本越來越高，各種業務的監控維護也越來越複雜。

• case 諮詢：pm 或者用戶諮詢不符合其預期下發的原因，研發需要查看代碼覈對邏輯復現線上，成本高昂。

2. 設計目標：

• 業務規則抽象化：業務代碼進行規則抽象，支持規則組合、插拔和熱更新。

• 業務上線配置化：老業務變更和新業務接入通過已有規則和新增規則配置化完成上線。

• 業務迴歸測試監控自動化：通過建立自動化監控及迴歸測試機制來降低業務複雜帶來的成本。

• 業務流程可見性：當業務遇到不清楚的問題時，可以非常清晰的發現是哪個環節導致。

2.3.1 資源模板化、下發規則插件化，應用規則引擎，靈活組裝上線

1. 業務方選取展現物料模板，填充物料，確定展示樣式。

2. 下圖下發規則組件化由接入業務方自由選取組合，平臺進行最終審覈上線。

規則引擎運轉步驟：

1. 創建規則引擎對象

2. 向引擎中加載規則集或更換規則集

3. 向引擎的前置過濾規則提交需要被規則集處理的數據對象獲取處理結果

4. 根據處理結果獲取需求的物料數據

5. 將物料數據提交給規則引擎的後置聚合規則

6. 輸出引擎執行結果

規則引擎核心設計：

• 規則的核心爲兩個部分：

1. 判斷資源在哪裏出與不出，業務上由於已經沉澱出絕大部分的規則，且規則變化不大，核心在於規則中的條件變更，所以基於業務和成本考量不建設複雜的規則編輯和解析能力，規則將以組件化的形式存在，可以動態維護規則得變量參數，如 app 下發規則，規則變量參數爲下發端的名稱，應用規則時變量參數爲端名稱、條件、是否下發，如新業務需要新增規則再進行組件開發，主要核心能力在於組裝管理規則組件。

2. 判斷資源出什麼，業務方選擇物料模板填充物料，如跳轉地址以及地址裏的參數和用戶、端、版本等因素都會有一定的關係，所以在輸出的時候需要進行動態的轉化，這個也需要通過規則得方式進行數據轉化。

• 規則之間的關係：

且： 規則定義爲執行的一條執行鏈路，所有的規則都命中爲下發則下發，一條命中不下發則不下發。

從屬： 規則存在從屬關係，有配套父子關係，如規則 a 下有從屬 b、c，配置 a 時可以配置從屬 b、c 規則，如版本和規則下發規則從屬與端下發規則，只有端下發規則生效從屬規則纔有意義，完整規則鏈條是：a(分發端) b (>=xx 版本) c(在端什麼頁面) 進行下發。

2.3.2 資源下發錄製回放

通過記錄並模仿用戶的行爲完成 case 的復現、業務探活、上線迴歸。

• 流量行爲錄製，通過服務標準化日誌打印輸出，統一用戶請求行爲日誌，將日誌收集至錄製平臺，對日誌進行清洗、分類、聚合，構建核心功能迴歸路徑、用戶請求路徑，完成用戶行爲和核心功能的請求錄製。

• 流量行爲回放，通過錄制的流量行爲構建對服務進行請求，拿到請求的結果與錄製時的結果對比，輸出報表，完成報告分析報告。

2.4 智能調度分發策略保證用戶體驗

通過前後端打點，獲取推薦卡片的點、展、觀看時長等數據，結合實驗進行統計分析，動態完成業務質量評估結合用戶畫像來實時調整下發策略。

2.4.1 接入業務質量評估及迭代處理

根據下發資源卡片的打點數據，定期進行業務自動化評估，根據評估數據，持續迭代淘汰質量較差的業務資源。

2.4.2 動態策略返回最優內容

根據用戶畫像及接入業務服務的性能及健康狀態，實時計算資源下發的分配份額，基於份額進行資源下發調配。

三、總結

前期重通路及可用性完成基礎能力構建，打通業務側內容、服務供給，用戶側內容消費、服務使用的閉環，通過存儲優化、性能優化保證了服務的可用性。後期重效率、質量通過平臺建設，應用插件設計、規則引擎提升業務接入效率，通過流量回放來降低事故率、業務迴歸測試成本，最終通過智能調度策略保障平臺生態質量，避免無序擴張而影響應用資源卡片的業務本身。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/rpNBlvj7u4aOR9EWtJW-ow