奇虎360 和 Go

英文原文： Qihoo 360 and Go

翻译 by 开源中国：奇虎360 和 go

在中国，奇虎 360 是一个互联网和手机安全产品及服务的主要供应商，截止到 2014 年 6 月，奇虎拥有 5 亿的 PC 活跃用户以及超过 6.4 亿移动用户。奇虎还运营着中国最受欢迎的网络浏览器和 PC 搜索引擎(原文如此)。

我的团队，推送服务团队(Push Service Team)，为超过 50 个公司的产品提供服务（PC 和移动），包括成千上万放在我们的开放平台的应用程序。

我们对Go的青睐要从2012年第一次尝试为奇虎的一个产品提供推送功能开始。最初的nginx + lua + redis方案因为负载过大没能满足我们对实时性能的需求。在这种情况下，最新发布的1.0.3版Go引起了我们的注意，借助它提供的goroutine和channel特性，我们在几周之内开发完成了一个原型。我们的系统最初运行在20台服务器上，能够处理2000万实时连接，每天发送200万信息。现在这套系统在超过400台服务器运行，支持2亿实时连接，每天发送超过100亿条信息。

随着商业上的快速扩张以及对我们推送服务的需求的增长，最初的Go系统很快遇到了瓶颈：堆大小达到69G、GC停顿最高能到3-6秒。更头疼的是，我们必须每周重启系统来释放内存。实话实话，我们考虑过放弃Go，用C来重写全部的核心组件作为替代。然而，并未如我们所愿，我们在迁移业务逻辑层的代码时遇到了麻烦。结果就是，作为当时唯一的人员，我不可能在维护这个Go系统的时候确保业务逻辑顺利迁移到C的服务框架上。

因此，我决定继续留在Go系统上(可能是我最机智的一次无奈选择)，并且很快就取得了重大进展。下面是几个要点和我们总结的小技巧：

用长连接(使用连接池)替代短连接，减少通信过程中缓冲区和对象的创建。
适当的使用对象池和内存池，减少GC的负载。
使用任务池，原理是由一组协程作为消费者轮询并执行全局的任务或者来自消息队列的任务——由持有连接的协程作为生产者发送任务，用这种模式取代为每个任务生成一个临时协程。
监视并控制程序中协程的数量。缺乏控制会使GC不堪重负，比如，因为不加控制的接受外部请求而出现的协程数峰值施加在GC上，同时发往内部服务的RPC调用可能阻塞新创建的协程。
在移动网络中，要记得给连接设置读写超时限制，否则可能导致协程阻塞。在局域网中就要慎重使用此设置，否则会降低RPC通信的效率。
使用Pipeline(在TCP全双工特征下)来增强RPC框架的通信效率。

最后，我们成功的对架构进行了三次迭代，其中有两次对 RPC 框架的迭代还是在人手有限的情况下完成的。这都得益于 Go 开发的便利性，下面是我们当前的系统架构：

持续优化的过程可以通过下表来说明：

还有，在这些优化之后，再也不需要临时的释放内存或者重启系统了。

更令人兴奋的时我们已经开发了一个线上实时反映 Go 程序运行概况的可视化平台。现在我们很轻松的就可以拿到系统状态并做出诊断，消除隐患。这是系统运行中的截图：

这个平台还可以做一件很棒的事情——模拟数百万用户在线的连接和操作。通过使用这个分布式的压力测试工具（也是用 Go 实现），并观察所有这些直观的实时数据。我们评估每一次优化的效果并且定位系统瓶颈然后排除问题。到目前为止，我们几乎试遍了所有系统优化的手段。我们还是期盼 GC 团队能带来更多的好消息让我们进一步的从繁重的开发工作中解脱出来。想来，也许有一天我们的这些经验会因为 Go 的持续发展而变得无用武之地。

这也是为什么我要以表达获得了这次出席 Gopher China 的机会的谢意来结束此次分享的原因。这是一个我们去学习，去分享的盛会，也是一个展现 Go 在中国的普及和繁荣的契机。在奇虎内部有许多其他的团队开始去了解 Go，或者已经在试着使用 Go。

在可预见的将来，我相信中国会有更多的互联网公司加入我们的行列，用 Go 来重新创建他们的系统，而 Go 开发团队的成果会使更多的开发者和公司收益。