内容简介:故事的起因在之前发了一篇帖子,讲了暴漫用golang重构了worker系统,有好多朋友问到语言选择的问题。其实在用Golang重写我们的worker系统之前是做过很多调研的。
故事的起因在 这里 。
之前发了一篇帖子,讲了暴漫用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倍的方案。我觉得我们在挑选方案的时候 也要有这种意识。虽然有些方案确实也可以解决目前的困境,但是对以后的架构调整是否有益,或者说兼容
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
How to Design Programs, 2nd Edition
Matthias Felleisen、Robert Bruce Findler、Matthew Flatt、Shriram Krishnamurthi / MIT Press / 2018-5-4 / USD 57.00
A completely revised edition, offering new design recipes for interactive programs and support for images as plain values, testing, event-driven programming, and even distributed programming. This ......一起来看看 《How to Design Programs, 2nd Edition》 这本书的介绍吧!