Gopher China 2016 见闻

记录gopher china的一些见闻，内容比较多，内容上一点一点再完善。

Insights in 2016 gopher大会

感想颇多，能写就写点，怕有的忘记了。确实不可能把每个嘉宾所讲的内容都听懂，也不现实（他们也没想让你听懂），毕竟人家都经过了那么长时间的实践，通过几个图，你也无法洞悉其中的细节，就是从中听一下对自己有启发的内容，对哪个环节感兴趣，会下可以继续细聊。有了这样的想法，就平和多了，虽然很努力的又听又记，但确实是好多时候不知所云，这里也只能尽量做一个整体梳理。

大会ppt链接 全是干货 特别特别干 。

4.16分享

晚上的技术party

pingcap的刘总与许总争论其了rust以及golang的话题。刘总的Tikv的底层是使用rust构建的，可以看出来刘总是一个对代码有追求的程序员。他似乎不太能受得了golang的

if err!=nil{    return err }

的问题。rust里面似乎有很多fancy的写法，但是这种写法似乎并不适合工程方面的concern。

老许虽然已经是公司ceo，但是在本质上还是一个程序员的性格，看到刘总黑golang，也抑制不住内心的冲动，上去抢过话筒，就开始唇枪舌战，这个场面，是晚上特别有意思的一幕。大家看到这样的场景真是蛮有意思，毕竟都是大佬。许总不用多说了，另一方代表，rust，没多少人会，更没有多少人能那他写一个分布式的database，在他看来，cgo的调用代码特别丑，整个底层用rust重写之后，效率高60%（不知道这个60%具体指什么，又是从哪里来的）。所以他们撕起来，特别好看，问题自然也就越辩越明了，大致梳理下：

其实正常会看来，这确实不是一个需要太concern的问题，效率低，也有可能是golang用的不好，代码结构不好，算法不佳，想后面小米讲的gorouter的ops 6k 到 10w 的优化，又怎么说呢？单纯把程序问题归结为语言效率，确实有失偏颇。如果说，单独用golang于rust写一个benchmark的程序，那60%的差别，那也算，要是对于整个项目来说，这种60%的说法，确实不很客观了。

其实说道最后，语言之争应该没有绝对的好坏，关键是要看 使用场景是什么 ，颇有点具体情况具体看待的意思，要在不同的使用场景下，发挥出不同语言的优势来，毕竟尺有所短存有所长。

在party上好多人似乎在这种时候还在关心docker的使用，其实这个已经是一种有点out of date的话题了，docker的使用已经毋庸置疑了，在各种网站上，已经很多了，关键是怎么去跟人家讲这个问题。（事后证明 现在还关心docker怎么用的人 确实out of date了 各个站在潮流之巅的IT公司 容器早已用的飞起了 只是使用场合和方式的问题而已）

总结起来，采用新技术之前，有三点要考虑：

• 自己企业中遇到的痛点是什么
• 新的技术可否解决这个痛点
• 技术人员能否hold住这项新的技术

通过实例去说服应该是一个比较好的表述，总比说一些high level的东西更容易让人信服。

最后和亮哥讨论技术与市场，运营或者业务方面的问题，实际上这两个东西总是分不开的，也不可能分开的，如果真的分开了，我感觉应该是方向出现问题了，这也可以解释，为啥开源项目总是不能百分百拿到企业中使用，因为他们本来就不是为了某些企业的具体场景而使用的。

要能回答，这个技术，适合解决什么样的用户的什么样的问题。

什么样的用户的什么样的需求，或者场景，推动了这些技术的产生。那些believe what you believe 的客户群在哪，做产品是这样，写论文，也是要这样，基本根上的东西弄明确，才不至于跑偏。

比如京东使用的openstack+docker的方案，为什么要用，因为根据它们的业务需求，最初的时候还是docker当成宿主机来用？怎么用的，它们的paas是怎么构建的，包括京东也是，这些东西的确给它们带来了好多切切实实的好处，当然他们也是遇到了好多实际的问题时候，才决定使用这些技术的。

私底下以为，大厂的docker实践靠谱多了，起码真正把这些内容用到了实处，不像市面上的打着各种私有云解决方案的旗号的公司，他们到底最后有没有帮别人创造价值，就很值得怀疑了。到头来，只不过的是把docker用的更熟练了而已，个人感觉，纯粹的技术方面研究，不太能给人多少欣喜的体会。当然以上纯属个人哔哔。

要意识到，实际使用起来并不是说，我那个docker来用这么简单，只能说，gopher这个场子，对于paas的讨论，too young too simple了。远远不及之前的容器大会。现在的立足点远远不是docker了，而应该是paas平台的各个模块，这些才是中厂和大厂真正care的，在docker新版本被解耦之后，立足点甚至应该是runc的这种维度了。其实越是大公司，拥抱docker越早，使用docker或者容易环境也越早，只是目前这个gopher会，大公司很少来讲的，他们都有自己的服务与团队。

对于小公司来说，只要使用第三方供应商提供的云服务，大厂商有自己的团队，有自己的私有云，我觉得从这个角度讲，daocloud思路还好，私有dce与共有平台，两个维度的产品。

七牛那边，感觉应该是做分场景的paas了。这种细粒度的划分，将使得它们的paas产品更有针对性，明天真是要过去好好再看看了。

显然gopher的几个重要场景已经非常清楚了，游戏服务端编程，容器paas平台，分布式数据服务，web server 开发。

coreos hongchaodeng

感觉他之前应该是一个acm的大牛，萌萌胖胖的，一口广东口音。之前看过他的文章，关于k8s的调度的那一篇，go profiling用的飞起，之前只读了前半部分吧，还是要再回过头来好好读上一读。

问了他一些相关的经验，他说了一些high level的，也算是鼓励吧：“要努力，要坚持，要把所有问题都弄懂，思路要理清楚，方向要对，在他看来，调试程序要讲证据，就是你为什么要这样做，你为什么要改这行，这个证据，我能想到的，就是golang 的profiling工具” 我不知道，怎么样操作，方向才算是对，看起来，他在分布式这一行，或者性能优化这一行，已经干了好多年了，对于app sampling instrument这些，确实是相当有经验。自己也确实需要一点时间积累的，干一年两年，可能没有什么显著的特点，但是干3年，5年，总有很好的提高，总要很好的提高。

个人感觉，一个没用过profiling的程序员不是好程序员，没用过，要么是对自己写的代码没有追求，要么就是做的事太low，没有太多的并发请求，当然也没有必要使用什么profiling工具。

其他

内容太多了，由于是倒着写的，所以记录不动了，一些tips慢慢整理吧。。。bilibil和pingcap都是讲的分布式文件系统，一个与业务紧耦合，快速开发，基于facebook haystack paper，另一个商业版kv store， 功能fancy。全栈大牛mijia分享了go web 方面的各种应用，框架，golang 在web方面的concern，chenhui分享了golang在AI方面的应用，以及他个人的几个项目，但是AI这块，显然并不是golang的优势啊。心动网络，演示gomobile的使用，cto现场手写代码，简直流畅的飞起。。。BFE golang 改造就系统，gc 在大量连接时候的各种优化。

4.17分享

Danny分享 high performance golang

直接ppt吧，之前还有篇文章，干货慢慢，好多实际的 tips 可以具体实践下。

阿里CDN

先吐槽一下，之前有一天，阿里CDN电话过来面试，面试官就是分享者wxw，声音太独特，绝对错不了，大概还是因为基础知识答的不过关，对于简历上写的一些开源项目的理解也不够深入，最后被rejected了，感觉失去一个好机会。

具体cdn的内容听不太懂，就记住个全球500+node，调度据测很nb，可以提前把资源分配好，应该还是基于精准的监控，能做的了这个，具体ppt吧，但是golang的一些tips很值得学习，怎么从c++过度到golang，整理再最后了。

还有关于influxdb，他们不用influxdb的原因，没有细说，性能上不满足需求，运维成本较高（高在哪些地方呢）。后来改成OTS了, open Ts Db 也是一个存时间序列的数据库。

关于监控，他提到了，监控要与评估，调度结合，他们实际也正是这样做的，比如发现嘉兴界定啊的网络环境竟然好于杭州，这种思路，真的是很赞，因为只有有了客观的测量技术，才知道什么样的是最好的，说的很朴素也和在理。

服务治理

许总的service government是特别high level的，算是后端service开发总纲了，毕竟是多年的技术经验，到这个程度基本上已经不care具体技术的的那些“细枝末节”了。

显示qlang的广告，一个golang友好的脚本语言，按照许总的话说，已经是商用级别。

之后是service government的几大块，具体参考ppt吧，几点深刻：

关于微服务，谁都会说，说的多细，看你本事。

• 从golang的角度，golang+channel，交换的是数据，而不是代码，这的微服务，就是把不同的模块之间流向，通过channel连接起来，它们之间再进行数据的交互。由于应用拆分之后，不同模块之间的数据交互自然会增多，怎么把这种数据流动带来的的开销降低，是需要考虑的
• 微服务最早的理念来自于SOA（service-oriented-architecture），演化到现在，实质上是一种面向API的编程。
• 在物理层面上，微服务之后，整个服务的复杂性会变高，但是在架构上，由于服务解耦，粒度更细，不同模块之间可以按需进行scale操作。
• 微服务的架构与企业组织架构想吻合，这样可以使得组织架构按照服务来进行划分，而非按照角色进行划分，每个人对自己的服务也更加负

这里 有一篇软件大师谈论微服务的文章，可以深入阅读。

关于服务发现如何找到这个服务本身所依赖的其他的服务。客户端服务发现，服务端服务发现。api gateway的方式（见ppt）。(不要总局限于etcd的那种watch的方式 提问环节 七牛基于mysql 在api层面进行通知的服务发现方式是怎么做的？有点没理解)

关于过载保护（overload protection）推荐通过apigate的方式 可以添加诸多额外操作

• 保护对象是哪些资源：socket connection ，文件句柄，disk I/O，cpu，memory。
• 限制资源的使用：报警上限应该是limit的 1/2，kill slow request。

拓扑发现与错误恢复（topology discovery & failure recovery）

• 知道集群当前是什么样的，知道服务当前的状态，目的是为了 find root cause of failure。

最后提问环节，关于设置requestid，

Docker 与 Golang

亮哥分享感觉还是主要集中在docker的维度，还有对于生态的分享，以及daocloud的一些实践。容器的监控上方面，因为仅仅是应用运行的载体，因此对于容器的监控，还是特别有必要的。

结合许总的分享，再清晰一下docker的使用场景。

• 在测试环境中使用docker进行测试，听asta讲，apple貌似是这样，之后利用镜像进行持续集成，代码到镜像这段。
• 镜像到服务这段，属于paas层面的的内容了，感觉上，就是基于docker的微服务。还是觉得k8s的pod的概念，对微服务阐述的最好，swarm似乎还是too simple了，关键不是什么调度性能的比较，因为这些代码层面的，只要继续优化，总是可以解决的。
• 这样一分析，有点看好hyper了。。。hyper这个，看起来就像个pod一样，但是提供了比pod更完备的os层面的隔离。但是毕竟还是在初期，看起来用户不怎么多，周边的工具也不是太完善，磊哥是高瞻远瞩啊。

小米商城运维实践

主要是讲MAE在构建过程中的架构，设计理念，以及诸多细节。听完感觉特别NB，其实大厂，往往能把docker为我所用，越是IT大厂，越是能hold住最新过的技术，小公司和国企，在这一块，已经不知道落后了多少个level了。

其实业务需求才是推动技术发展的关键，以小米为例，总不能等到k8s完善了，或者是docker daemon 100%稳定了采用，所以他们有自己的docker版本，所以他们做自己的paas平台，还高逼格的搞了基于raft的高可用框架。所以京东很早就开始使用docker，取得的效益想必也是显而易见。（今天看到京东云的广告了，他们也是分类的paas，这一点有点像七牛的路线，而且由于他们已经自己有了大规模的实践，因此会给人，依赖性很强的感觉，这种还是适合大厂，有大业务驱动，有大量的资金，有大量的人才，阿里和京东相比，在这一块，似乎动作真是落后了好多了）

整个架构还是看ppt吧，细节太了，说下印象深刻的吧，他们在改造和优化方面，做的很不错。比如对于gorouter的改进，feature上面，负载反馈动态调权，性能上，QPS从6k优化到了10w，语言层面的对象重用（各种缓冲和pool各种对象重用），都是一些实实在在的东西，也有一个启发，以后再跟别人讲优化的时候，一定要拿出证据，数据说话。

监控方面有基础监控与自定义监控，这一块也没有太细讲。到时有一些相关的问题：

有个问题，没有办法从容器外面获得容器的网络流量？容器的监控是否应该里外结合？使用traffice controle可不可以呢？？

监控指标的合并应该来怎么操作？

总是感觉，别管人家是否已经有重复的东西，先一点一点做下去，一个一个问题解决，在这个过程中自然可以make some difference。其实从自己论文的角度来看，并不需要一个完备的，能在生产环境中使用的东西，这不是一个人的事情，也不是短期的，论文的目标，论文的目标，应该是验证理论和技术的可行性，总之要是能 突出关键点 。

Grab 关于golang的CI

背景 Grab相当于东南亚的"滴滴打车"，但是又不仅仅限于打车服务，切入点很赞，市场基础很好，同时又大量的现成案例可以参考。公司的核心理念有两个，让东南亚人民的出行更安全，让东南亚人民的出行更便捷。感觉是一个颇有情怀的公司。

grab的分享相当赞，站在了整个架构的维度，从技术的角度，整体描述了一个团队，如何从小团队，到中型团队在CI以及技术选型上的实践，在团队的不同规模的时候，ci的具体流程是怎样的，适用性很高，具体内容参考ppt。

大致浏览下，可以看到，在团队规模小的时候，主要是各种saas服务，规模逐渐变大之后，才会用k8s，spark这些。开来在企业里，目前最好的ci流程，还是jekins，就算k8s这样的github上的大项目，也都是jekins，自动跑测试，这一套流程。

对于测试相关技术的描述也很好

• 一段代码有没有写测试
• 看测试用例，是不是为了测试而写测试
• 测试用例到底通过了没有

测试的时候，也应该是testcase+benchmark的结合，如hongtao所说，要“讲证据”，而不是“only guess”，我觉得先要有一些hyprothesis，之后再用实际的数据和测试经行验证。

此外grab的golang工程师也是相当赞，整理了好多实用的tips，以及好多实际踩过的golang的坑，详细的内容融合在最后的golang tip部分中，我觉得他们的分享很全面，也很符合会议的主题，大家很喜欢show me the code的东西，希望听到一些实用的技巧。

现在想想，那种讲整个架构，然后一个一个小模块那样讲，会使得听的人很累，也不现实，适合点到即止，在讲之前，希望听众获得什么样的信息，而不是说，明确这点很重要，因为不一定所有的听众都是和你领域相关，抛出很对fancy的概念，然后系统内部很细节的一些设计，除了让听众很累之外，反响也不一定很好。

grab的这个分享，回忆起来，条理特别清晰。可以看到一个好的架构师对企业的业务发展的关键。

Go & 与网易对象存储

好多听不懂，但是整体架构上特别完善，毕竟大厂，感觉上服务很完整，整体上像是七牛云存储那样的服务。

预计在8月份的时候要推出公有云服务。

还能记住一点点的有两块，一个是主干网络路径的之间的优化，另一个是tcp和http参数的调优。许多细节的技巧可以补上（可以看出对于tcp细节的掌握，在笔试面试的时候，是多么重要），具体参考ppt中的一些参数细节，这一块自己原来的了解还是太少，特别是对于tcp的整个协议的粒度，理解的很不够细，可以根据ppt中列出的细节再补充完整。

总结

磊哥说的很对，要实习的时候，就要找大厂，增长见识，现在看来确实是很有道理，开阔眼界真的是很重要的啊

golang所有优缺点

这个几乎是所有的讲师都提到的内容，这里尽量做个整理，能有一些深入一点的insights在里面

优点

工程性语言，why? 规定比较多，比如go fmt 或者 某些场景，只能按照某些方式写，比如 if err!=nil{return err} 较少那种语法糖的话，会使得开发者更加关注业务逻辑。

快速上手？

摒弃旧语言之争，因为大家都开始使用了新的语言

并发的模型

chnnel goroutine的模型 与微服务的架构很相似，面向数据流的编程

缺点

不支持泛型（目前这个带来的不好的地方还体会不是太深）

性能问题，gc的优化（其实大家都是泛泛，很少深入，应该再深入看看），

goroutine还是胡有自己的一些stack，2k左右，太多的goroutine还是会影响性能

会议提到的golang tips 汇总

零散点

go build 与 go install:

编译大型项目的时候go build -i 或者 go insall 可以加快编译速度 资源和程序一起发布的包 go-bindata 包管理 godepth以及vendor go package 发布的流程

支持git hub 的go get ？（go get 的时候不能从gitlib中获得？？？） (改源码 vcs 使用代理（go get 仅仅是某种协议）)

关于golang的依赖（使用 vendor 来构建）:：

可以参考 这个 。之前每次用golang弄项目的时候，都是在godepth中的包拷来拷去。之后会把宿主机上的环境弄得乱七八糟的，不过使用go build的时候可以直接指定使用项目本身自带的依赖包来进行build，不过这样的话，就没法进行跳转了，因为依赖的代码找不到。

最近在做python的一些项目，感觉virtualenv的这一套使用起来还是蛮方便的，在一个虚拟的环境中进行依赖的管理，比较方便。

可以看下 这个文章 中关于vendor的使用，主要是vendor的几条机制：

• 使用了vendor之后，import的时候，默认从vendor的路径来寻找源文件。
• 如果vendor之中应用的项目，还有vendor的子目录，那么在引用的时候，引用到的是最长的那个package的路径。

详细的官方文档参考 这里

sync.Pool包

关于锁的使用 保护的是数据而非代码 控制锁的粒度（还是不太理解。。。）

关于pprf

实际在自己的项目中使用pprof不多，更多的是学习而已。 常用的pprof工具是memory和cpu的profile，它们都被集成在了golang的runtime中。 pprof 详细文档 本质上来说，pprof相当于golang的一种apm工具，因为其搜集数据的粒度是语言层面的。

• cpu profile 开启的时候，runtime会每隔10s钟记录一下当前所有运行的goroutine的stack trace的信息，当这些信息被存下来的时候，我们就可以继续分分析代码的cpu耗时。
• 当heap被空间被分配的时候（stack 空间分配的时候，memory profile并不会对其进行追踪记录），memory profiling会记录stack trace，与cpu profiling一样，memory profiling也是基于sample采样的，默认情况下，在1000次分配中，memory profile会进行一次数据采样。
• 因为memory profiling是基于采样的机制，想通过其追踪程序总的内存使用量是难以做到的。
• profiling开启的时候，会占用runtime的时间，一次只开一个profiling工具即可，并且对程序本身的性能也会造成影响。

pprof使用

[相关使用整理一个具体文档 补充具体的使用]

使用命令行的形式 通过在代码中设置代码开启pprof，参考 这个

具体benchmark的使用方式与普通的test类似，只需要通过 -bench参数显示运行次数。

更具体的内容罗列在 这一篇 中，这里就是介绍一些大概情况，之前整理过一个类似的。

promethes/prometheus tsenart/vegeta

没有测试，不谈优化，没有测量，不谈优化，没有证据，不谈优化，

关于gc

gc一直以来就是一个hot topic，golang 是基于garbage collecting类型的语言，这一点是明确不变的，如何提升gc的效率，就成了一个特别需要考虑的问题，关于gc的一些经验，都整理到 这一篇 中。

测试

go metalinter 用于进行所有的golang的格式化检测 golang中没有assert 可以用三方框架 stretchr/testify

实例展示

grab select 时候阻塞的例子 以及 timeout 时候的例子

golang的相关产品

分布式数据库

web 技术

语言本身

容器相关

其他服务端相关开发

其他感想

astaxie 是那种心态很好的人，很年轻，很佩服，人生赢家，apple员工，新晋golang China首席布道师，业余时间都把事情搞的这么好，nb。

hongchaot同学真的是特别nb了，反应超快，自我介绍特nb，我来自三番，用golang写kubernetes，屌屌的感觉。总是自己其实也应该自信点，humble与confidence应该统一起。也没有必要觉得别人特别nb怎样怎样，初来乍到，比自己年轻，nb的人多的是，不光是以前，现在也是，未来也一定会是，首先自己内心里，要客观承认。在自己的小圈圈里，追求更好，但也没有必要太过强求。此外，每个人做的领域都不一样，能在自己的小领域里，把事情所好，有点成就，这样就会自信起来。

自己也应该自信一点，不应该妄自菲薄，问别人问题的时候，切入点要小，但是问题本身要是开放的，比如说，对哪一个哪一个点特变感兴趣，刚开始的时候又不知道怎么问，就可以问，关于这一点，能不能多谈谈，比如关于性能调优，可否再多谈谈，说一些自己遇到的实际的case，不要一下就拿出一个非A即B的问题，这样别人也不好回答。

有匠心，不要有匠气。会场看到不少码农，有的人一看，就匠气十足，呆萌呆萌的，哈哈。但是看看来自google的工程师，或者是astaxie他们，身上就看不到那种所谓的“匠气”，但他们确确实实，都是相关领域的大牛。技术本身，是客观的，所有的东西，归根到底，还是一个“人”字，人不能被技术本身所束缚住。

应为能力哎，虽然E文一直折腾了不少，但是国外工程师分享的时候，还是不知所云。其实渐渐发现，在日常交流的时候，listening 体现的比speaking 更为重要。因为speaking总是可以用各种各样的方式表述，marvelous不会说，总会说个very good。别人也就明白了，但是如果想要继续put forward话题，一定要get到别人的idea，语音的辨识度，是一个问题，对于语音本来的处理，也是一个问题，词汇，短语，context，语音语调，信息转述，还是练得不够哎。

讲话与表达的逻辑性，与条理性，跟别人说之前，先明确好，自己想要表达什么idea，因为太多的说“看具体情况”这种话，被bs了好几次，之前跟老师汇报，也有这样的毛病，归根到底，还是个条理性的问题。要是一个问题不是很清楚的话，先不要轻易模糊表达，这样思想如果是模糊的话，阐述出来的语言也是不准确的，经不起别人的二次追问，idea表述，本身要逻辑上完备，内容的丰富程度，要至少能够满足逻辑上完备这种需求。已经有好几次讲话的时候，自己都不知道自己想要说什么了，以后多注意吧。

要明白，自己应该特别concern的问题是什么：大家都基于golang做分布式数据库，各种key-value数据库有多个，etcd，influxdb… 支撑它们的raft只有一个，cap理论只有一个。分布式系统有多个，而整个系统需要考虑的问题，按照刘老师的说法，也就是split，scale，merge，数据路由，rebalance，transection这几块。docker 这些东西，再绕也绕不过cgroup，namespace，讨论的内容，也都是filesystem，network，storage这几块。

还是不够积极主动，比如该加的wechat还是应该加上的。。。脸皮厚一点嘛，反正是为了学习提升，有啥可不好意思的呢。

最近又在yy了，get到好多创意的电子，但是我发现了这些电子的一些共同的规律，就是都需要一个庞大的信息库作为支撑。所以我决定把爬虫相关技术好好再实践一番，最起码说明自己做的事，是在一个正确的方向上吧。

产品策略，from inside to outside 所谓情怀。以视频以及grab为例。

其他

LRU cache 什么鬼。。。 golang 协程安全？？？