嗶哩嗶哩後端開發面試真題：Go+微服務架構深度考察

背景介紹

先說下我的情況，3年Go後端開發經驗，之前在一家中型視頻公司做後端，主要負責視頻轉碼和分發相關的服務。說實話在那邊待了3年，業務比較穩定，技術棧也比較固定，感覺成長空間有限。今年4月份看到嗶哩嗶哩在招Go後端開發，崗位是視頻基礎設施方向，跟我之前做的內容高度相關，就在官網投了簡歷。

投完第二天就收到了HR的郵件，約了筆試+一面。整個流程一共4輪：一面技術基礎、二面架構能力、三面系統設計+算法、HR面。從投遞到拿到offer大概3週，中間二面和三面之間等了一週，說是面試官出差了。

一面：Go基礎+gRPC+Protobuf

Go並發編程

一面面試官是視頻基礎架構組的一個技術骨幹，上來先聊了下我的項目經歷，然後直接進入技術問題。Go相關的問得比較深，不是那種背八股文的水平，而是要你能講清楚底層原理和使用場景。

goroutine池：面試官問「為什麼需要goroutine池？直接go func不行嗎？」我說在低並發場景下go func沒問題，但在高並發場景下如果不控制goroutine數量，會導致內存暴漲和調度壓力。然後講了下我之前實現的goroutine池：用buffered channel做任務隊列，固定數量的worker goroutine消費任務，支持動態調整池大小。面試官追問了「如果任務量突然飆升，你的池子怎麼處理？」我說會設置一個最大容量上限，超過上限的任務要麼排隊等待要麼丟棄（取決於業務場景），同時配合限流策略從源頭控制。

sync包：面試官問了sync.Mutex和sync.RWMutex的區別，以及sync.Map的適用場景。Mutex和RWMutex比較基礎，我說RWMutex適合讀多寫少的場景，多個讀操作可以並發執行。sync.Map我說它適合讀多寫少且key相對穩定的場景，內部用了讀寫分離和原子操作來優化讀性能，但在寫多或者key頻繁變化的場景下性能不如map+Mutex。面試官又問了一個比較細的點：「sync.Once的實現原理？」我說它內部用了Mutex和原子操作，保證函數只執行一次，核心是fast path用原子操作檢查，slow path加鎖執行。

Go泛型：面試官問了我對Go 1.18+泛型的理解，以及在項目中有沒有用到。我說我在項目中用泛型寫了一些通用工具函數，比如泛型的Slice過濾、映射函數，以及泛型的緩存接口。面試官問「泛型有什麼限制？」我說目前Go泛型不支持特化、不支持方法上的類型參數，而且編譯速度會有一定影響。

gRPC原理

面試官問「為什麼選擇gRPC而不是HTTP REST？」我從三個方面回答：性能（基於HTTP/2和Protobuf，序列化更快、連接複用）、代碼生成（自動生成客戶端和服務端代碼）、流式通信（支持雙向流）。面試官追問了「gRPC的流式通信在你們項目中怎麼用的？」我說我們視頻轉碼服務用了服務端流，客戶端發起轉碼請求後，服務端透過流推送轉碼進度和狀態。

然後面試官問了gRPC的負載均衡怎麼做。我說gRPC基於HTTP/2的長連接特性，傳統的客戶端負載均衡（如Round Robin）可能會因為連接不均衡導致負載不均。我們用的是服務端負載均衡+代理模式，透過Nginx或者專門的gRPC代理來做負載均衡。面試官還問了gRPC的攔截器（Interceptor）怎麼用，我說我們用攔截器做了統一的鑑權、日誌和鏈路追蹤。

Protobuf

面試官問「Protobuf和JSON的區別？為什麼Protobuf更快？」我說Protobuf是二進制格式，序列化和反序列化速度比JSON快很多，而且體積更小。核心原因是Protobuf用字段編號而不是字段名，並且預定義了schema，不需要運行時解析字段類型。面試官追問了「Protobuf的向後兼容性怎麼保證？」我說新增字段用新的編號，老版本不認識的字段會跳過；刪除字段要用reserved保留編號，避免複用導致數據錯亂。

二面：微服務架構+Kubernetes

微服務架構

二面面試官是架構組的一個大佬，問的問題更偏架構層面，不再是具體語法，而是怎麼設計、怎麼做技術選型。

服務網格：面試官問「你們用服務網格了嗎？Istio還是Linkerd？」我說我們用的是Istio，主要用了流量管理（VirtualService和DestinationRule）和可觀測性（Kiali和Jaeger集成）。面試官問「Istio的Sidecar模式有什麼性能開銷？」我說Sidecar會引入額外的延遲（大概1-3ms），以及內存和CPU開銷。我們在生產環境做過壓測，整體性能影響在可接受範圍內，但在超高頻調用的場景下需要考慮優化。

分佈式追蹤：面試官問「分佈式追蹤的原理是什麼？你們怎麼做的？」我說我們用的是OpenTelemetry+Jaeger，核心原理是在請求入口生成TraceID，每個服務調用時透過Context傳遞TraceID和SpanID，最終在Jaeger上可以看到完整的調用鏈。面試官追問了「跨服務的TraceID怎麼傳遞？」我說透過gRPC的metadata傳遞，我們在攔截器裡統一處理了。

熔斷降級：面試官問「熔斷和降級有什麼區別？你們怎麼做的？」我說熔斷是當某個服務故障率超過閾值時，自動切斷對該服務的調用，避免故障擴散；降級是在系統壓力過大時，主動關閉一些非核心功能，保證核心功能的可用性。我們用的是Hystrix-Go的思路，自己實現了一個熔斷器，支持三種狀態：關閉（正常調用）、打開（直接拒絕）、半開（試探性放行少量請求）。

Kubernetes

Pod生命週期：面試官問「Pod的完整生命週期是怎樣的？」我說從Pending→Running→Succeeded/Failed，中間還有Container的Creating和Terminating階段。面試官追問了「Pod的優雅退出怎麼做？」我說設置terminationGracePeriodSeconds，在PreStop鉤子裡做清理工作，Kubernetes會先發送SIGTERM，等寬限期過後再發送SIGKILL。

調度策略：面試官問「Kubernetes的調度策略有哪些？」我說主要有nodeSelector（簡單標籤匹配）、nodeAffinity（更靈活的親和性規則）、podAffinity/podAntiAffinity（Pod之間的親和/反親和）、taints和tolerations（污點和容忍）。面試官追問了「如果某個節點資源不足，Pod會被調度到那裡嗎？」我說不會，Kubernetes調度器會先做預選（Filter）排除不滿足條件的節點，再做優選（Score）選擇最優節點。

三面：系統設計+項目深挖+算法

系統設計：設計B站彈幕系統

三面的系統設計題是「設計一個B站彈幕系統」，這個題很有B站特色。我的設計思路如下：

需求分析：彈幕系統的核心需求是實時性（彈幕要低延遲展示）、高並發（熱門視頻可能有幾萬人同時發彈幕）、可擴展（支持歷史彈幕和實時彈幕）、以及彈幕防刷。

架構設計：我畫了一個大致的架構圖——客戶端透過WebSocket連接到彈幕網關服務，網關服務負責維護長連接和消息分發。彈幕消息先寫入消息隊列（Kafka），然後由彈幕分發服務消費並推送到對應視頻的所有在線客戶端。歷史彈幕存儲在Redis（熱點視頻）+ MySQL（全量存儲）。

關鍵設計：彈幕合併（同一時間段的彈幕合併推送，減少客戶端渲染壓力）、彈幕防刷（限流+內容審核）、彈幕分區（按視頻ID分片，不同視頻的彈幕互不影響）、降級策略（高峰期只推送VIP彈幕或限制彈幕密度）。

面試官追問了「如果某個熱門視頻有100萬在線觀眾，你怎麼保證彈幕的實時性？」我說網關服務做水平擴展，每個網關實例負責一部分連接；彈幕消息透過Kafka分區，每個分區對應一個視頻；推送時用批量推送而不是逐條推送，減少網絡開銷。

項目深挖

面試官讓我詳細講了之前做的視頻轉碼服務。我講了整體架構：上傳服務→轉碼調度服務→轉碼Worker集群→分發服務。面試官問了幾個關鍵問題：轉碼任務怎麼調度（優先級隊列+資源感知調度）、轉碼失敗怎麼處理（重試+死信隊列+告警）、視頻分發怎麼做（CDN+多級緩存）。整體聊了大概20分鐘，面試官對我的項目理解比較認可。

算法題

算法題是兩道：LRU緩存實現和跳表。

LRU緩存：經典題，用HashMap+雙向鏈表實現，get和put都是O(1)。我寫得比較快，面試官追問了「如果要支持過期時間呢？」我說可以在節點上加一個過期時間戳，get的時候檢查是否過期，另外起一個後台goroutine定期清理過期節點。

跳表：面試官讓我實現跳表的插入和查找。跳表我之前研究過，但手寫還是第一次，寫得有點慢。核心思路是多層索引+隨機層數，查找從最高層開始逐層下降。面試官說思路沒問題，代碼有些小bug但不影響理解。

HR面：動機+加班+薪資

HR面問了為什麼來B站，我說B站是國內最好的視頻社區，技術挑戰大，而且彈幕、直播這些業務場景對後端的要求很高，能學到很多東西。加班的問題，HR說B站確實有些組會比較忙，但視頻基礎架構組相對還好，基本能保證雙休。薪資方面，HR說B站的薪資在業內中等偏上，具體要看定級結果。

面試真題彙總

Go基礎

1. goroutine池的設計和使用場景

2. sync.Mutex、sync.RWMutex、sync.Map的區別和適用場景

3. sync.Once的實現原理

4. Go泛型的使用和限制

gRPC與Protobuf

5. gRPC vs HTTP REST的優劣

6. gRPC流式通信的使用場景

7. gRPC負載均衡方案

8. gRPC攔截器的使用

9. Protobuf vs JSON的區別

10. Protobuf的向後兼容性

微服務架構

11. Istio服務網格的使用和性能開銷

12. 分佈式追蹤的原理和實現

13. 熔斷降級的區別和實現方案

Kubernetes

14. Pod的完整生命週期

15. Kubernetes調度策略

16. Pod優雅退出

系統設計

17. 設計B站彈幕系統

算法

18. LRU緩存實現（支持過期時間）

19. 跳表的插入和查找

心得體會與建議

1. Go基礎要扎實，但不是背八股。B站的面試不是考你能不能背出標準答案，而是看你能不能講清楚原理和使用場景。比如goroutine池，不是簡單說「用channel實現」就完了，要能講清楚為什麼需要、怎麼設計、邊界情況怎麼處理。

2. 系統設計要有方法論。建議按照「需求分析→架構設計→關鍵組件→擴展性→降級方案」的框架來回答，不要一上來就畫架構圖。面試官更看重你的思考過程，而不是最終答案。

3. 項目經歷要能深挖。面試官一定會追問項目細節，所以簡歷上寫的項目你自己要非常熟悉。建議提前梳理每個項目的架構圖、關鍵決策、踩過的坑。

4. 算法不能丟。雖然B站不是算法公司，但三面還是會考算法。LRU緩存是高頻題，一定要能手寫。跳表相對少見，但如果你了解Redis的底層實現，應該不會太陌生。

5. 了解B站的技術博客。B站技術團隊有公開的技術博客，建議面試前讀幾篇，了解他們的技術棧和架構思路，面試時能自然地引用會加分。

常見問題FAQ

Q1：B站Go後端面試重點是什麼？

重點在Go並發編程、微服務架構和系統設計。Go基礎要扎實，微服務要能講清楚服務治理的各個方面，系統設計要體現架構思維。

Q2：沒有視頻行業經驗可以面B站嗎？

可以，但有相關經驗會加分。如果沒有視頻行業經驗，建議重點準備系統設計和Go基礎，面試官更看重技術能力而不是行業經驗。

Q3：算法難度怎麼樣？

中等難度，不是LeetCode Hard那種。LRU緩存、跳表這種偏工程實踐的算法題比較多，建議重點練習數據結構相關的題目。

Q4：B站後端的薪資水平怎麼樣？

在互聯網公司中中等偏上，具體要看定級。3年經驗大概在P6級別，薪資範圍可以參考offershow上的數據。

Q5：面試流程大概多久？

我這次從投遞到offer大概3週，每輪面試間隔2-7天不等。二面和三面之間等了一週，說是面試官出差，這個就看運氣了。