注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

snoopyxdy的博客

https://github.com/DoubleSpout

 
 
 

日志

 
 

转载——第三届 GopherChina 大会  

2017-05-01 14:21:19|  分类: 网络分享 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

转载地址:http://fuxiaohei.me/2017/4/22/gopherchina-2017.html

上周末参加 GopherChina 第三届大会,感受不错。经过三年时间,Go 的发展非常火爆。会议规模从原来的几百人到上千人,还有很多站在座位两侧听的朋友。大会的内容也是从 Go 本身,到架构,到容器等相关领域都有涉及,可以说干货不错。办大会大会是一件辛苦事,非常感谢 Astaxie 一直以来的努力。讲好一个主题,也会需要很多技巧的,也非常感谢参与大会的各个讲师。言归正传,来聊聊大会的内容。

语言上 的 Go

每种语言都有自己的特色,Go 也不例外。学习 Go 的时候,难免会带入别的语言经验,造成一定的麻烦。因此从 Go 的方式来理解 Go,是 Go 语言开发者必须经历的过程。Tony Bai 从 Go 语言的角度,分享了 Go 的思维模式。

de  >Go is about orthogonal composition of simple concepts with preference in concurrency.
Go 是在偏好并发的环境下的简单概念/事物的正交组合
de>

从这句话就可以总结出几个 Go 开发的原则:

  • 事物的简单化,逻辑单元不要太大;不是一个函数从头到尾,是多个小函数组合起来的大函数
  • 正交组合,逻辑单元之间的无关性;因为函数之间的无关性,才可以复用,也才可以并发
  • 并发背景的需要,即业务是可以同时的,不是线性的

这一些原则还是需要很多的开发技巧来实现的,比如接口的垂直组合,如:

de  >
type ReadWriter interface {
    Reader // 这里体现了逻辑单元的简单化
    Writer
}

de>

根据接口来更适配的接受逻辑水平扩展:

de  >
func ReadAll(r io.Reader) ([]byte, error)
// 可以支持文件流,网络数据流等
ReadAll(*os.File)
ReadAll(*http.Response.Body)

de>

最后我比较感兴趣的就是 de >errorde> 处理的内敛,比如:

de  >
// *bufio.Writer
func (b *Writer) Write(p []byte) (nn int, err error) {
    if b.err != nil {
        return nn, b.err  // 错误在结构内部
    }
    ... ...
}

// usage
buf := bufio.NewWriter(fd)
buf.WriteString("hello, ") // 这样就不需要每行 if err != nil
buf.WriteString("gopherchina ")
buf.WriteString("2017")
if err := buf.Flush() ; err != nil {
    return err
}

de>

上面提到接口的垂直扩展,francesc 的分享就更深入的聊了 Go 中 de >interface{}de> 的使用技巧。de >interface{}de> 我的理解有两个意思。当 de >interface{}de> 带有方法的时候,是行为的定义,如:

de  >
type Reader interface{
    Read(data []byte)(n int,err error) // 注意定义的时候写一下变量名,否则不是啥意思
}

de>

这样的接口就可以弥补 Go 没有泛型的不足。泛型的时候返回如 de ><List,Map>de> 其实是不对的,真正的意义很可能是 de ><Iterator>de>。在 Go 的编程中就逼迫你需要这样的思维来理解,找出需要泛型的时候数据类型的共通之处,执行相同的操作(如果就是不同的行为,写俩函数不是更好?)。

de >interface{}de> 另一个特殊场景就是空接口,对应的代码就是需要类型推断:

de  >func do(v interface{}){
    switch t := v.(type){
        case int:
            fmt.Printf("int - %d",t)
        case error:
            fmt.Printf("error - %s",t.Error())
        default:
            fmt.Printf("interface - %v",t)
    }
}
de>

不到万不得已不要这么写代码。否则需要推断类型的 case 越来越多,代码可维护性瞬间下降。


ezbuy 的分享有很多微服务相关的内容,选型 gRPC 的使用,context tracing 等问题。不过我最在意的是他们的开发环境搭建工具 de >Goflowde>。Go 的包管理机制一直为人所诟病。就算 de >vendorde> 解决了一些第三方包依赖的问题,但是非常的粗糙和直接。同时项目管理时 GOPATH 中既有第三方库,又有自己的项目代码,也给工程实践造成麻烦。Goflow 从分享中看很像 gb + package registry。Goflow 修改系统变量 GOPATH 到当前目录,再从内网 registry 下载第三方包到 vendor 目录。真的非常方便,是个不错的解决方案。而且国内网络访问很多包资源不是很顺畅,内网有 registry 提供很大的便利。这一套东西在公司内部使用我觉得非常棒。

另外他是唯一提及用 de >internalde> 包的分享。例如代码结构:

de  >--product
  |
  |---internal
  |   |
  |   |---product_get.go
  |   |---product_search.go
  |   |
  |---product.go
de>

代码和功能更加清晰明确。回头我也尝试一下这样的使用技巧。

架构上 的 Go

Go 的使用场景中,很多是大规模的并发服务。并发服务的承受能力,不仅是 Go 一种语言的事情,而且与整体的架构设计密不可分。很多的讲师从架构的层面,来谈 Go 在整体中的角色和相关的使用。

七牛的讲师分享了 Go 在他们的大数据分析系统 Pandora 中很小一块的应用。大数据分析的系统,简单的想象也会有数据采集、数据处理、数据分析和分析结果落地这些过程。这次分享是分析数据结果落地的组件的细节。再来联想,落地会有什么问题:数据丢失、数据传输延迟、多种下游输出方式,如何多实例分布式等。整个分享聊到了几乎所有分布式架构都会用到的手段:

  • 数据进入内存队列,内存队列可能 dump 到磁盘队列
  • 数据的事务化,保证进出;进入失败重播,流出确保正确处理
  • 程序关机重启等特殊状态的数据离线
  • 多实例之间的平衡算法

整体听下来,都是比较常规的操作。动用一般手段,加上合理的架构设计,就可以承载大量的服务,这就足够了。(不要瞎折腾)


TiDB 的讲师分享谈数据库实现本身的内容较多。因为 TiDB 是个分布式数据库,可以想象,一个查询请求来到,经过查询优化之后,具体的查询运算任务实际执行的过程,需要去询问 meta 数据源表结构、索引结构等信息,然后去具体的 TiKV 实例进行数据检索。很有可能一次查询需要从很多 TiKV 实例获取数据,显然是 并发 的逻辑,Go 是非常适合的。

我比较有兴趣的是,TiKV 是支持一些简单查询运算的。就是查询任务的某些细节可以下方到 TiKV,如 LIMIT 10 。TiKV 就可以聪明的返回有限数量的结果,在 SQL 层进行聚合。否则各个 TiKV 来一大波数据在 SQL 层聚合,太浪费了。


消息队列是 Go 很常见的应用场景,有赞 为大家分享 NSQ 消息队列的改造之路。整个分享里听到了几个有意思的点:

  • 数据队列的读取方式是游标,在整段上一部分一部分的挪。( NSQ 的数据队列有内存和文件队列,消费不过来写文件了)
  • 因为是游标,就可以并发的读队列。多个游标在同一条队列上读取数据,似乎维护起来复杂度比较高。另一个角度让我想起 de >ringbufferde>
  • 并发读队列,也是 channel 的常见模型,1 producer -> n consumer
  • 队列太多计时器太多,使用 time channel 来统一管理。其实就是 时间轮 吧???

微服务是比较热门的议题。很久以前分布式架构就有模块划分。随着 docker 的兴起,模块的维度太大,更小的业务单元 + docker 容器化,形成的集群成为现在微服务一种流行的实现方式。微服务化之后,业务流程就打散在各种微服务之间。我们需要跟踪和同级数据在各个微服务中的运行状态,trace 成为非常重要的议题,Bilibili 的 毛剑 的分享很大一部分就在聊 B 站在服务化过程中,数据 trace 的方式。

因为业务的多样性,绝大多数的 trace 都是侵入式的。最开始毛剑是在 Go 的标准库 de >net/rpcde> 上添加 tracing 的 context,同时利用标准库 de >context.Contextde> 还可以控制数据流。context 可以针对 rpc 做很多微服务必须的事情。 如 de >context.WithTimeout()de> 控制微服务请求的超时,de >context.Value()de> 寄存很多链接、用户、操作的相关数据,用于鉴权、过滤和统计等。再如负载均衡中,客户端请求中 context 记录服务端请求权重,自动做到均衡的发送数据到压力小的服务端。(这里也可以想见服务端是无状态的)

聊到之后毛剑用的都是成熟的工具,消息队列 kafka,缓存 redis + 修改的 twemproxy,分布式跟踪 google dapper ,存储 Hbase 和 ES 等。合理的架构设计 + 成熟的工具就可以承受大规模的业务。和七牛的分享给我的经验是类似的。最后还有一点好玩的,B 站最早的代码是基于 DedeCMS 魔改的,全部代码揉在一起,几乎无法控制,哈哈哈哈!


第二天 Grab 的高超谈到 Go 在 Grab 的应用也说到微服务下 context tracing 的使用,定位问题。分享中更引人注意的是代码项目管理的过程。Grab 将代码放在一个 git repository 中,按照团队命名空间规范目录结构。这样简单的做到了职责区分,也做到了代码对加大的透明化。或许说,如果要进行大规模的修改,各个团队之间可以通过代码更容易的讨论和重构。另外,极致的代码复用,和简单的依赖管理,统一的版本更新,也带来了项目整体稳定性。这些都是好处,但是一个项目大家同时更新代码,肯定会有冲突的情况。之后 code test 和 review 的自动化过程,为这个问题提供了解决方案。

代码协作工具 Phabricator 为 code review 提供的极大的便利,自动进行代码格式规范化,单元测试和覆盖率检测。这样冲突的代码会造成单元测试的失败,代码覆盖率下降等问题,通过 slack 等立即提示到开发者。即使代码冲突,也可以立刻跟进修改。况且代码库是透明的,对方修改什么内容你可以去阅读,参照之后修改自己的内容。一套自动化测试的工具搭建下来,大仓库 对 Grab 而言利大于弊。


360 分享 poseidon 搜索平台的技术细节中有很多可以参考的信息。从旧的 C++ 过度到 Go 的过程中使用 cgo,带来很多麻烦,最终选择用 Go 完全重写旧的代码。可见,cgo 在很多情况下是吃力不讨好的,谨慎选择。另外对于跨 goroutine 的 panic 捕获的问题,他将 error 内嵌到数据结构内,和上文提到的处理模式一样。那么在运算数据的 goroutine 就可以进行 panic-recover 将错误打入数据中。处理数据运算结果的 goroutine 就可以通过 Data.Error 来获取这次数据运算是否是出现了错误。360 说他们的处理量是日均 100 万亿条,比较想知道是多少台机器撑起的业务。

容器里 的 Go

Go 的一大明星应用就是 de >dockerde>。docker 几乎相关的所有内容都是 Go 语言开发的,比如 Docker Hub, Kubernetes , etcd 等。我日常使用 Docker 也就是本机多个开发环境的切换。对于大数量的容器编排和日常维护还是没啥概念的。听着 Docker 的分享更多死在涨姿势。

邓洪超 介绍的 Kubernetes Operator 让我眼前一亮。Kubernetes Operator 是为了解决有状态的服务容器化的问题。比如 etcd 动态配置各个节点的位置等。Kubernetes Operator 就负责在一个统一的地方监听配置等状态信息的变化,根据变化启动和停止容器,使整个容器群的状态和定义的一样。他现场演示修改 Kubernetes Operator 配置中容器内服务的版本号,容器群的数量等信息,Kubernetes 自动启动和关闭容器,满足配置的要求。看到这些,觉得智能化运维的进步,尤其配套服务比如编排等越来越趋向自动化和智能化,可喜可贺。


华为 马道长 分享的是 DevOps 的升级版 de >ContainerOpsde>。 大公司的开发业务内容很多很复杂。如果按照一般的 DevOps 搭建环境,安装各种需要的配套设施,再搭建当前业务开发以来的别的业务模块,还需要开发测试运维一条龙,非常复杂咯。docker 帮助解决搭建环境和安装基础设施的问题。在 docker 中开发测试和 vm 中是一样的。那问题就在搭建依赖的别的业务模块这个问题上。按我的理解 de >ContainerOpsde> 中的 de >Componentde> 就是来解决这个问题。你要开发某项业务过程,就定义一种 Component,业务输入到业务输出。Component 中就使用 k8s 从 registry 拉起需要的别的业务模块的 docker 镜像,在内部形成完整的业务流。然后人员在这个业务流上开发和测试。这个对于大公司的开发,相对于 DevOps 是简化了很多。同时为了构建一系列的 docker 镜像,业务本身的模块拆分或者说微服务化,也为以后的日常维护、部署和扩展节省了很多事情。

另外,马道长的 ppt 还是比较好理解的,从图中的流程就很好知道基于 ContainerOps 的工作流是如何运行的。


VMWare 对于 Harbor 的介绍是很全面的。从 Harbor 解决的 docker 镜像分发问题的需求分析,到具体实现遇到的一些问题都有提及。我比较在意的是他代码中的 worker pool 和 状态机 state。我隐约记得上次为了回答 QQ 群中小伙伴的提问,去翻了 Harbor 的 worker pool 的代码,发现很像 Handling 1 Million Requests per Minute with Go 文章中的设计。这样看来,worker pool 的 pattern 大家的想法都是差不多了哈哈。

极限 的 Go

Dave Cheney 分享的 Go 的 de >#Pragmade> 满满的黑科技。编译器指令一直是非常让人困惑的东西。除非非常了解编译器本身实现,否则很容易闹出无法收拾的事情。de >go://nosqlitde> 和 de >go://noinlinede> 是比较容易理解的编译器操作指令。goroutine 的连续栈模型带来的是否 split 的问题,而新的 SSA 后端编译也带来是否要被 inline 的问题。我对于 Go 本身实现的理解并不深,大概只能有这样的影响。具体的内容还需要我继续深入的研究。

de >#Pragmade> 听听就好,千万别用


广发证券的分享非常有意思。证券业务高频交易的要求:超低延迟、超高并发、超高可靠性和超严格监管。无论是什么语言开发都面临巨大的挑战。Go 面临这些问题时我们需要如何应对,很有参考意义。

首先面临的问题是 GC 停顿。Go 1.8 已经把 GC STW 时间压缩到 < 100 μs,可以说已经解决的很多问题。不过从代码的角度,还是可以做很多事情降低 GC 的消耗。一个是 goroutine 池。这一点在 fasthttp 的使用得到的印证,效率是标准库的几倍,而内存和 GC 和标准库差别不大。另外是可以控制数量的对象池。Go 标准库的 de >sync.Poolde> 太过粗放,有些情形下非常需要自己写一个对象池来做精细的控制。还有一点就是变量逃逸的问题。如果变量逃逸到 heap 上,就会影响 GC 的性能(需要扫描变量)。因此需要使用学习一些代码技巧,避免逃逸到堆上的情形。

还提到多级 Map 的优化。大 Map 是非常影响 GC 性能的。应对策略就是大而化小,比如多个小 Map 降低扫描的时间 (Go 的 GC Mark-Sweep 中的 Mark 是并发的)。另外访问 Map 是需要加锁保证并发安全。大 Map 的锁粒度太大,好像一个仓库只有一个门,人进去关门就不能再进去,直到里面的人出来。非常影响并发的操作。Map 大而化小后,相当于有多个门了。而且多级 Hash 分散后的 Map,粒度很小,门很多。即使 goroutine 数量巨大,门多了之后,同时访问一个门的情况明显减少。即读取数据的过程几乎不会遇到锁竞争的问题。

另外还分享了网卡的 offload 的问题,利用硬件分片将小包组成大包发送。

题外话

这次的 GopherChina 内容满满,从 Go 语言层面,到代码技巧,架构设计,以及容器应用都有涉及。不过,内容过多,不是什么领域大家都有兴趣。还是希望在 Go 语言本身和代码编程方面有更多的内容。从需求分析到架构设计,都是代码编写的前奏。为了应付设计,我的 Go 程序变成什么模样。为了实现功能,我的 Go 程序提供哪些功能。希望有更多的讲师可以从架构层面落到代码的层面。架构设计的原则和工具手段都是类似的,但是各家公司的业务不同,最终形成的架构模型是千差万别的。Go 作为架构中的一份子,想让会为这个架构做适应的设计。而这种设计,更能启发开发者如何更好地使用 Go 这门语言。


GopherChina 历届大会的分享内容:

https://github.com/gopherchina/conference

  评论这张
 
阅读(134)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017