5. 真实案例：技术栈演进路径
了解了理论后，让我们通过真实案例，看看技术栈是如何在实际项目中演进的。
5.1 GitHub：从 Ruby 到多语言共存
2008 年：GitHub 上线，全部用 Ruby on Rails 开发。
为什么选择 Rails？
- 创始人是 Ruby 社区活跃成员
- 快速开发，适合初创公司
- "约定优于配置"减少决策疲劳
2010 年代初期：问题来了
- 用户量爆炸式增长，Rails 成为性能瓶颈
- Ruby 的 GIL（全局解释器锁）限制多线程性能
- 每次部署需要重启整个应用，停机时间长
解决方案：渐进式重构
GitHub 采用绞杀者模式 (Strangler Fig Pattern)：
- 识别瓶颈：找出最慢的功能模块（如代码搜索、通知系统）
- 逐步替换：用 Go 重写高性能服务
- API 网关：前端先调用新服务，失败时回退到旧服务
- 监控验证：确保新服务稳定后再完全下线旧代码
2015 年：GitHub 使用 Go 重写了代码搜索功能，查询速度提升 10 倍。
2018 年：通知系统从 Rails 迁移到 Go，延迟从 2 秒降到 100 毫秒。
今天的 GitHub 技术栈：
- 主站：仍然 Rails，但核心功能已拆分为微服务
- 高性能服务：Go（搜索、通知、Git 操作）
- 前端：React + TypeScript
- 基础设施：Kubernetes + MySQL + Redis
关键启示：
技术栈演进不是革命，而是渐进式改良。选错语言不致命，但拒绝改进会致命。
5.2 Twitter：从 Ruby 到 Java
2006 年：Twitter 上线，用 Ruby on Rails 开发。
问题出现：
- 用户快速增长，频繁宕机（著名的"Fail Whale"时代）
- Rails 无法处理高并发，每次推文都要查询数据库
- 响应时间从 200ms 涨到 5 秒
演进过程：
- 2008 年：引入 Scala（JVM 语言）处理消息队列
- 2010 年：核心搜索功能迁移到 Java（Lucene）
- 2011 年：整个推文流处理迁移到 Java
- 2017 年：完全迁移到微服务架构，多语言共存
今天的 Twitter 技术栈：
- 前端：React + JavaScript
- 后端服务：Java、Scala、Go、Python 混合
- 消息队列：Kafka（Scala/Java）
- 存储：HDFS、Cassandra、Redis
关键启示：
不要推倒重来，要渐进式迁移。Twitter 用了 5 年时间才完成技术栈转型。