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沒有那么明顯，除非極端情況，否則不太需要了
