01、西瓜視頻微服務(wù)架構(gòu)設(shè)計

西瓜視頻介紹

西瓜視頻是一個開眼界、漲知識的視頻 App (Informative Video Platform)，作為國內(nèi)領(lǐng)先的中長視頻平臺，它源源不斷地為不同人群提供優(yōu)質(zhì)內(nèi)容，讓人們看到更豐富和有深度的世界，收獲輕松的獲得感，點亮對生活的好奇心。

同時，西瓜視頻鼓勵多樣化創(chuàng)作，幫助人們輕松地向全世界分享視頻作品，創(chuàng)造更大的價值。目前平臺月活躍創(chuàng)作人超過 320 萬，月活躍用戶數(shù)超過 1.8 億，日均播放量超過 40 億，用戶平均使用時長超過 100 分鐘。

微服務(wù)架構(gòu)設(shè)計時關(guān)注哪些方面

業(yè)務(wù)域劃分

上面四張圖分別對應(yīng)我們的中視頻、電商、長視頻和作者側(cè)的業(yè)務(wù)。當然我們的業(yè)務(wù)場景遠不止這些，但是也反映出了 C 端場景多，業(yè)務(wù)域劃分較細的特點，因此我們在微服務(wù)架構(gòu)設(shè)計的時候需要著重考慮服務(wù)劃分與解耦，在設(shè)計期間我們主要遵循兩個原則：

• 單一職責(zé)原則：確保每個微服務(wù)只負責(zé)一個特定的業(yè)務(wù)功能，避免職責(zé)混亂。
• 領(lǐng)域驅(qū)動設(shè)計：使用領(lǐng)域驅(qū)動設(shè)計方法來劃分服務(wù)邊界，確保各個服務(wù)獨立、可復(fù)用。

這樣設(shè)計之后，可以保證：

• 業(yè)務(wù)模塊的獨立性：每個微服務(wù)可以獨立開發(fā)、測試、部署和擴展，提升了開發(fā)效率和系統(tǒng)的靈活性。
• 技術(shù)棧靈活性：不同的微服務(wù)可以使用最適合其業(yè)務(wù)需求的技術(shù)棧，不需要統(tǒng)一技術(shù)選型。
• 故障隔離：一個服務(wù)的故障不會影響其他服務(wù)的運行，提高了系統(tǒng)的可用性和穩(wěn)定性。
• 按需擴展：可以根據(jù)每個服務(wù)的負載情況獨立擴展，優(yōu)化資源使用和成本。

性能

架構(gòu)設(shè)計

上圖是西瓜視頻整體的微服務(wù)架構(gòu)設(shè)計。

從上到下我們分為三層，分別是接入層，業(yè)務(wù)層和基礎(chǔ)組件層。

接入層

• 不同的分端：包括西瓜 APP，西瓜 PC，TV 端鮮時光以及 M 站。
• 負載均衡及網(wǎng)關(guān)

使用公司內(nèi)部組件來提供負載均衡和通用網(wǎng)關(guān)能力。

• API 服務(wù)：使用 Hertz 框架的服務(wù)。

業(yè)務(wù)層

• 消費側(cè)業(yè)務(wù)，基礎(chǔ)業(yè)務(wù)，和其他的一些互動社區(qū)等 RPC 業(yè)務(wù)，這些服務(wù)采用的是 Kitex 框架。

消費側(cè)業(yè)務(wù)主要面向 C 端用戶的場景就是信息流和詳情頁。

信息流：主要是西瓜 APP 的全部頻道模塊,包括進入西瓜視頻后的首頁看到的推薦精選都對應(yīng)我們的信息流服務(wù)。

詳情頁：我們知道推薦頻道更多對應(yīng)的是一個沉浸式的場景，但是我們的視頻也會有其他的入口進入，比如個人主頁等場景，這個時候點擊一個視頻就會進入詳情頁，相對于沉浸式那種更專注于視頻本身播放的體驗，詳情頁會包含更多的視頻信息。

推薦系統(tǒng)：這里是一些推薦、廣告的服務(wù),主要是提供底層的數(shù)據(jù)的 id 返回，包含廣告混排，推薦排序，廣告投放等功能。

打包服務(wù)：公司的業(yè)務(wù)線會比較繁雜,所以隨著發(fā)展抽象出了打包層，各個業(yè)務(wù)會有自己數(shù)據(jù)結(jié)構(gòu)的打包服務(wù)，作為最終返回給客戶端的數(shù)據(jù)。這里就包括小視頻、中視頻、長視頻、直播等數(shù)據(jù)的打包。

• 互動模塊

在這些業(yè)務(wù)之外，我們還會有其他的一些互動和社區(qū)的功能模塊。這種都是有公司專門的關(guān)系中臺、評論中臺去維護。同時，我們的業(yè)務(wù)還會依賴業(yè)務(wù)用到的存儲，像 mysql、redis 等。

基礎(chǔ)組件

基礎(chǔ)組件，比如語言框架，像前面提到的 Hertz、Kitex 等框架，還有一些日志、監(jiān)控，配置系統(tǒng)。

02、Hertz 框架介紹

背景

字節(jié)跳動從 2014 年開始使用 Golang，2016 年基于 Gin 框架封裝了 Ginex。但 Ginex 在迭代受開源 Gin 項目限制、代碼混亂膨脹導(dǎo)致維護困難、無法滿足性能敏感和功能擴展需求等問題。2020 年部分業(yè)務(wù)線嘗試魔改其他開源框架如 Fasthttp，但帶來了分散生產(chǎn)力和巨大維護成本的問題。為解決這些痛點，字節(jié)于 2020 年初立項開發(fā)自研高性能 Go 框架 Hertz，經(jīng)過兩年多的迭代，Hertz 于 2022 年 6 月正式開源，目前已廣泛應(yīng)用于字節(jié)內(nèi)部逾 1.4 萬個服務(wù)，支撐日峰值 QPS 超 5000 萬，顯著降低資源使用和服務(wù)延時，接替大量基于 Gin 的存量服務(wù)，助力公司降本增效。

為什么選擇 Hertz

• 極致的性能

Hertz 的性能指標是作為一個核心指標開展設(shè)計和實現(xiàn)的。Hertz 默認使用自研的高性能網(wǎng)絡(luò)庫 Netpoll，在一些特殊場景相較于 go net，Hertz 在 QPS、時延上均具有一定優(yōu)勢。關(guān)于性能數(shù)據(jù)，大家可以看一下 hertz-benchmark（https://github.com/cloudwego/hertz-benchmark），可以看到 Hertz 的 QPS 和時延指標在和其他三個知名框架對比中已經(jīng)全面占優(yōu)，對比 Gin 更是遙遙領(lǐng)先。

并且，框架整體的持續(xù)優(yōu)化會貫穿框架的整個生命周期，持續(xù)不斷地進行下去。

• 易用性，開發(fā)者友好

在開發(fā)過程中，快速寫出正確的代碼往往是重要的。Hertz 在設(shè)計 API 時，考慮到用戶的使用習(xí)慣，參考業(yè)界主流框架使用 API 的方式，并加以優(yōu)化。在 Hertz 在迭代過程中，積極聽取用戶意見，持續(xù)打磨框架， 比如很多用戶希望 Client 也有 Trace 的能力，為此，Hertz Client 支持了中間件能力。Hertz 也提供了命令行工具，一鍵生成代碼，提高框架的易用性。

Hertz 提供了一個簡單易用的命令行工具 hz，用戶只需提供一個 IDL，根據(jù)定義好的接口信息，hz 便可以一鍵生成項目腳手架，開箱即用使用 Hertz；hz 也提供更新能力，用戶的 IDL 如果發(fā)生改變，hz 可以更新腳手架。目前 hz 支持了 Thrift 和 Protobuf 兩種 IDL 定義。命令行工具內(nèi)置豐富的選項，可以根據(jù)自己的需求使用。

• 豐富的文檔體系

即使是從來沒有使用過相關(guān)框架的新同學(xué)，都能夠通過相應(yīng)的文檔，快速上手 Hertz，體驗 Hertz 所帶來的極致的開發(fā)體驗。

• 穩(wěn)定性
  Hertz 對內(nèi)對外支撐了大量的業(yè)務(wù)服務(wù)，業(yè)務(wù)選擇 Hertz 的一個重要考量就是穩(wěn)定性。Hertz 也制定了各種措施來保證框架的穩(wěn)定性：
• 基于線上流量特征的隨機模擬。Hertz 會根據(jù)線上真實的流量曲線，通過模擬和重放的方式，在測試環(huán)境中復(fù)現(xiàn)各種極端的高并發(fā)場景，從而驗證系統(tǒng)的承載能力和容錯能力。
• 核心 API 全覆蓋。Hertz 所有對外提供服務(wù)的 API 接口，無一例外都要經(jīng)過完備的性能測試、壓力測試和負載測試，確保在各種極限情況下也能保持穩(wěn)定和高效。
• 適配不同的線上部署環(huán)境。針對 Hertz 服務(wù)的不同場景，會準備不同的線上環(huán)境。這些環(huán)境硬件資源配置不盡相同，通過在不同環(huán)境中反復(fù)測試和驗證，可以全面評估系統(tǒng)的穩(wěn)定性和可擴展性。
• 7*24 小時監(jiān)控大盤。全天候?qū)崟r監(jiān)控系統(tǒng)的各項核心指標，一旦發(fā)現(xiàn)異常，能夠第一時間定位并通知值班人員介入處理。
• 嚴格的發(fā)布流程。Hertz 對系統(tǒng)的每一次上線升級都有特別嚴格的流程要求，必須經(jīng)過線下測試、驗證、代碼 review 等多個環(huán)節(jié)，避免出現(xiàn)變更帶來的風(fēng)險。
• 低廉的遷移成本
• 西瓜早期的 API 服務(wù)都是基于 Ginex 框架開發(fā)的。而 Hertz 立項之初，就將針對存量 Ginex 服務(wù)的遷移作為一個高優(yōu)需要照顧的環(huán)節(jié)。在一些業(yè)務(wù)常用 API 上做了許多兼容性的設(shè)計。
• 同時，Hertz 也為存量項目提供了一鍵遷移的方案 Ginex 項目快速遷移 Hertz 1.x 指南，使用一鍵遷移工具，用戶可能無需/只需改動少量代碼即可完成
• Gin —> Hertz 項目的遷移。詳見：https://www.cloudwego.io/zh/docs/hertz/tutorials/service-migration/#gin
• 豐富的擴展能力

Hertz 采用了分層設(shè)計，提供了較多的接口以及默認的擴展實現(xiàn)，用戶也可以自行擴展。Hertz 目前支持了日志、監(jiān)控、服務(wù)注冊與發(fā)現(xiàn)、網(wǎng)絡(luò)庫和協(xié)議等擴展能力，未來有望為用戶提供更多的擴展能力。

03、Hertz 遷移過程、踩坑經(jīng)驗

遷移過程

1. 選擇要遷移的服務(wù)

遷移的第一步就是要先選擇要遷移的服務(wù)，根據(jù)帕累托原則，我們優(yōu)先找出占據(jù)最大比例的成本來源，并處理這些高成本項目，以最大化資源利用效率。根據(jù)性能分析平臺，我們選擇了目前西瓜 CPU 資源消耗最大的兩個 api 服務(wù)進行遷移，分別對應(yīng)我們的觀看歷史、點贊和彈幕的有關(guān)服務(wù)。

2. SDK 庫適配

西瓜業(yè)務(wù)線對 Ginex 做了封裝，提供一個 SDK 給其他 api 服務(wù)使用，比如在獲取觀看歷史的接口中，我們會先使用 SDK 中的 newRequestContext 方法來做一些請求上下文的初始化操作。在這個請求上下文中我們會有 ab 實驗、設(shè)備信息、地理位置信息等上下文的初始化。所以我們第一步就是針對 SDK 庫中相應(yīng)的代碼進行適配。在這個適配過程中有一些三方的 SDK 庫的依賴，可以直接升級 SDK 對應(yīng)的 Hertz 版本。

3. 執(zhí)行一鍵遷移腳本

Hertz 同學(xué)提供了一鍵遷移腳本，只需在當前服務(wù)目錄下執(zhí)行腳本即可完成大部分重復(fù)性的改造工作。

腳本通過正則匹配的方式完成大部分重復(fù)性替換工作，對于一些 gin、ginex 字樣會替換為Hertz 中的相應(yīng)的實現(xiàn)。

4. 手動修改

Hertz 中間件的設(shè)計采用了洋蔥模型，洋蔥模型是一種中間件流程控制方式，做到核心邏輯和通用邏輯分離。

中間件可以做日志記錄、性能統(tǒng)計、安全控制、事務(wù)處理、異常處理等場景。

Hertz 預(yù)置了幾款中間件：

• Recovery 中間件：負責(zé)處理鏈路上的 panic
• Metrics 中間件：負責(zé)請求相關(guān)指標上報

對于業(yè)務(wù)自己實現(xiàn)的特殊中間件需要進行遷移，關(guān)于如何實現(xiàn)一個中間件 Hertz 也給出了實例。

以西瓜業(yè)務(wù)自己的特殊中間件 default_stable 為例，我們會在 header 中將 stable 設(shè)置為 1，用于做 SLO 數(shù)據(jù)統(tǒng)計。這種中間件我們就需要做一些適配工作，這里的話就會面臨接口不匹配的問題，可以參考 Gin —> Hertz API 對照表（https://github.com/hertz-contrib/migrate/blob/main/gin_to_hertz.md）進行修改。

踩坑經(jīng)驗

1. Query tag 缺失導(dǎo)致請求參數(shù)解析失敗

• 表現(xiàn)

Query 請求參數(shù)在服務(wù)端沒有解析成功，調(diào)用 RequestContext 進行參數(shù)綁定的時候報錯。

• 原因
• 參考 Hertz 支持的參數(shù)綁定與校驗相關(guān)功能及用法，不通過 IDL 生成代碼時若字段不添加任何 tag 則會遍歷所有 tag 并按照優(yōu)先級綁定參數(shù)，添加 tag 則會根據(jù)對應(yīng)的 tag 按照優(yōu)先級去綁定參數(shù)。
  Hertz 支持的參數(shù)綁定與校驗相關(guān)功能及用法：
  https://www.cloudwego.io/zh/docs/hertz/tutorials/basic-feature/binding-and-validate/
• 請求參數(shù)有關(guān)的結(jié)構(gòu)體未設(shè)置 query tag，導(dǎo)致 query 請求參數(shù)在服務(wù)端沒有解析成功。
  
• 解決方式
• 結(jié)構(gòu)體添加 query tag
• 通過單元測試提前規(guī)避

2. 未配置 looseZero 模式導(dǎo)致綁定數(shù)值類型報錯

• 表現(xiàn)

在一些場景下，前端有時候傳來的信息只有 key 沒有 value，這會導(dǎo)致綁定數(shù)值類型的時候報錯。

• 原因
• 未配置 looseZero 模式
• 解決方式

04、落地 Hertz 后的收益

上線前后對比發(fā)現(xiàn) CPU 使用率下降約 10%，優(yōu)化效果明顯，詳細的性能收益如下：

• 平均 CPU 核數(shù)從 2730 降為 2443
• 單核 QPS 處理能力提升：10.7%
• 內(nèi)存占用率變化—優(yōu)化前：31.1% ，優(yōu)化后：29.3%
• 核心接口 LatencyPct99 下降：10.15%

項目地址

GitHub：https://github.com/cloudwego

官網(wǎng)：www.cloudwego.io