Grab：

从RoR转向Go，后台全用Go

用Go和jenkins打造了一套CI系统

Grab的Go实践

• go的代码存储于单个的代码仓库

  
  

• 分布式跟踪

  
  
  
  
  
  
  
  

• 用context传递跟踪ID，调用方地址等，配合OpenTracing这个方法论

• 测试

• 单元测试（使用了testing.T这个包，Mock的使用，对数据库等全局单例的Mock是个坏实践，改为将数据库定义为接口，作为依赖注入）

• 端到端的测试

  
  

• CodeReview

  
  
  
  
  
  
  
  

• review的时候可以看到测试对代码覆盖的情况；单元测试覆盖率低于一定百分比，CI Build主动失败

使用Go遇到的坑

• 问题一

  
  

• 解决办法

  
  

• 问题二

  
  

下一步计划

函数式中，每个docker跑的是一个函数

讯联：

Go的技术特点

• 开发效率高
• 天生并发支持
• 简洁的错误处理：defer、panic、recover

技术选型

• 安全性
• 漏洞少，因为语言新，第三方的东东少（java的漏洞多为第三方组建引入）
• 有一个网站可以查看语言的漏洞统计
• 稳定性
• 高可用架构，应用可无状态扩展
• 吞吐量
• 并发处理能力
  • 以http和rsa作为测试场景，go比java效率高
  • json解析场景，java的效率更高
  • 在一个秒杀系统的挡板应用上，感受到了go相比java在吞吐量上的优势

15年为单体架构，17年为微服务架构，全部使用go实现

踩过的一些坑：

• 变量作用域
• channel操作

goroutine没有优先级，怎么搞定类似线程优先级的问题，让高优先级的被调度到？

• 从实现角度来考虑，可以用一些其它的策略，如触发机制

goroutine堆积的情况怎么处理？

• goroutine的系统消耗比线程小

360：

Go在大规模搜索中的应用

ES和HBase在规模和效率上难以满足要求

多个doc.gz连成一个hadoop文件，gz格式在分段保存上有优势

用差分做了压缩，仍然有2.4T

为了简单，使用了CGO和C++配套

协程中再起协程，协程是临时创的，没使用协程池或连接池来做协程复用

消息队列用的channel，而非redis之类来实现

开源
嵌套依赖目前还没有很好的解决，于是all in one，但一些开发者还是使用了拆成5个微服务的方式

总结
对象池导致代码可读性差，目前gc没有那么明显，除非极端情况，否则不太需要了