神刀安全网

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%具体指什么,又是从哪里来的)。所以他们撕起来,特别好看,问题自然也就越辩越明了,大致梳理下:

golang适合于工程,效率上,多数场景也还ok,但相比rust,还是不够高效,特别是在数据库这种底层服务上。golang更多的是由google公司内部的人维护的,不会太concern社区的意见,而rust相反。而在golang的维护者们看来,太多的contern别人的意见,会使自己更臃肿,甚至lost themself,事实也确实如此。感觉怎么balance,找到一个很好的平衡点,特别关键。

其实正常会看来,这确实不是一个需要太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 协程安全???

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » Gopher China 2016 见闻

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址