我们为什么选择Golang重构Worker系统

blackswan 发布于2年前 阅读7678次
0 条评论

故事的起因在这里

之前发了一篇帖子,讲了暴漫用golang重构了worker系统,有好多朋友问到语言选择的问题。

其实在用Golang重写我们的worker系统之前是做过很多调研的。

真正让我们下定决心的是 Parse的一篇文章:How We Moved Our API From Ruby to Go and Saved Our Sanity。 文中讲了Facebook的Parse团队为什么选择Golang代替Ruby。

我翻译下关键几点:

Parse面临的问题

Parse跟暴漫的技术栈比较相似: 服务器Unicorn,部署使用Capistrano。在高流量面前很多问题都被指数级放大,在每次部署的时候 app server重启都要很长时间。并且Unicorn的重启并不是真正的‘graceful’(这个我们也有同感,重启之后服务会中断10秒左右,另外Parse在用Golang重构之后还写了一个库‘Grace’ 专门解决重启中断服务的问题)。 这样造成的服务中断带来的影响非常不好。

另外像Unicorn这样 每个进程同时只能处理一个请求(one process per request),不仅仅是极度的浪费,而且如果某一个action突然变慢 将会占满整个 worker poll。 导致整个服务都不可用。

方案选择

Parse在EventMachine,JRuby,c++, c#, golang 之前做了对比,并最终选择了go。

EventMachine

Parse使用了EventMachine实现他们的push服务,在使用过程中,由于相关的gem成熟度不够,总是碰到一些奇怪的bug。还是生态的问题,导致实现某些功能的时候无轮子可用。

JRuby

Parse现在是Ruby实现,所以JRuby就是正确的选择? JRuby基于rvm可以并发处理大量请求,看起来非常不错。 不是的!JRuby缺乏各种异步库的支持。Parse担心为了应对业务的增长,还要第二次重构:从JRuby到JAVA。 并且Parse的工程师团队是在不想在JVM中部署并调节各种参数。

文中还提到了 Twitter团队在迁移到Scala之前对JRuby的调查:Twitter对MRuby做了很多工作,包括自己写了一个GC工具。本来在MRuby上工作很好,效率很高的库,到了JRuby上 就不好使了(说白了就是各种库不成熟,生态系统太重要!)迁移过去之后虽然JRuby本身快了2倍,但是其他东西都面临各种问题,有点得不偿失

That's not a fault of JRuby; it's just that at the moment the surrounding ecosystem is still kind of immature. CRuby's was too; we put a lot of investment into it, which we can now take advantage of, and we would have to do the same for JRuby.

暴漫团队说实话没人用过JRuby,而且经过这么长时间的发展,生态应该会好很多,但是尽管这样,迁移之后 仍然有很多工作要做吧?

C++

Parse团队有很多c++的开发经验, 不过c++代码难以debug和维护。 就我个人而言 严重觉得c++肯定不是web项目的选择。 另外缺乏 web相关各种库支持。

C

c#有非常好的并发模型支持。不过在Linux上。。。还是看下一条吧

Golang

Golang语言效率高,语言层面支持并发,语法非常简单 易于上手,并发模型容易理解。(我们重构之前只给团队讲了一个小时的语法,然后给了一些些好的worker作为参考,然后大家都可以顺利的重构2-3个worker,在两周的时间内)。 应该是worker系统的最佳选择。

最后回到暴走漫画的问题

大家的疑问更多是 既然都是io消耗,为什么golang会快这么多。 我试着解释下(水平有限): golang静态语言 不需要类型推断 抛弃了各种语法糖,在语言效率层面上快上不少,另外在数据库io方面 gorm 没有 ActiveRecord的黑魔法,自然会快很多。

暴漫的worker系统瓶颈在高并发峰值,一旦抗不过去后面就会持续累积。 而golang在单个任务上虽然只有5倍快,但是良好的并发机制,使job的执行速度飞快。 而在原系统中 每台机器150并发跑慢之后,有些100ms的任务都等到23s之久。

单个任务执行速度快5倍, 并发再快5倍,所以从10台减到1台 而 golang机器还游刃有余是合理的。

Parse在重构的时候考虑的是能容纳当前业务峰值的10倍的方案。我觉得我们在挑选方案的时候 也要有这种意识。虽然有些方案确实也可以解决目前的困境,但是对以后的架构调整是否有益,或者说兼容

需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。