FreeWheel基于Go的实践经验漫谈——GC是大坑(关键业务场景不用),web框架尚未统一,和c++性能相比难说

  1. 云栖社区>
  2. 博客>
  3. 正文

FreeWheel基于Go的实践经验漫谈——GC是大坑(关键业务场景不用),web框架尚未统一,和c++性能相比难说

桃子红了呐 2017-11-15 14:23:00 浏览1330
展开阅读全文

摘自:http://www.infoq.com/cn/news/2017/06/freewheel-experience-on-go

Go语言是FreeWheel公司目前主要力推的一个方向,在其看来,面向服务的架构的大环境中,Go非常适合做一些功能相对独立、功能比较明确的微服务的语言。在结合已有的各种编程语言,计算框架(如Hadoop、Java、Ruby、C++)的基础上,FreeWheel把Go语言定位成用来实现轻量级服务或API的缺省编程语言,将之与用来完成更小粒度工作的Python结合在一起,就构成了FreeWheel的整个技术语言栈 。
 
FreeWheel在Go上所经历的“坑”

虽然从2012年Go 1.0发布到团队相继采用Go来编写项目,这中间经历了大致三年左右的时间,但由于在GC等许多问题的克服上需要Go本身去做一部分迭代,FreeWheel也需要把技术对客户的影响控制在一个可控的范围内,因此作为一家B-to-B企业,其采用了更为渐进的方式将Go语言应用到自身的生产平台上。

在这个过程中,FreeWheel也经历过两个较为重要的“坑”。

  • GC的问题

如多数人所知道的一样,Go语言垃圾回收器存在一定的缺陷,特别是容易导致整个进程不可预知的间歇性停顿。像某些大型后台服务程序,如游戏服务器、APP容器等,由于占用内存巨大,其内存对象数量极多,GC完成一次回收周期,可能需要数秒甚至更长时间,这段时间内,整个服务进程是阻塞的、停顿的,在外界看来就是服务中断、无响应。FreeWheel在使用Go 1.4版本时也遇到过类似问题:广告预测团队用Go来实现调度器,平常运行的时候没有问题,但一旦触发1.4版本下GC的时候,该系统的downgrade非常厉害,导致任务的堆积非常严重,触发报警,同时其处理性会下降很多,也会影响其他上下游系统的正常运转。

于是,FreeWheel在当时主要采取了三种对策:一、并不把Go用在非常关键的、对服务进程稳定性要求较高的系统里;二、引入Kafka之类的能够持久化的消息队列,能够缓存和重释这样的方式去解决这个问题,使系统能扛住冲击,并在后面把它消化掉;三、尽量复用已经创建的对象,防止Go频繁的创建了回收对象。

Go 1.5到1.7版本相继出来后,GC的系统性能得到不断改进和持续提升(从秒级到毫秒级)。对于目前FreeWheel内生存环境不太关键的系统来说,Go 1.7之后的GC已经可以达到可接受的范围和程度以内。

  • 内置数据结构的变化

很多人都知道,Go语言提供的字典类型并不是并发安全的,此外由于Go语言发展较快,有些内置的数据结构如Map的行为也发生了变化。因为Map为引用类型,所以即使函数传值调用,参数副本依然指向映射m,所以多个goroutine并发写同一个映射m。例如,如果map由多协程同时读和写就会出现 fatal error:concurrent map read and map write的错误。

Go 1.6版本之前Map可以支持并发读写,但FreeWheel开发的程序在升级到1.6之后也就发现Map产生了读写竞争的问题。

对于这一问题,常用的有两种解决方案,一是如上所说的加锁(包括通用锁和读写锁),二是利用channel串行化处理。FreeWheel的做法也主要靠两方面,其一是将锁粒度设计的更细,使得并发的依赖更少;另外是在不同的数据结构中,选择性能更高的一方。比如array和slice中,前者就是更优选择。

FreeWheel首席架构师刘昊植认为,并发的时候不能假设Go能完美处理所有的工作,工程师需要结合并借鉴传统(成熟)的编程语言,比如Java或者C对并发的经验,在动手之前就想清楚并发的规模、锁的粒度等,并对系统会如何运行有非常明确的设计和理解。

同时,刘昊植也坦言,随着Go的快速发展阶段,FreeWheel内部也有多种不同的声音,例如运维团队就会觉得快速发展阶段的语言稳定性不够,它的特性和数据结构会因为版本升级等原因产生很大变化,并且部分变化不能完全保持向前兼容。在这个过程中FreeWheel的总结是:不管Go怎样实现,都要对系统并发做很好的支持,在应用层面做保护和控制,这样才保证这个系统能够正常的运行。

为什么FreeWheel没有全部用系统重写Go

从编程范式的角度来说, Go语言是变革派,而不是改良派。对于C++、Java和C#等语言为代表的面向对象的思想体系,总体来说全球范围内许多公司对Go语言的态度更为保守,多数持有限吸收的观念(这可从下图中Go的热度分布情况看出)。

即使FreeWheel在实践中发现Go比其他类编程语言具有许多更为明显的优势,如在写并行上,相比Python这样的解释语言要高一个数量级;如前期由Python开发的很多轻量级API,因为全局解释锁GIL的关系而面临着进程间通信带来额外开销,所以就把轻量级API迁移到Go上;又比如Go在并发上的优势,适合面向多用户同时上传、同时调用API的场景……但其内部团队也并没有用Go来重写全部系统。原因主要有两点:

第一,FreeWheel有很多已有的算法实现,想全部切入到Go上会面临巨大的开销和成本;第二,相比C或者C++,Go在高性能方面还没有完全的证明自己。在Web服务器端,它目前也没有一个特别好的像RoR、Django、或者PHP的流行框架。对于FreeWheel来说,整个广告服务器是不允许出现明显的downgrade情况(尤其是当GC时),所以对这种非常关键的系统,目前还不能完全用Go去写。所以刘昊植也认为,Go在扩展使用场景层面可能还需要做一些较大变革。

此外,FreeWheel基于Go的Web程序,目前使用的是Gorilla框架。但从Martini、Revel、Gocraft/web等几款主流框架的使用和评价上看(可以下图github上的数据做个参考),Go社区还没有一款处于统治地位的Web框架。如果Go想把它的触角伸得更长,这可能是其未来发力的一个方向。

但总的来说,Go在高并发、开发效率等特性上的优势,决定了Go在FreeWheel内的采用程度会越来越深。刘昊植说:“除了一些已有业务依赖于Hadoop、Spark这样的基础设施,对于新增的业务和功能,Go语言会是我们的首选。”

另外,FreeWheel希望其使用的编程语言是能够得到跨大陆、跨时区、受所有工程师共同认可的,所以Go或许会是其最好的选择。这个过程中,FreeWheel也评估过很多其他语言如Scala、Rust等,但最终因为Go在学习成本、统一实践、社区规模等方面的优势而胜出。














本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6999802.html,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论