从PC到移动端的关键三年，B站完成了技术架构的重大升级
2015年到2017年是B站发展史上的关键转折期。这三年间，中国移动互联网用户数从5.57亿增长到7.53亿，移动端成为互联网的主战场。B站敏锐地捕捉到这一趋势，全面启动移动化转型，不仅重构了客户端技术栈，还上线了直播业务，同时开始探索微服务架构。用户数从2015年的5000万增长到2017年底的7000万+，技术团队也从50人扩张到300人+。
2015年初，B站面临一个关键抉择。数据显示，虽然PC端仍占据70%的流量，但移动端增长速度是PC端的5倍。陈睿在内部会议上明确提出：”移动端不是补充，而是未来的主战场。”这一决策直接推动了B站历史上最大规模的技术投入。
市场环境分析：
内部数据洞察（2015.01）： | 维度 | PC端 | 移动端 | 洞察 | |——|——|——–|——| | 用户占比 | 70% | 30% | 移动端增速快 | | 使用时长 | 45分钟 | 25分钟 | 移动端有提升空间 | | 活跃度 | 3天/周 | 5天/周 | 移动端粘性更高 | | 年龄分布 | 平均22岁 | 平均19岁 | 移动端更年轻 | | 功能使用 | 全功能 | 仅观看 | 移动端功能缺失 |
战略决策过程：
2015年1月董事会
├── 徐逸提案：保守发展，PC为主
├── 陈睿提案：激进转型，All in Mobile
├── 投资方建议：参考YouTube移动化经验
└── 最终决议：3年内移动端成为主战场
├── 2015年：移动端流量占比达到40%
├── 2016年：移动端流量占比达到60%
└── 2017年：移动端流量占比达到80%
战略布局要点：
资源投入计划： | 项目 | 2014年 | 2015年计划 | 实际投入 | |——|——–|————|———-| | 人力 | 10人 | 60人 | 75人 | | 预算 | ¥200万 | ¥2000万 | ¥2500万 | | 服务器 | 50台 | 500台 | 600台 | | 带宽 | 1Gbps | 10Gbps | 15Gbps |
组织架构调整：
技术部门重组（2015.02）
├── 移动端团队（新建，张峰负责）
│ ├── iOS组（15人，李明负责）
│ │ ├── 框架小组（5人）
│ │ ├── 业务小组（7人）
│ │ └── 性能小组（3人）
│ ├── Android组（18人，王强负责）
│ │ ├── 架构小组（6人）
│ │ ├── 功能小组（8人）
│ │ └── 优化小组（4人）
│ └── 移动架构组（8人，赵云负责）
│ ├── 跨端框架（3人）
│ ├── 组件库（3人）
│ └── 工具链（2人）
├── 后端服务团队
│ └── 移动API组（新建，12人）
│ ├── 接口设计（4人）
│ ├── 性能优化（4人）
│ └── 网关建设（4人）
└── 基础设施团队
└── 移动专项组（新建，6人）
├── CDN优化（2人）
├── 推送系统（2人）
└── 埋点分析（2人）
KPI设定与考核：
第一代（2012-2014）：初创期的简单实现
早期iOS客户端由徐逸的朋友业余开发，代码质量参差不齐，主要满足基本的视频播放需求。
// 早期代码示例（2013年版本）
@interface BiliVideoViewController : UIViewController
{
MPMoviePlayerController *_player;
NSMutableArray *_danmakuArray;
NSTimer *_danmakuTimer;
}
@end
// 问题：
// 1. 使用系统播放器，无法自定义
// 2. 弹幕用Timer驱动，性能差
// 3. 内存管理混乱，经常崩溃
技术栈：
问题暴露： | 问题 | 具体表现 | 用户投诉率 | |——|———-|————| | 崩溃频繁 | 日崩溃率3% | 40% | | 弹幕卡顿 | 超过50条就卡 | 35% | | 内存泄漏 | 使用10分钟占用200MB | 15% | | 功能缺失 | 无离线下载、投币等 | 10% |
第二代（2015.03发布）：专业团队重构
2015年初，B站组建了15人的iOS团队，由前网易云音乐iOS负责人李明带队，进行彻底重构。
架构升级：
核心模块设计：
iOS App架构（2015版）
┌─────────────────────────────────────────┐
│ Presentation Layer │
│ ├── ViewControllers (MVVM) │
│ ├── Views & Cells │
│ └── ViewModels (RAC绑定) │
├─────────────────────────────────────────┤
│ Business Layer │
│ ├── Services (业务逻辑) │
│ ├── Managers (单例管理) │
│ └── Models (数据模型) │
├─────────────────────────────────────────┤
│ Core Components │
│ ├── BiliPlayer (播放器核心) │
│ ├── DanmakuEngine (弹幕引擎) │
│ ├── NetworkEngine (网络层) │
│ ├── CacheManager (缓存管理) │
│ └── SecurityModule (加密模块) │
├─────────────────────────────────────────┤
│ Foundation Layer │
│ ├── Categories (分类扩展) │
│ ├── Utilities (工具类) │
│ └── Constants (常量定义) │
└─────────────────────────────────────────┘
播放器架构革新：
// BiliPlayer核心接口设计
@protocol BiliPlayerProtocol <NSObject>
@required
- (void)playWithURL:(NSURL *)url;
- (void)pause;
- (void)resume;
- (void)seek:(NSTimeInterval)time;
@optional
- (void)setDanmakuVisible:(BOOL)visible;
- (void)setPlaybackRate:(CGFloat)rate;
- (void)switchQuality:(BiliVideoQuality)quality;
@end
// 实现细节
// 1. 基于AVPlayer二次开发
// 2. 支持HLS/MP4/FLV格式
// 3. 实现边下边播
// 4. 自适应码率切换
iOS技术栈（2015-2017）
┌─────────────────────────────────┐
│ 业务层（Swift混编） │
├─────────────────────────────────┤
│ 组件层（Objective-C） │
│ ├── 播放器组件 │
│ ├── 弹幕引擎 │
│ ├── 网络层 │
│ └── 数据持久化 │
├─────────────────────────────────┤
│ 基础层（C/C++） │
│ ├── 视频解码（FFmpeg） │
│ ├── 弹幕渲染（OpenGL） │
│ └── 图片处理（GPUImage） │
└─────────────────────────────────┘
关键技术突破：
Android客户端在2015年经历了一次彻底重构，从Eclipse迁移到Android Studio，全面拥抱Material Design。这次重构由前腾讯视频Android架构师王强主导，团队18人历时3个月完成。
重构背景与动机：
重构前后对比： | 维度 | 重构前（2014） | 重构后（2015） | 改进 | |——|—————|—————|——| | 开发工具 | Eclipse | Android Studio 1.5 | 编译速度提升300% | | 最低版本 | Android 2.3 | Android 4.0 | 覆盖95%用户 | | 架构模式 | MVC混乱 | MVP清晰分层 | 可维护性提升 | | UI框架 | 原生View | Material Design | 用户满意度+40% | | 包大小 | 45MB | 28MB | 减少38% |
技术架构：
Android架构分层（2015-2017）
┌────────────────────────────────┐
│ UI层（Activity/Fragment） │
├────────────────────────────────┤
│ 业务逻辑层（MVP模式） │
├────────────────────────────────┤
│ 中间件层 │
│ ├── RxJava（响应式编程） │
│ ├── Retrofit（网络请求） │
│ ├── OkHttp（HTTP客户端） │
│ └── Glide（图片加载） │
├────────────────────────────────┤
│ 核心组件层 │
│ ├── IJKPlayer（视频播放） │
│ ├── DanmakuFlameMaster（弹幕） │
│ └── GreenDAO（数据库） │
└────────────────────────────────┘
重要技术选型：
性能优化成果： | 指标 | 优化前 | 优化后 | 优化手段 | |——|——–|——–|———-| | 启动时间 | 4.2s | 1.1s | 懒加载、异步初始化 | | 内存占用 | 150MB | 80MB | 图片压缩、内存复用 | | 包体积 | 45MB | 28MB | 资源压缩、代码混淆 | | 崩溃率 | 0.5% | 0.08% | Bugly监控、异常捕获 |
2016年开始，B站尝试跨端技术方案，目标是提高开发效率，保证双端体验一致性。
探索历程：
跨端架构设计：
跨端页面架构
┌──────────────────────────────┐
│ 业务代码（JS/CSS） │
├──────────────────────────────┤
│ Elec Framework │
│ ├── JS Bridge │
│ ├── 插件系统 │
│ └── 性能监控 │
├──────────────────────────────┤
│ Native Container │
│ ├── iOS (WKWebView) │
│ └── Android (X5内核) │
└──────────────────────────────┘
网络优化：
播放器优化：
播放器优化策略
┌─────────────────────────────────┐
│ 预加载策略 │
│ • 智能预测下一个视频 │
│ • 缓存前10秒内容 │
│ • 后台静默下载 │
├─────────────────────────────────┤
│ 码率自适应 │
│ • 根据网速自动切换 │
│ • 支持无缝切换 │
│ • 优先保证流畅度 │
├─────────────────────────────────┤
│ 缓存策略 │
│ • LRU缓存算法 │
│ • 最大缓存500MB │
│ • 智能清理机制 │
└─────────────────────────────────┘
电量优化：
流量优化：
2015年是中国直播元年，斗鱼、虎牙等平台快速崛起。B站管理层意识到，直播不仅是新的变现方式，更是连接UP主与粉丝的重要纽带。2015年12月，B站直播项目正式立项，代号”Link”。
市场背景分析：
2015年中国直播市场格局
┌────────────────────────────────────────┐
│ 游戏直播：斗鱼（￥10亿估值） │
│ 虎牙（￥7亿估值） │
│ 龙珠（￥5亿估值） │
├────────────────────────────────────────┤
│ 秀场直播：YY（￥50亿市值） │
│ 9158（￥30亿估值） │
│ 六间房（￥20亿估值） │
├────────────────────────────────────────┤
│ 移动直播：映客（刚起步） │
│ 花椒（种子轮） │
└────────────────────────────────────────┘
B站机会：二次元垂直领域空白
内部讨论记录（2015.11董事会）：
业务目标：
竞争优势分析： | 优势 | 具体体现 | 预期效果 | |——|———-|———-| | 用户基础 | 5000万二次元用户 | 转化率10% | | UP主资源 | 10万活跃UP主 | 1000人开播 | | 社区氛围 | 弹幕文化浓厚 | 互动率高 | | 内容特色 | 唱见、绘画、宅舞 | 差异化明显 |
技术挑战：
项目组织：
直播项目组（2015.12成立）
├── 项目负责人：张磊（前YY直播技术总监）
├── 技术团队（25人）
│ ├── 后端开发（10人）
│ ├── 前端开发（5人）
│ ├── 移动端（6人）
│ └── 运维（4人）
├── 产品团队（5人）
└── 运营团队（8人）
├── 主播运营（4人）
├── 内容审核（3人）
└── 数据分析（1人）
B站直播架构经历了三个版本的迭代：
V1.0 MVP版本（2016.01上线）：
简单直播架构 V1.0
┌────────────────────────────────┐
│ 主播端（OBS/手机） │
└────────────┬───────────────────┘
│ RTMP推流
┌────────────┴───────────────────┐
│ Nginx-RTMP-Module │
│ (单点接入) │
└────────────┬───────────────────┘
│
┌────────────┴───────────────────┐
│ CDN分发 │
│ (使用第三方CDN服务) │
└────────────┬───────────────────┘
│ HLS/HTTP-FLV
┌────────────┴───────────────────┐
│ 观众端 │
└────────────────────────────────┘
V2.0 自建核心系统（2016.09）：
生产级直播架构 V2.0
┌─────────────────────────────────────┐
│ 推流端 │
│ (OBS/移动SDK/Web推流) │
└──────────┬──────────────────────────┘
│ RTMP/SRT
┌──────────┴──────────────────────────┐
│ 接入层集群 │
│ ├── LB (负载均衡) │
│ ├── Auth (鉴权) │
│ └── QoS (质量控制) │
└──────────┬──────────────────────────┘
│
┌──────────┴──────────────────────────┐
│ 源站集群 │
│ ├── 转码服务 │
│ │ ├── 1080p │
│ │ ├── 720p │
│ │ └── 480p │
│ ├── 录制服务 │
│ └── 截图服务 │
└──────────┬──────────────────────────┘
│
┌──────────┴──────────────────────────┐
│ CDN分发网络 │
│ ├── 自建节点 (20个) │
│ └── 第三方CDN (备份) │
└──────────┬──────────────────────────┘
│ HLS/FLV/DASH
┌──────────┴──────────────────────────┐
│ 播放端 │
└─────────────────────────────────────┘
V3.0 低延迟优化版（2017.06）：
编码优化：
视频编码参数优化
┌──────────────────────────────────┐
│ 编码参数配置 │
├──────────────────────────────────┤
│ 游戏直播： │
│ • 编码器：x264 │
│ • 预设：veryfast │
│ • 码率：3000-6000kbps │
│ • 关键帧间隔：2秒 │
├──────────────────────────────────┤
│ 唱歌直播： │
│ • 音频编码：AAC-LC │
│ • 采样率：48kHz │
│ • 码率：128-192kbps │
│ • 降噪：开启 │
├──────────────────────────────────┤
│ 手机直播： │
│ • 硬编码：优先 │
│ • 自适应码率：开启 │
│ • 弱网降级策略 │
└──────────────────────────────────┘
延迟优化技术栈： | 技术方案 | 延迟 | 适用场景 | 实现难度 | |———|——|———-|———-| | HLS | 10-30s | 普通观看 | 简单 | | HTTP-FLV | 3-5s | 标准直播 | 中等 | | RTMP | 2-3s | 互动直播 | 中等 | | 私有协议 | 1-2s | 游戏直播 | 困难 | | WebRTC | <1s | 连麦互动 | 困难 |
音视频同步：
B站在2016-2017年投入¥2亿建设直播CDN网络：
节点部署：
CDN节点分布（2017年底）
┌────────────────────────────────────┐
│ 中心节点（2个） │
│ 北京BGP机房 + 上海BGP机房 │
└─────────────┬──────────────────────┘
│
┌─────────┼─────────┬──────────┐
│ │ │ │
┌───┴──┐ ┌──┴───┐ ┌──┴───┐ ┌───┴──┐
│华北 │ │华东 │ │华南 │ │西部 │
│5节点 │ │8节点 │ │4节点 │ │3节点 │
└──────┘ └──────┘ └──────┘ └──────┘
总带宽：50Gbps
覆盖率：95%+ 一二线城市
智能调度系统：
成本优化策略：
弹幕系统改造：
直播弹幕架构
┌──────────────────────────┐
│ 弹幕发送端 │
└────────┬─────────────────┘
│ WebSocket
┌────────┴─────────────────┐
│ 弹幕网关集群 │
│ (Golang, 100万并发) │
└────────┬─────────────────┘
│
┌────────┴─────────────────┐
│ 消息队列 │
│ (Kafka集群) │
└────────┬─────────────────┘
│
┌────────┴─────────────────┐
│ 弹幕推送服务 │
│ (长连接管理) │
└────────┬─────────────────┘
│ WebSocket
┌────────┴─────────────────┐
│ 接收端 │
└──────────────────────────┘
礼物系统：
连麦技术：
数据统计： | 指标 | 2016.01 | 2017.12 | 增长 | |——|———|———|——| | 注册主播 | 1000 | 10万+ | 100x | | 日均开播 | 50 | 5000+ | 100x | | 峰值在线 | 1万 | 100万+ | 100x | | 月流水 | ¥10万 | ¥5000万 | 500x |
2015-2017年，B站经历了移动互联网红利期的爆发式增长，这种增长速度远超技术团队的预期，带来了前所未有的挑战。
增长数据详析：
用户增长趋势图（百万）
80 ┤ ╱
70 ┤ ╱╱
60 ┤ ╱╱╱
50 ┤ ╱╱╱╱
40 ┤ ╱╱╱╱
30 ┤ ╱╱╱╱
20 ┤ ╱╱╱╱
10 ┤ ╱╱╱╱╱
0 └────────────────────────────────────
2015Q1 2015Q3 2016Q1 2016Q3 2017Q1 2017Q3
关键增长节点：
• 2015.Q2: 鬼畜区爆火，月增300万用户
• 2016.Q1: 拜年祭带动，春节7天增500万
• 2016.Q4: FGO联动，二次元用户涌入
• 2017.Q2: 移动端超PC，DAU破2000万
爆发式增长的驱动因素：
流量特征分析： | 时段 | 流量特点 | 技术挑战 | 应对策略 | |——|———-|———-|———-| | 工作日白天 | 平稳，基础负载30% | 常规运维 | 例行检查 | | 晚高峰(19-23点) | 日常峰值的3倍 | 自动扩容 | 提前预热缓存 | | 周末 | 全天高位运行 | 预扩容 | 周五下午扩容 | | 热点事件 | 瞬时10倍增长 | 限流降级 | 启动应急预案 | | 春节/拜年祭 | 持续高峰7天 | 全面备战 | 全员值守 |
典型流量洪峰事件：
案例1：2016春节拜年祭
流量增长时间线（2016.02.07 除夕）
18:00 ────┐ 基准流量：100万QPS
19:00 ├─── 200万QPS（预热阶段）
20:00 ├───── 500万QPS（晚会开始）
20:30 ├───────── 800万QPS（高潮）
21:00 ├─────────────── 1200万QPS（峰值）
22:00 ├──────── 600万QPS（回落）
23:00 ────┴─── 300万QPS（正常）
技术应对：
1. 提前2周进行压测
2. 临时采购云服务器500台
3. CDN带宽扩容至30Gbps
4. 核心接口全部降级为静态缓存
案例2：FGO联动活动（2016.10）
面对指数级增长，B站制定了三级扩容策略：
物理扩容路线图：
服务器规模演进
├─ 2015.01: 500台物理机
│ └─ 单机房部署
├─ 2015.12: 2000台
│ └─ 双机房主备
├─ 2016.12: 5000台
│ └─ 三地五中心
└─ 2017.12: 10000+台
└─ 混合云架构
弹性伸缩架构：
自动扩容决策系统
┌────────────────────────────────┐
│ 监控数据收集 │
│ (CPU/内存/QPS/响应时间) │
└──────────┬─────────────────────┘
│
┌──────────┴─────────────────────┐
│ 扩容决策引擎 │
│ • 规则：CPU>70% 持续5分钟 │
│ • 预测：基于历史数据 │
│ • 限制：单次最多扩容20% │
└──────────┬─────────────────────┘
│
┌──────────┴─────────────────────┐
│ 执行层 │
│ • 云主机：秒级创建 │
│ • 容器：Docker Swarm │
│ • 配置：自动注册发现 │
└────────────────────────────────┘
成本优化措施：
问题诊断：
解决方案演进：
Phase 1: 垂直拆分（2015.Q3）
数据库垂直拆分
┌─────────────┐ ┌─────────────┐
│ 单库模式 │ => │ 垂直拆分 │
│ │ ├─────────────┤
│ - 用户表 │ │ 用户库 │
│ - 视频表 │ ├─────────────┤
│ - 弹幕表 │ │ 视频库 │
│ - 评论表 │ ├─────────────┤
│ │ │ 社交库 │
└─────────────┘ └─────────────┘
Phase 2: 水平分库分表（2016.Q1）
分库分表策略
用户库 => 32个分库 × 32个分表 = 1024个表
└─ 分片键：uid % 1024
视频库 => 16个分库 × 64个分表 = 1024个表
└─ 分片键：aid % 1024
弹幕库 => 64个分库 × 16个分表 = 1024个表
└─ 分片键：cid % 1024
Phase 3: 引入中间件（2016.Q4）
Phase 4: NewSQL探索（2017.Q3）
多级缓存体系：
四级缓存架构
┌─────────────────────────────┐
│ CDN缓存 (L1) │
│ 命中率: 60% │
│ 更新策略: TTL 5分钟 │
└──────────┬──────────────────┘
│ miss
┌──────────┴──────────────────┐
│ Nginx缓存 (L2) │
│ 命中率: 20% │
│ 容量: 100GB/节点 │
└──────────┬──────────────────┘
│ miss
┌──────────┴──────────────────┐
│ Redis集群 (L3) │
│ 命中率: 15% │
│ 容量: 10TB │
│ 集群: 100个节点 │
└──────────┬──────────────────┘
│ miss
┌──────────┴──────────────────┐
│ 本地缓存 (L4) │
│ 命中率: 4% │
│ 实现: Guava Cache │
└──────────┬──────────────────┘
│ miss
┌──────────┴──────────────────┐
│ 数据库 │
│ 最终命中: 1% │
└─────────────────────────────┘
Redis集群演进： | 时期 | 方案 | 规模 | 问题 | |——|——|——|——| | 2015 | 主从模式 | 5个实例 | 单点故障 | | 2016.Q1 | Sentinel | 20个实例 | 扩容困难 | | 2016.Q3 | Codis | 50个实例 | 运维复杂 | | 2017.Q2 | Redis Cluster | 100个节点 | 稳定运行 |
缓存优化技巧：
四维监控体系：
监控体系架构
┌────────────────────────────────────┐
│ 应用层监控 │
│ • APM (Pinpoint) │
│ • 日志 (ELK Stack) │
│ • 业务指标 (自研) │
├────────────────────────────────────┤
│ 系统层监控 │
│ • 服务器 (Zabbix) │
│ • 网络 (Cacti) │
│ • 容器 (Prometheus) │
├────────────────────────────────────┤
│ 数据层监控 │
│ • 数据库 (PMM) │
│ • 缓存 (Redis Sentinel) │
│ • 消息队列 (Kafka Manager) │
├────────────────────────────────────┤
│ 用户层监控 │
│ • 前端 (Sentry) │
│ • 移动端 (Bugly) │
│ • 用户行为 (自研埋点) │
└────────────────────────────────────┘
关键指标监控： | 指标类型 | 监控项 | 阈值 | 告警级别 | |———|——–|——|———-| | 可用性 | 服务可用率 | <99.9% | P1 | | 性能 | API响应时间 | >1秒 | P2 | | 容量 | CPU使用率 | >80% | P2 | | 错误 | 错误率 | >0.1% | P3 | | 流量 | QPS | >预期150% | P3 |
故障处理流程：
到2016年初，B站的单体应用已经膨胀到难以维护的程度，技术债务累积到了必须偿还的临界点。
代码规模失控：
单体应用代码统计（2016.05）
├── Java代码：150万行
├── 类文件数：8000+
├── Maven模块：200+
├── 开发人员：80+
├── 日均提交：100+
├── 代码冲突：日均15次
├── 编译时间：15分钟
└── 部署时间：30分钟（滚动发布）
具体问题分析：
// 典型的耦合代码示例
public class VideoService {
// 一个类依赖20+其他服务
@Autowired private UserService userService;
@Autowired private DanmakuService danmakuService;
@Autowired private CommentService commentService;
@Autowired private CoinService coinService;
@Autowired private FavoriteService favoriteService;
// ... 还有15个依赖
public VideoInfo getVideoInfo(long aid) {
// 一个方法调用10+其他服务
User user = userService.getUser();
List<Danmaku> danmakus = danmakuService.load();
List<Comment> comments = commentService.list();
// 任何一个服务出问题，整个功能崩溃
}
}
单库压力（2016.05监控数据）
┌─────────────────────────────────┐
│ 主库：bilibili_main │
│ ├── 连接数：3000+（接近上限） │
│ ├── QPS：15000（性能瓶颈） │
│ ├── 存储：2TB（备份困难） │
│ └── 表数量：300+（管理混乱） │
└─────────────────────────────────┘
核心痛点： | 问题 | 具体表现 | 影响 | 量化指标 | |——|———-|——|———-| | 开发效率低 | 代码冲突频繁，CI队列长 | 功能上线慢 | 平均上线周期14天 | | 部署风险高 | 一个bug影响全站 | 故障率上升 | 月均P1故障3次 | | 扩展困难 | 无法针对热点模块扩容 | 资源浪费 | CPU平均使用率仅30% | | 技术债务重 | 代码耦合严重 | 重构困难 | 圈复杂度平均>15 | | 新人上手慢 | 理解全局需要3个月 | 人力成本高 | 新人产出周期90天 | | 技术栈固化 | 全部Java，无法尝试新技术 | 创新受限 | Go/Python需求无法满足 |
典型案例：2016年春节故障
故障时间线：
2016.02.08 20:15 - 22:30
20:15 弹幕模块内存泄漏，Full GC频繁
20:18 响应时间从200ms升至5s
20:21 连接池耗尽，请求开始超时
20:25 监控告警，但值班人员在吃年夜饭
20:35 用户大量投诉，微博炸锅
20:45 技术负责人赶到公司
21:00 尝试重启，但单体应用启动需要10分钟
21:15 重启完成，但问题依旧（未找到根因）
21:30 定位到弹幕模块，但无法单独重启
21:45 修复代码，重新编译部署
22:15 服务恢复，但已错过春节流量高峰
22:30 开始写故障报告
影响：
- 直接损失：￥200万广告+礼物收入
- 用户流失：当晚DAU下降15%
- 品牌损害：#B站崩了#上微博热搜
痛点根因分析：
问题树分析
┌─────────────────────────────────┐
│ 表象问题 │
│ • 故障频繁 │
│ • 开发效率低 │
│ • 扩展困难 │
├─────────────────────────────────┤
│ 中层原因 │
│ • 模块耦合 │
│ • 职责不清 │
│ • 边界模糊 │
├─────────────────────────────────┤
│ 根本原因 │
│ • 架构设计过时 │
│ • 快速增长导致的技术债 │
│ • 缺乏架构演进规划 │
└─────────────────────────────────┘
B站制定了为期两年的微服务化改造计划：
微服务化三步走战略
┌──────────────────────────────────────┐
│ Phase 1: 试点探索 (2016.Q2-Q3) │
│ • 选择边缘业务试点 │
│ • 技术选型与培训 │
│ • 基础设施准备 │
├──────────────────────────────────────┤
│ Phase 2: 核心改造 (2016.Q4-2017.Q2) │
│ • 用户服务拆分 │
│ • 视频服务拆分 │
│ • 支付服务独立 │
├──────────────────────────────────────┤
│ Phase 3: 全面推广 (2017.Q3-Q4) │
│ • 所有业务微服务化 │
│ • 服务治理体系完善 │
│ • 运维自动化 │
└──────────────────────────────────────┘
技术选型决策：
服务拆分原则：
核心服务拆分示例：
用户中心服务拆分
┌─────────────────────────────────┐
│ 原单体用户模块 │
│ (50万行代码，30张表) │
└─────────────┬───────────────────┘
│ 拆分
┌─────────┼─────────┬─────────┐
↓ ↓ ↓ ↓
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│账号服务│ │资料服务│ │关系服务│ │积分服务│
│ │ │ │ │ │ │ │
│·注册 │ │·头像 │ │·关注 │ │·经验值│
│·登录 │ │·昵称 │ │·粉丝 │ │·硬币 │
│·安全 │ │·签名 │ │·黑名单│ │·等级 │
└───────┘ └───────┘ └───────┘ └───────┘
数据拆分策略：
-- 原表结构
CREATE TABLE user (
uid BIGINT PRIMARY KEY,
username VARCHAR(50),
password VARCHAR(100),
avatar VARCHAR(200),
follower_count INT,
coin INT,
exp INT,
...
);
-- 拆分后
-- 账号服务库
CREATE TABLE account (
uid BIGINT PRIMARY KEY,
username VARCHAR(50),
password VARCHAR(100),
...
);
-- 资料服务库
CREATE TABLE profile (
uid BIGINT PRIMARY KEY,
avatar VARCHAR(200),
nickname VARCHAR(50),
...
);
自研BiliRPC框架（2017.Q1）：
BiliRPC架构
┌─────────────────────────────────────┐
│ 服务消费者 │
└─────────────┬───────────────────────┘
│
┌─────────────┴───────────────────────┐
│ BiliRPC Client │
│ • 负载均衡 │
│ • 熔断降级 │
│ • 超时重试 │
└─────────────┬───────────────────────┘
│
┌─────────────┴───────────────────────┐
│ 注册中心(ZK集群) │
│ • 服务注册 │
│ • 服务发现 │
│ • 健康检查 │
└─────────────┬───────────────────────┘
│
┌─────────────┴───────────────────────┐
│ BiliRPC Server │
│ • 协议解析 │
│ • 线程池管理 │
│ • 限流控制 │
└─────────────┬───────────────────────┘
│
┌─────────────┴───────────────────────┐
│ 服务提供者 │
└─────────────────────────────────────┘
服务治理能力矩阵： | 能力 | 实现方案 | 上线时间 | |——|———-|———-| | 服务注册发现 | Zookeeper | 2016.Q3 | | 负载均衡 | 随机/轮询/一致性Hash | 2016.Q3 | | 熔断降级 | Hystrix | 2016.Q4 | | 限流 | 令牌桶算法 | 2017.Q1 | | 链路追踪 | Zipkin | 2017.Q1 | | 配置中心 | Apollo | 2017.Q2 | | 服务网关 | 基于Zuul | 2017.Q2 | | 监控告警 | Prometheus+Grafana | 2017.Q3 |
踩坑记录：
坑1：分布式事务
坑2：服务雪崩
坑3：调试困难
坑4：版本兼容
经验总结：
微服务化收益与成本
┌──────────────────────────────────┐
│ 收益 │
│ • 开发效率提升30% │
│ • 故障隔离，影响范围缩小80% │
│ • 弹性扩容，资源利用率提升40% │
│ • 技术栈多样化 │
├──────────────────────────────────┤
│ 成本 │
│ • 运维复杂度增加3倍 │
│ • 网络开销增加20% │
│ • 需要额外的治理组件 │
│ • 团队学习成本 │
└──────────────────────────────────┘
最佳实践：
2015-2017年是B站技术发展的关键转型期。通过全面拥抱移动端、上线直播业务、应对用户爆发式增长、探索微服务架构，B站完成了从小型网站到中型平台的蜕变。这三年的技术积累，为后续的规模化发展奠定了坚实基础。
关键成就：
经验教训：
未来展望： 下一阶段（2018-2020），B站将面临上市后的新挑战，需要在技术深度和广度上继续突破，包括AI技术应用、中台建设、国际化等重大技术变革。
2015.01 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2017.12
│ │
├─ 2015.03: iOS客户端2.0版本发布 │
├─ 2015.06: Android客户端重构完成 │
├─ 2015.09: 移动端用户突破1000万 │
├─ 2015.12: 开始直播业务内测 │
├─ 2016.01: 正式上线B站直播 │
├─ 2016.05: 微服务架构POC项目启动 │
├─ 2016.09: 移动端DAU超越PC端 │
├─ 2017.03: 直播技术架构2.0升级 │
├─ 2017.06: 用户数突破1亿 │
└─ 2017.12: 微服务化改造初步完成 │
| 指标 | 2015年初 | 2017年底 | 增长倍数 |
|---|---|---|---|
| 注册用户数 | 5000万 | 7000万+ | 1.4x |
| 移动端DAU | 100万 | 2000万+ | 20x |
| 技术团队规模 | 50人 | 300人+ | 6x |
| 服务器数量 | 500+ | 5000+ | 10x |
| 微服务数量 | 1（单体） | 50+ | 50x |
| 直播并发观看 | 0 | 100万+ | - |
| APP下载量 | 500万 | 8000万+ | 16x |