哔哩哔哩后端开发面试真题：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天不等。二面和三面之间等了一周，说是面试官出差，这个就看运气了。