# 技术选型与决策
架构师最核心的能力——不是写代码,而是决定用什么代码
前置知识:第01-11章全部内容(技术选型需要对各方案有深入理解)
阅读指南(初学者必看)
为什么你需要学习技术选型与决策?
前11章你学了各种技术——帧同步、状态同步、ECS、热更新……但实战中最大的问题不是"怎么实现",而是"选哪个"。选错了方向,写再多代码也是白费。技术选型是架构师最核心的能力。
学完本章,你能回答:
- 技术选型应该考虑哪些因素?为什么"团队因素"最重要?
- 游戏通信协议选 JSON/Protobuf/FlatBuffers?各适合什么场景?
- 技术债怎么管理?什么时候该重构,什么时候该忍?
本文结构
第一部分:技术选型框架——四个维度的选型方法
第二部分:游戏技术选型案例——两个实战选型分析
第三部分:技术债管理——借债、还债和避免利滚利
一、技术选型框架
选型考虑因素:
1. 团队因素(最重要!)
- 团队熟悉什么技术?
- 招聘市场是否好招人?
- 学习曲线是否可接受?
2. 业务因素
- 游戏类型(MMO/MOBA/休闲)?
- 并发量级(千/万/十万)?
- 是否需要跨平台?
3. 技术因素
- 性能是否满足?
- 生态是否成熟?
- 社区是否活跃?
4. 成本因素
- 开发成本
- 运维成本
- 许可证成本
二、游戏技术选型案例
案例1:游戏通信协议选什么?
JSON:
✅ 开发友好,调试方便
❌ 体积大,解析慢
→ 适合:开发阶段、简单游戏
Protobuf:
✅ 体积小,跨语言,有Schema
❌ 需要编译.proto,调试不直观
→ 适合:正式游戏通信
FlatBuffers:
✅ 零拷贝,解析极快
❌ API不友好,体积比Protobuf略大
→ 适合:高频实时消息(位置同步)
案例2:游戏同步方式选什么?
帧同步:
适合:RTS/格斗/MOBA(需要确定性)
前提:逻辑能保证确定性
状态同步:
适合:MMO/RPG/FPS(服务器权威)
代价:带宽大,服务器计算量高
预测回滚:
适合:竞技格斗(需要低延迟手感)
代价:实现复杂,需要状态保存
三、技术债管理
技术债就像金融债:
好的技术债:为了快速上线,暂时简化实现
→ 有意识地借,有计划地还
坏的技术债:没有规划,代码越改越乱
→ 利滚利,最终无法维护
还债策略:
1. 重构时间预算:每个迭代预留20%重构时间
2. 童子军规则:每次修改让代码比之前好一点
3. 债务清单:记录技术债,定期评估优先级
4. 架构演进:渐进式重构,不要推倒重来
自问自答
Q:为什么团队因素比技术因素更重要? A:再好的技术,团队不会用就是零。用团队熟悉的技术,开发效率高、Bug 少、好招人。反之,用"技术更好"但团队不熟悉的技术,开发慢、Bug 多、招人难。技术可以学,但项目等不起。
Q:JSON 真的不能用于正式游戏吗? A:不是。如果游戏是休闲类型、并发量不大、开发阶段,JSON 完全够用。过早优化协议是一种浪费。关键是:开发阶段用 JSON 快速迭代,上线前评估是否需要切换 Protobuf,预留协议层抽象。
Q:什么时候该重构,什么时候该忍? A:判断标准——如果修改代码的恐惧感 > 重构的工作量,就该重构了。具体来说:1)改一个小功能要改 5 个文件 → 该重构了;2)每次改这个模块都出 Bug → 该重构了;3)新人看不懂这坨代码 → 该重构了。否则,忍。
Q:技术债可以完全避免吗? A:不可能。任何项目都有时间压力,为了赶进度必然会有简化实现。关键不是避免技术债,而是"有意识地借债,有计划地还债"。就像金融债——合理的贷款可以帮助你更快发展,无规划的借贷才会让你破产。
实践任务
- 任务1:对你当前项目的通信协议做选型分析——列出 JSON/Protobuf/FlatBuffers 在你场景下的优劣,给出推荐
- 任务2:对你当前项目的同步方式做选型分析——列出帧同步/状态同步/预测回滚的适用性,给出推荐
- 任务3:列出你当前项目的 Top 5 技术债,评估每项的优先级(影响 × 紧急度),制定还债计划
- 任务4:模拟一个技术选型会议——对"游戏服务器用什么语言"做选型分析(Go/Java/C++/Node.js)
- 任务5:用童子军规则,找一个你最近写的模块,每次修改时让它比之前好一点,记录 3 次改进
与其他章节的关联
| 本章内容 | 关联章节 | 关联点 |
|---|---|---|
| 同步方式选型 | 第03章 帧同步Lockstep | 帧同步是三种同步方式之一 |
| 同步方式选型 | 第04章 状态同步 | 状态同步是三种同步方式之一 |
| 同步方式选型 | 第05章 预测与回滚 | 预测回滚是三种同步方式之一 |
| 协议选型 | 第06章 自定义UDP协议与KCP | 自定义协议 vs TCP/UDP 的选型 |
| 热更新选型 | 第11章 Lua/CSharp脚本与热更新 | ILRuntime/HybridCLR/xLua 的选型 |
| 架构模式选型 | 第01章 系统设计方法论 | 分层/事件驱动/微服务的选型 |
| 团队因素 | 第10章 游戏架构设计模式 | ECS 的学习曲线陡,团队因素是关键考量 |
上一章:11-LuaCSharp脚本与热更新 下一章:13-弱网优化与实战