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 年時間才完成技術栈轉型。