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没有那么明显，除非极端情况，否则不太需要了
