移动后端支持平台Parse将API由Ruby迁移到Go

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都不是异步的，而且许多不是线程安全的，所以经常很难找到一个库可以异步地处理一些常见任务。\\t
JRuby：JRuby从根本上说还是Ruby，同样缺少异步库支持。而对于Java，他们的后端或Ops团队不愿意部署和调优JVM。\\t
C++：他们现有的C++代码已经难以调试和维护。与其它现代编程语言相比，C++开发的效率不是很高。C++也缺少一些他们需要的库，比如HTTP请求处理。C++可以处理异步操作，但并不好用。\\t
C#：C#有最好的并发模型，并且支持Async和Await。但真正的问题在于，Linux对C#开发的支持不够好，缺少一些与常用开源工具互操作的库。如果选择C#，那么他们就需要对工具链做重大调整。\\t
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则这样评论道：