Charity Majors 是移动后端支持平台 Parse 的工程师。近日，他 撰文 介绍了他们将API 从Ruby 迁移到Go 的过程。
2011 年， Parse 借助 Ruby on Rails 快速推出了第一个版本。他们用 Unicorn 作为 HTTP 服务器，用 Capistrano 部署代码，用 RVM 管理环境，并用许多开源 gems 处理 YAML 解析、oAuth、JSON 解析、MongoDB 及 MySQL 等方面的工作。此外，他们还用 Chef 管理他们的基础设施。
起初，平台运行良好。但随着代码库的增长，部署时间越来越长，Unicorn 服务器无法很平稳地重启。到 2012 年底，他们有 200 个 API 服务器运行在 m1.xlarge 类型的实例上，每个实例 24 个 Unicorn 工作进程。该平台每秒需要为来自 60000 个移动应用的 3000 个请求提供服务。一次完整部署或回滚需要 20 分钟。另外，在通常的 Ruby on Rails 设置中，工作进程池大小固定，每个工作进程一次只能处理一个请求。随着 API 流量和应用数量的增加，“一个请求一个进程”的 Rails 模型开始无法满足平台的扩展需求，而增加数据库和工作进程也增加了故障点和性能退化的可能。
于是，他们认为，他们需要迁移到一个完全不同于 Rails 的异步工作模型。他们对比了如下选项：
- EventMachine ：绝大多数 Ruby gems 都不是异步的，而且许多不是线程安全的，所以经常很难找到一个库可以异步地处理一些常见任务。
- JRuby ：JRuby 从根本上说还是 Ruby，同样缺少异步库支持。而对于 Java，他们的后端或 Ops 团队不愿意部署和调优 JVM。
- C++ ：他们现有的 C++ 代码已经难以调试和维护。与其它现代编程语言相比，C++ 开发的效率不是很高。C++ 也缺少一些他们需要的库，比如 HTTP 请求处理。C++ 可以处理异步操作，但并不好用。
- C# ：C#有最好的并发模型，并且支持 Async 和 Await。但真正的问题在于，Linux 对 C#开发的支持不够好，缺少一些与常用开源工具互操作的库。如果选择 C#，那么他们就需要对工具链做重大调整。
- Go ：同 C#一样，Go 也在底层内置了异步操作。MongoDB Go 驱动程序可能是现有最好的 MongoDB 驱动程序，而与 MongoDB 的复杂交互是 Parse 的核心所在。Goroutines 比线程更轻量级。
最终，他们选择了 Go，用它重写了 EventMachine 推送后端、核心 API 服务器，实现了 Rails 中间件的处理功能，结果：Parse 平台的可靠性提高了一个数量级；API 不再因为数据库和后端服务的增加而日益变得脆弱；由于去掉了大量的 gems 和隐含假设，代码库变得更干净；Ops 团队不用每周处理多次 Ruby API 故障了；预分配的 API 服务器池缩减了约 90%；移除了孤立的 Rails API 服务器筒仓，简化了架构；完整集成测试的时间由 25 分钟缩减至 2 分钟；完整 API 服务器部署（包含滚动重启）的时间由 30 分钟缩减至 3 分钟；Go API 服务器启动更平稳。
虽然 Parse 成功地实现了迁移，但是许多网友都认为 Majors 给出的选择理由并不充分。网友 pron 指出，JVM 易于监控、控制、调试和性能分析。在大多数情况下，JVM 调优只需要设置 GC 方式、最大堆大小和新生代比率三个值。对此，Majors 的答复是，“我们讨厌有关 Java 和 JVM 的一切”。网友 headius 则为 Parse 团队没有试用 JRuby 感到可惜，因为单个 JRuby 实例就可以处理成百上千的并发请求，而且不需要采用异步方式。他认为，JRuby 团队不需要重写就可以解决 Parse 的问题。网友 Zazi Bazuka 则这样评论道：
我讨厌这篇博文，攻击 Ruby 成了现在的一种趋势。但攻击总是来自不了解 Ruby 生态系统的人。为什么不使用 Puma 或其它多线程服务器？！为什么使用 EventMachine？互联网上到处都是不应该使用它的文章，你们应该使用 celluloid.io 代替它。
Majors 的文章 在 Hacker News 上也引发了激烈的讨论 ，其中许多网友同样对 Parse 的选择过程存在疑问。网友 aikah 就表示：
当了解业务域和性能问题时，Go 是一个不错的迁移目标。但是，我不推荐初学者用它构建安全的 Web 应用程序，因为……Go 确实不适合用于传统 Web 站点的快速开发。让我吃惊的是，Parse 用 Rails 编码，我原以为他们以 Node.js 为基础构建，因为 Cloud Code 用了 JS。
对此，lacker 答复说：
我们考虑过它。那时，一个很大的 Node 代码库看上去很难维护。不过，工具比那时好了。如果我们现在重新讨论，我认为，采用 Node 的理由会更令人信服，如果我们等到 ES6 成为标准后再讨论，理由还会更充分。