Quantcast
Channel: Tony Bai
Viewing all 560 articles
Browse latest View live

构建Kubernetes集群 –选择工作节点大小

$
0
0

近期learnk8s网站上发布了一些关于k8s的好文章,这里搬运并翻译了一些,供大家参考。

本文翻译自《Architecting Kubernetes clusters — choosing a worker node size》

img{512x368}

当您创建Kubernetes集群时,冒出的第一个问题之一是:“我应该使用哪种类型的工作节点以及需要多少个这样的节点”。

如果您正在构建在内部部署的k8s集群,是应该订购一些最近一代的新服务器,还是使用数据中心内的十几台旧机器?

或者,如果您使用Google Kubernetes Engine(GKE)等托管Kubernetes服务,您是否应该使用八个n1-standard-1或两个n1-standard-4实例来实现所需的计算能力呢?

集群容量

通常,Kubernetes集群可以被视为将一组单个节点抽象为一个大的“超级节点”。

该超级节点的总计算容量(就CPU和内存而言)是所有组成节点容量的总和。

有多种方法可以实现集群的所需目标容量。

例如,假设您需要一个总容量为8个CPU内核和32 GB RAM的集群。

例如,因为要在集群上运行的应用程序集需要如此数量的资源。

以下是设计集群的两种可能方法:

img{512x368}

这两个选项都会产生具有相同容量的集群 – 但左侧选项使用4个较小的节点,而右侧选项使用2个较大的节点。

哪个更好?

为了解决这个问题,让我们来看看“少数大节点”和“许多小节点”这两个相反方向思路的优缺点。

请注意,本文中的“节点”始终指的是工作节点(worker node)。master节点的数量和大小的选择是完全不同的话题。

使用少量大节点

这方面最极端的情况是仅使用一个可以提供整个所需集群容量的工作节点。

如果要满足上面的示例中容量的需求,这将是一个具有16个CPU内核和16 GB RAM的单个工作节点。

让我们来看看这种方法可能具有的优势。

1. 减少管理成本

简单地说,管理少量机器比管理大量机器要更省力。

更新和补丁可以更快地应用,机器可以更容易保持同步。

此外,对于机器数量少而言,预期故障的绝对数量要小于机器数量多的情况。

但请注意,这主要适用于裸机服务器而不适用于云实例。

如果您使用云实例(作为托管Kubernetes服务的一部分或您在云基础架构上安装的Kubernetes),则将底层机器的管理外包给云提供商。

因此,管理云中的10个节点并不比管理云中的单个节点成本多得多。

2. 每个节点的成本更低

虽然更强大的机器比低端机器更昂贵,但价格上涨不一定是线性的。

换句话说,具有10个CPU内核和10 GB RAM的单台机器可能比具有1个CPU内核和1 GB RAM的10台机器便宜。

但请注意,如果您使用云实例,这可能同样不适用。

在主要云提供商Amazon Web Services,Google Cloud Platform和Microsoft Azure的当前定价方案中,实例价格是随容量线性增加的。

例如,在Google Cloud Platform上,64个n1-standard-1实例的成本与单个n1-standard-64实例完全相同- 两个选项都为您提供64个CPU内核和240 GB内存。

因此,在云中,您通常无法通过使用更大的机器来节省成本。

3. 允许运行资源消耗较大的应用程序

拥有大型节点可能只是您要在集群中运行一类应用程序的要求。

例如,如果您有一台需要8 GB内存的机器学习应用程序,你无法在仅具有1 GB内存的节点的集群上运行它。

但是,您可以在具有10 GB内存节点的群集上运行它。

看过优势后,让我们再来看看其弊端又是什么。

1. 每个节点有大量的pod

在较少的节点上运行相同的工作负载自然意味着在每个节点上运行更多的pod。

这可能成为一个问题。

原因是每个pod都会在节点上运行的Kubernetes代理上引入一些开销 – 例如容器运行时(例如Docker),kubelet和cAdvisor。

例如,kubelet对节点上的每个容器执行常规活动和就绪探测 – 更多容器意味着在每次迭代中kubelet需要做更多的工作。

cAdvisor收集节点上所有容器的资源使用统计信息,并且kubelet定期查询此信息并通过其API发布它 – 再次,这意味着每次迭代中cAdvisor和kubelet的工作量都会增加。

如果pod的数量变大,这些东西可能会开始减慢系统速度,甚至使系统变得不可靠。

img{512x368}

issue称节点因常规的kubelet运行状况检查花费了太长时间来迭代节点上的所有容器而导致节点处于非就绪状态。

出于这些原因,Kubernetes 建议每个节点最多110个pod

针对这个数字,Kubernetes已经做过测试,结果证明是可以在通常节点类型上可靠地工作的。

根据节点的性能,您可能能够成功地为每个节点运行更多的pod – 但这依然很难预测事情是否会顺利运行,又或您将遇到问题。

大多数托管Kubernetes服务甚至对每个节点的pod数量施加了严格的限制:

  • 在Amazon Elastic Kubernetes Service(EKS)上,每个节点的最大pod数取决于节点类型,范围从4到737。
  • 在Google Kubernetes Engine(GKE)上,无论节点类型如何,每个节点的限制为100个pod。
  • 在Azure Kubernetes服务(AKS)上,默认限制是每个节点30个pod,但最多可以增加到250个。

因此,如果您计划为每个节点运行大量pod,则应该事先测试事情是否能按预期工作。

2. 有限的复制

少量节点可能会限制应用程序的有效复制程度。

例如,如果您有一个由5个副本组成的高可用性应用程序,但您只有2个节点,那么应用程序的有效复制程度将减少到2。

这是因为5个副本只能分布在2个节点上,如果其中一个失败,它可能会同时删除多个副本。

另一方面,如果您有至少5个节点,则理想情况下每个副本可以在单独的节点上运行,并且单个节点的故障最多只会删除一个副本。

因此,如果您具有高可用性要求,则可能需要对集群中的最小节点数提出要求。

3. 更大的爆破半径

如果您只有几个节点,那么失败节点的影响比您有许多节点的影响要大。

例如,如果您只有两个节点,并且其中一个节点出现故障,那么大约一半的节点会消失。

Kubernetes可以将失败节点的工作负载重新安排到其他节点。

但是,如果您只有几个节点,则风险更高,因为剩余节点上没有足够的备用容量来容纳故障节点的所有工作负载。

结果是,部分应用程序将永久停机,直到再次启动故障节点。

因此,如果您想减少硬件故障的影响,您可能希望选择更多的节点。

4. 大比例增量

Kubernetes 为云基础架构提供了一个Cluster Autoscaler,允许根据当前需求自动添加或删除节点。

如果使用大型节点,则会有大的缩放增量,这会使缩放更加笨重。

例如,如果您只有2个节点,则添加其他节点意味着将群集容量增加50%。

这可能比您实际需要的多得多,这意味着您需要为未使用的资源付费。

因此,如果您计划使用集群自动缩放,则较小的节点允许更流畅且经济高效的缩放行为。

在讨论了使用”很少几个大节点”的方案的优缺点之后,让我们转向”许多小节点”的场景。

使用大量小节点

这种方法包括从许多小节点而不是几个大节点中形成集群。

这种方法的优点和缺点是什么?

使用许多小节点的优点主要对应于使用少量大节点的缺点。

1. 较小的爆破半径

如果您有更多节点,则每个节点上的pod自然会更少。

例如,如果您有100个pod和10个节点,则每个节点平均只包含10个pod。

因此,如果其中一个节点发生故障,则影响仅限于总工作负载的较小比例。

有可能只有一些应用程序受到影响,并且可能只有少量副本,因此整个应用程序都会保持运行状态。

此外,剩余节点上的备用资源很可能足以容纳故障节点的工作负载,因此Kubernetes可以重新安排所有pod,并且您的应用程序可以相对快速地返回到完全正常运行的状态。

2. 允许高可复制性

如果您有高可用性需求的应用程序和足够的可用节点,Kubernetes调度程序可以将每个副本分配给不同的节点。

您可以通过节点亲缘关系pod亲和力/反亲和力以及taint和tolerations来影响调度程序对pod放置位置的选择。

这意味着如果某个节点出现故障,则最多只有一个副本受影响且您的应用程序仍然可用。

看到使用许多小节点的优点,那它有什么缺点呢?

1. 节点数量大

如果使用容量较小的节点,则自然需要更多节点来实现给定的集群容量。

但是大量节点对Kubernetes控制平面来说可能是一个挑战。

例如,每个节点都需要能够与每个其他节点通信,这使得可能的通信路径数量以节点数量的平方的量级增长 – 所有节点都必须由控制平面管理。

Kubernetes控制器管理器中的节点控制器定期遍历集群中的所有节点以运行运行状况检查 – 更多节点意味着节点控制器的负载更多。

更多节点意味着etcd数据库上的负载也更多 – 每个kubelet和kube-proxy都会导致etcd的观察者(watch)客户端(通过API服务器),etcd必须广播对象更新。

通常,每个工作节点都会给主节点上的系统组件增加一些开销。

img{512x368}

据官方统计,Kubernetes声称支持最多5000个节点的集群

然而,在实践中,500个节点可能已经构成了较大的挑战

通过使用性能更高的主节点,可以减轻大量工作节点的影响。

这就是在实践中所做的 – 这里是kube-up在云基础架构上使用的主节点大小

  • Google云端平台
    • 5个工作节点→ n1-standard-1主节点
    • 500个工作节点→ n1-standard-32主节点
  • 亚马逊网络服务
    • 5个工作节点→ m3.medium主节点
    • 500个工作节点→ c4.8xlarge主节点

如您所见,对于500个工作节点,使用的主节点分别具有32和36个CPU核心以及120 GB和60 GB内存。

这些都是相当大的机器!

因此,如果您打算使用大量小节点,则需要记住两件事:

  • 您拥有的工作节点越多,您需要的性能就越高
  • 如果您计划使用超过500个节点,则可能会遇到一些需要付出一些努力才能解决的性能瓶颈

Virtual Kubelet这样的新项目允许绕过这些限制,并允许具有大量工作节点的集群。

2. 更多系统开销

Kubernetes在每个工作节点上运行一组系统守护进程 – 包括容器运行时(例如Docker),kube-proxy和包含cAdvisor的kubelet。

cAdvisor包含在kubelet二进制文件中。

所有这些守护进程一起消耗固定数量的资源。

如果使用许多小节点,则这些系统组件使用的资源部分比例会更大。

例如,假设单个节点的所有系统守护程序一起使用0.1个CPU内核和0.1 GB内存。

如果您拥有10个CPU核心和10 GB内存的单个节点,那么守护程序将占用集群容量的1%。

另一方面,如果您有1个CPU核心和1 GB内存的10个节点,则后台程序将占用集群容量的10%。

因此,在第二种情况下,10%的账单用于运行系统,而在第一种情况下,它只有1%。

因此,如果您希望最大化基础架构支出的回报,那么您可能更喜欢更少的节点。

3. 降低资源利用率

如果您使用较小的节点,那么最终可能会有大量资源片段太小而无法分配给任何工作负载,因此保持未使用状态。

例如,假设您的所有pod都需要0.75 GB的内存。

如果你有10个1 GB内存的节点,那么你可以运行10个这些pod – 你最终会在每个节点上有一块0.25 GB的内存,你不能再使用它了。

这意味着,集群总内存的25%被浪费了。

另一方面,如果您使用具有10 GB内存的单个节点,那么您可以运行13个这样的pod – 而只有0.25 GB的单块内存剩下无法使用。

在这种情况下,您只会浪费2.5%的内存。

因此,如果您想最大限度地减少资源浪费,使用更大的节点可能会提供更好的结果。

4. 小节点上的Pod限制

在某些云基础架构上,小节点上允许的最大pod数量比您预期的要限制得多。

Amazon Elastic Kubernetes Service(EKS)就是这种情况,其中每个节点的最大pod数取决于实例类型。

例如,对于一个t2.medium实例,pod的最大数量是17,因为t2.small它是11,而t2.micro它是4。

这些都是非常小的数字!

任何超出这些限制的pod都无法由Kubernetes调度程序安排,这些pod会一直保持在Pending状态。

如果您不了解这些限制,则可能导致难以发现的错误。

因此,如果您计划在Amazon EKS上使用小节点,请检查相应的每节点pods数,并多算几次计算节点是否可以容纳所有pod。

结论

那么,您应该在集群中使用少量大型节点还是许多小型节点?

一如既往,没有明确的答案。

您要部署到集群的应用程序类型可能会指导您的决策。

例如,如果您的应用程序需要10 GB内存,则可能不应使用小节点 – 集群中的节点应至少具有10 GB内存。

或者,如果您的应用程序需要10倍的复制性以实现高可用性,那么您可能不应该只使用2个节点 – 您的集群应该至少有10个节点。

对于中间的所有场景,它取决于您的具体要求。

以上哪项优缺点与您相关?哪个不是?

话虽如此,没有规则规定所有节点必须具有相同的大小。

没有什么能阻止您在集群中使用不同大小节点混合在一起的方案。

Kubernetes集群的工作节点可以是完全异构的。

这可能会让您权衡两种方法的优缺点。

最后,证明布丁好坏就在于吃 – 最好的方法是试验并找到最适合你的组合!


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.


Go语言回顾:从Go 1.0到Go 1.13

$
0
0

Go 1.13版本在2019.9.3正式发布!国外的Gopher Vincent Blanchon发表了一篇文章《Go: Retrospective》(科学上网阅读),对Go从1.0版本到1.13版本做了简要的回顾,这里是那篇文章的译文。

img{512x368}

对于每一位Go开发者来说,Go语言的演化历程是必须要知道的事情。了解这些横跨年份发布的大版本的主要变化将有助于Gopher理解Go语言的发展理念以及该语言每个版本的优势与不足。更多关于特定版本的变更细节,可以参考每个版本对应的Changelog

Go 1.0 – 2012.3月

伴随着Go语言的第一个版本,Go的缔造者还发布了一份兼容性文档。该文档保证未来的Go版本将保持向后兼容性(backward-compatible),即始终兼容已有的代码,保证已有代码在Go新版本下编译和运行的正确性。

Go 1.0版本还包含了go tool pprof命令,这是一个Google pprof C++ profiler的变体。Go 1.0还提供了go vet命令(之前的go tool vet),用于报告Go package中可能的错误。

Go 1.1 – 2013.5月

该版本主要专注于语言改善和性能提升(编译器、垃圾回收、map、goroutine调度)。这里是一个改善后的效果示意图:

img{512x368}
图来自https://dave.cheney.net/2013/05/21/go-11-performance-improvements

这个版本同时还嵌入了一个竞态探测器(race detector),这个工具对于Go这种原生并发的语言是十分必要的。在《Race Detector with ThreadSanitizer”》一文中,你可以找到有关race detector的更多详细信息。

在这个版本中的一个重点变动是Goroutine调度器被重写了,重写后的调度器性能大幅提升。

重写后的Go调度器的设计如下图:

img{512x368}
图来自 https://rakyll.org/scheduler/

M对应的是操作系统的线程。P表示一个处理器(P的数量不能超过GOMAXPROCS),每个P拥有一个本地goroutine队列。在1.1版本之前,P这个抽象并不存在。所有goroutine的调度通过全局互斥锁进行全局级别的管理。这次改进实现了”work-stealing”算法,允许某个P从其他P的队列中”偷goroutine”:

img{512x368}
图来自 https://rakyll.org/scheduler/

更多关于Go调度器调度原理以及”work-stealing”算法的信息,可以查看Jaana B. Dogan的文章《Go’s work-stealing scheduler》

Go 1.2 – 2013.12

在该版本中,Go test命令开始支持代码测试覆盖率统计了,并且通过go提供的新子命令: go tool cover可以查看代码测试覆盖率统计信息:

img{512x368}
图来自 https://blog.golang.org/cover

它还能提供代码覆盖信息:

img{512x368}
图来自 https://blog.golang.org/cover

Go 1.3 – 2014.6

该版本包含了栈管理的一个重要改进。在该版本中,栈内存分配采用连续段(contiguous segment)的分配模式以提升内存分配效率。这将为下一个版本将栈size降到2KB奠定基础。之前的分割栈分配方式(segment stack)存在频繁分配/释放栈段导致栈内存分配性能不稳定(较低)的问题,引入新机制后,分配稳定性和性能都有较大改善。

这里是一个json包的例子,图中显示json包对栈size的敏感度:

img{512x368}
图来自 contiguous stack

使用连续段的栈内存分配管理模式解决了一些程序性能低下的问题。下面是html/template包的性能对stack size的敏感度图:

img{512x368}

更多信息可参见[《How Does the Goroutine Stack Size Evolve?”》(https://medium.com/@blanchon.vincent/go-how-does-the-goroutine-stack-size-evolve-447fc02085e5)]。

这个版本还发布了sync.Pool。这个组件允许我们后面重用结构体,减少内存分配的次数。它也将成为Go生态圈中许多性能提升的源头,比如:标准库中的encoding/json、net/http或是Go社区中的zap等。

关于sync.Pool的更多信息,可以参考文章《Understand the Design of Sync.Pool》

Go开发组在该版本中对channel进行了优化改善,使其性能获得提升。下面是channel在Go 1.2和Go 1.3版本中的基准测试数据对比:

img{512x368}

Go 1.4 – 2014.12

在该版本中,Go提供了对Android的官方支持。使用golang.org/x/mobile包,gopher们可以使用Go编写简单的Android应用。

同时,之前版本中大量用C语言和汇编语言实现的运行时已经被翻译为Go,一个更为精确的垃圾回收器让堆内存分配减少了10~30%。

和版本自身无关的是,Go工程在本次发布后已经从Mercurial迁移到Git,从Google code迁移到github。

Go还发布了go generate命令,该命令可以通过扫码代码中的//go:generate指示器来生成代码,可以帮助Gopher简化代码生成工作。

更多关于这方面的信息可以参考Go blog和这篇文章《Generating code》

Go 1.5 – 2015.8

这个新版本推迟了两个月发布,目的是适应Go新的开发发布周期:每年二月和八月进行发布:

img{512x368}
图来自:https://github.com/golang/go/wiki/Go-Release-Cycle

在该版本中,垃圾回收器全面重构。由于引入并发回收器,回收阶段带来的延迟大幅减少。下面是来自一个生产环境服务器上的延迟数据,我们看到延迟从300ms降到了30ms:

img{512x368}
图片来自 https://blog.golang.org/ismmkeynote

这个版本还发布go tool trace命令,通过该命令我们可以实现执行器的跟踪(trace)。这些跟踪是在test执行、运行时生成的,跟踪信息可以通过浏览器呈现:

img{512x368}
图片来自原始Go Execution Tracer文档

Go 1.6 – 2016.2

这个版本的最显著变化是当使用HTTPS时,将默认支持HTTP/2。

垃圾回收器的延迟在该版本中进一步降低:

img{512x368}
图片来自https://blog.golang.org/ismmkeynote

Go 1.7 – 2016.8

这个版本发布了context包。该包用于处理timeout和取消任务。

更多关于context包的信息,可参考文章:《Context and Cancellation by Propagation》

编译器工具链的性能得到了较大幅度优化,编译速度更快,二进制文件size更小,有些时候幅度可达20~30%。

Go 1.8 – 2017.2

垃圾回收器的延迟在该版本中进一步改善,延迟时间已经全面降到毫秒级别以下:

img{512x368}
图片来自https://blog.golang.org/ismmkeynote

对延迟的优化还将继续。接下来版本的目标是将延迟降到100微秒左右。

这个版本还大幅提升了defer的性能:

img{512x368}
图片来自 https://medium.com/@blanchon.vincent/go-how-does-defer-statement-work-1a9492689b6e

更多关于defer的信息,可以参考文章How Does Defer statement Work?

Go 1.9 – 2017.8

该版本引入了alias语法。

type byte = uint8

这里byte是unit8的一个alias。

sync包增加了Map类型,该类型支持并发访问(原生map类型不支持)。

关于map的更多信息,参考文章“Concurrency Access with Maps”

Go 1.10 – 2018.2

在该版本中,test包引入了一个新的缓存机制,所有通过测试的结果都将被缓存下来。当test没有变化时,重复执行test会节省大量运行test的时间。

first run:
ok      /go/src/retro 0.027s
second run:
ok      /go/src/retro (cached)

go build命令也维护了一个已构建的包的缓存以加速构建性能。

该版本中垃圾回收器并没有显著性能提升。但是Go team为垃圾回收定义了一个新的SLO(Service-Level Objective):

img{512x368}
图片来自https://blog.golang.org/ismmkeynote

Go 1.11 – 2018.8

Go 1.11引入了一个重要的新功能:Go modules。Go module的引入是为了应对过去几年官方调查问卷结果中Go社区反馈的几个主要挑战:

img{512x368}
图片来自 https://blog.golang.org/survey2018-results

另外一个重要功能是一个试验功能:支持WebAssembly。允许开发人员将Go源码编译成一个兼容四个主流浏览器的二进制格式文件。

Go 1.12 – 2019.2

该版本中,go vet基于analysis包进行了重写,使得go vet更为灵活并支持Go开发人员编写自己的checker。

更多关于analyzer的信息可以参考文章《How to Build Your Own Analyzer》

Go 1.13 – 2019.8

在该版本中,sync.Pool得到了改善:当垃圾回收时,pool中对象不会被完全清理掉。它引入了一个cache,用于在两次GC之前清理pool中未使用的对象实例。

逃逸分析(escape analysis)被重新实现了,在该版本中,Go得意更少地在堆上分配内存了。下面是新旧逃逸分析的基准测试对比:

img{512x368}
图片来自 https://github.com/golang/go/issues/23109


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Go语言包管理简史

$
0
0

img{512x368}

包管理是Go一直被诟病做得不好的功能之一。先前版本(go 1.11之前)的主要缺点之一是go get是缺乏对依赖包版本的管理和对可复制构建(reproducible build)的支持。Go社区已经开发了一些包管理器和工具作为版本化包依赖的事实标准解决方案,如glidedep以及一些辅助工具等。

“我在生产构建中使用go get。” – 没有人这么说过。

Go语言的包管理实现可追溯到Google公司内的代码依赖管理(Google将内部所有源代码都存放在一个巨大的单体存储库中)。我们来分析一下在”Go module”之前Go语言的包管理工具都出了什么问题。

  • 依赖包的版本化
  • 依赖包的本地缓存(vendor)
  • GOPATH的必要性

依赖包的版本化

go get默认情况下不支持包版本控制。go软件包管理的第一版实现背后的想法是-不需要包版本控制,不需要第三方包存储库,您可以从当前分支中构建所有内容。

Go 1.11之前的版本中,添加依赖项意味着将该依赖项的源代码仓库克隆到$GOPATH下面。就是这样,没有版本的概念。版本始终指向克隆时刻的主分支。出现了另一个主要问题是,当不同的项目需要依赖包的不同版本时,Go包管理工具无法实现。

依赖包的本地缓存(vendor)

依赖包本地缓存通常是指相关依赖包与项目存储在同一位置。这通常意味着将您的依赖项源码也提交到源管理系统中,例如Git。

考虑这样一种情况- A使用依赖项B,而B使用了C版本在1.5版本中引入一个功能,这时B必须确保A在构建时使用的也是C 1.5或更高版本。在Go 1.5之前的版本中,没有一种机制可以在不重写导入路径的情况下将依赖包代码与命令绑定在一起。

GOPATH的必要性

GOPATH存在的主要原因有两个:

  1. 在Go中,import声明通过其完全限定的导入路径来引用包。GOPATH存在可以方便Go工具计算GOPATH/src内的任何目录所涉及软件包的绝对导入路径。
  2. 它是Go get命令存储包依赖项的位置。

这有什么问题?

  1. GOPATH 不允许开发人员像其他语言一样选择任意喜欢的目录签出项目的源代码。
  2. 此外,GOPATH不允许开发人员同时检出某个项目(或其依赖项)的多个副本。

Go Module介绍

Go 1.11引入了对Go模块(module)的初步支持。下面摘自Go Wiki:

一个模块是一组相关的Go包的集合,这个包集合被当做一个独立的单元进行统一版本管理。模块精确记录了依赖要求并支持创建可复制的构建。

Go模块带来了三个重要的内置功能:

  1. go.mod文件,它与package.json或Pipfile文件的功能类似。
  2. 机器生成的传递依赖项描述文件 – go.sum。
  3. 不再有GOPATH限制。模块可以位于任何路径中。
$ go help mod
Go mod provides access to operations on modules.

Note that support for modules is built into all the go commands,
not just 'go mod'. For example, day-to-day adding, removing, upgrading,
and downgrading of dependencies should be done using 'go get'.
See 'go help modules' for an overview of module functionality.

Usage:

    go mod <command> [arguments]

The commands are:

    download    download modules to local cache
    edit        edit go.mod from tools or scripts
    graph       print module requirement graph
    init        initialize new module in current directory
    tidy        add missing and remove unused modules
    vendor      make vendored copy of dependencies
    verify      verify dependencies have expected content
    why         explain why packages or modules are needed

Use "go help mod <command>" for more information about a command.

更多相关讨论在这里

迁移到Go Module

要使用Go模块,请更新Go到1.11及以上版本。由于不再需要GOPATH,因此可以通过以下两种方式之一激活模块支持(译注:下面的行为仅适用于Go 1.11~Go 1.12Go 1.13版本默认开启Go module,无论是否在GOPATH下,除非GO111MODULE=off):

  • 在GOPATH/src之外的目录中调用Go命令,并在当前目录中存在一个有效的go.mod文件。
  • 如果源码在GOPATH之下,Go模块将不起作用。要改变此行为,请设置环境变量GO111MODULE=on后再调用Go命令。

让我们通过以下简单的步骤开始迁移:

  • 由于GOPATH不再必要的了,将module移出GOPATH。

  • 在项目根目录中,创建初始模块定义 – go mod init github.com/username/repository。go mod还会自动转换现有的包管理器(如dep和Gopkg,glide以及其他六种)的依赖关系。这将创建一个名为go.mod的文件,该文件存储了模块名以及模块的依赖项及其版本。

$ cat go.mod
module github.com/deepsourcelabs/cli

go 1.12

require (
    github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e
    github.com/getsentry/raven-go v0.2.0
    github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9
)
  • 运行go build会创建一个go.sum文件,其中包含特定模块版本的内容的预期校验和。这是为了确保这些模块将来的下载内容与第一次下载是相同的。请注意,go.sum不是锁文件。
$ cat go.sum
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e h1:9574pc8MX6rF/QyO14SPHhM5KKIOo9fkb/1ifuYMTKU=
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e/go.mod h1:GJKEexRPVJrBSOjoqN5VNOIKJ5Q3RViH6eu3puDRwx4=
github.com/getsentry/raven-go v0.2.0 h1:no+xWJRb5ZI7eE8TWgIq1jLulQiIoLG0IfYxv5JYMGs=
github.com/getsentry/raven-go v0.2.0/go.mod h1:KungGk8q33+aIAZUIVWZDr2OfAEBsO49PX4NzFV5kcQ=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9 h1:dIsTcVF0w9viTLHXUEkDI7cXITMe+M/MRRM2MwisVow=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=

关于版本控制的注意事项:为了保持向后兼容性,如果模块的版本为v2或更高版本,则模板的主版本必须以/vN的形式被包含在go.mod文件中使用的模块路径的末尾。比如:module github.com/username/repository/v2

日常命令

列出依赖项

go list -m all 列出当前模块及其所有依赖项。

$ go list -m all
github.com/deepsourcelabs/cli
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e
github.com/getsentry/raven-go v0.2.0
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9

在go list输出中,当前模块(也称为主模块)始终是第一行,其后是路径排序所有依赖模块。

列出软件包的可用版本

go list -m -versions github.com/username/repository 列出软件包的可用版本。

$ go list -m -versions github.com/getsentry/raven-go
github.com/getsentry/raven-go v0.1.0 v0.1.1 v0.1.2 v0.2.0

添加依赖

添加依赖项是隐式的。在代码中导入依赖项后,运行go build或go test命令将获取模块的最新版本并将其添加到go.mod文件中。如果要显式添加依赖项,请运行go get github.com/username/repository。

依赖项的升级/降级

go get github.com/username/repository@vx.x.x下载并设置依赖项和更新go.mod文件的特定版本。

$ go get github.com/getsentry/raven-go@v0.1.2
go: finding github.com/getsentry/raven-go v0.1.2
go: downloading github.com/getsentry/raven-go v0.1.2
go: extracting github.com/getsentry/raven-go v0.1.2

$ cat go.mod
module github.com/deepsourcelabs/marvin-go

go 1.12

require (
    github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e
    github.com/getsentry/raven-go v0.1.2
    github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9
)

$ cat go.sum
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e h1:9574pc8MX6rF/QyO14SPHhM5KKIOo9fkb/1ifuYMTKU=
github.com/certifi/gocertifi v0.0.0-20190410005359-59a85de7f35e/go.mod h1:GJKEexRPVJrBSOjoqN5VNOIKJ5Q3RViH6eu3puDRwx4=
github.com/getsentry/raven-go v0.1.2 h1:4V0z512S5mZXiBvmW2RbuZBSIY1sEdMNsPjpx2zwtSE=
github.com/getsentry/raven-go v0.1.2/go.mod h1:KungGk8q33+aIAZUIVWZDr2OfAEBsO49PX4NzFV5kcQ=
github.com/getsentry/raven-go v0.2.0 h1:no+xWJRb5ZI7eE8TWgIq1jLulQiIoLG0IfYxv5JYMGs=
github.com/getsentry/raven-go v0.2.0/go.mod h1:KungGk8q33+aIAZUIVWZDr2OfAEBsO49PX4NzFV5kcQ=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9 h1:dIsTcVF0w9viTLHXUEkDI7cXITMe+M/MRRM2MwisVow=
github.com/pkg/errors v0.0.0-20190227000051-27936f6d90f9/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0=

vendor依赖项

使用模块时,go命令将完全忽略vendor目录。为了向后兼容旧版Go,或确保将用于构建的所有文件一起存储在单个文件树中,请运行go mod vendor。

这将在主模块的根目录中创建一个vendor目录,并将依赖模块中的所有软件包存储在该目录中。

注意:要使用主模块的顶级vendor目录进行构建,请运行’go build -mod=vendor’。

删除未使用的依赖项

go mod tidy将删除未使用的依赖项并更新go.mod文件。

常见问题解答

  1. GOPATH不再需要了?
    是,永别了GOPATH。

  2. 默认情况下拉取哪个版本?
    go.mod文件和go命令通常将语义版本用作描述模块版本的标准形式,以便可以比较版本以确定哪个版本应早于或晚于其他版本。v1.2.3通过在基础源存储库中标记(tag)修订来引入类似的模块版本。未标记(untag)的修订版可以使用“伪版本”之类的来引用:v0.0.0-yyyymmddhhmmss-abcdefabcdef,其中时间是UTC的提交时间,最后的后缀是提交哈希的前缀。

  3. go.sum应该被检入到版本库中吗?
    是。

鉴于本人近期较忙,又不希望让博客长草,近一段时间会挑选翻译一些笔者认为比较优秀的外文文章分享给大家。

本文翻译自《Package management in Go – brief overview of package management in Go — pre and post Go modules》


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

如何在Go语言中使用Websockets:最佳工具与行动指南

$
0
0

如今,在不刷新页面的情况下发送消息并获得即时响应在我们看来是理所当然的事情。但是曾几何时,启用实时功能对开发人员来说是一个真正的挑战。开发社区在HTTP长轮询(http long polling)和AJAX上走了很长一段路,但终于还是找到了一种构建真正的实时应用程序的解决方案。

该解决方案以WebSockets的形式出现,这使得在用户浏览器和服务器之间开启一个交互式会话成为可能。WebSocket支持浏览器将消息发送到服务器并接收事件驱动的响应,而不必使用长轮询服务器的方式去获取响应。

就目前而言,WebSockets是构建实时应用程序的首选解决方案,包括在线游戏,即时通讯程序,跟踪应用程序等均在使用这一方案。本文将说明WebSockets的操作方式,并说明我们如何使用Go语言构建WebSocket应用程序。我们还将比较最受欢迎的WebSocket库,以便您可以根据选择出最适合您的那个。

网络套接字(network socket)与WebSocket

在Go中使用WebSockets之前,让我们在网络套接字和WebSockets之间划清一条界限。

网络套接字

网络套接字(或简称为套接字)充当内部端点,用于在同一计算机或同一网络上的不同计算机上运行的应用程序之间交换数据。

套接字是Unix和Windows操作系统的关键部分,它们使开发人员更容易创建支持网络的软件。应用程序开发人员不可以直接在程序中包含套接字,而不是从头开始构建网络连接。由于网络套接字可用于许多不同的网络协议(如HTTP,FTP等),因此可以同时使用多个套接字。

套接字是通过一组函数调用创建和使用的,这些函数调用有时称为套接字的应用程序编程接口(API)。正是由于这些函数调用,套接字可以像常规文件一样被打开。

网络套接字有如下几种类型:

  • 数据报套接字(SOCK_DGRAM),也称为无连接套接字,使用用户数据报协议(UDP)。数据报套接字支持双向消息流并保留记录边界。

  • 流套接字(SOCK_STREAM),也称为面向连接的套接字,使用传输控制协议(TCP),流控制传输协议(SCTP)或数据报拥塞控制协议(DCCP)。这些套接字提供了没有记录边界的双向,可靠,有序且无重复的数据流。

  • 原始套接字(或原始IP套接字)通常在路由器和其他网络设备中可用。这些套接字通常是面向数据报的,尽管它们的确切特性取决于协议提供的接口。大多数应用程序不使用原始套接字。提供它们是为了支持新的通信协议的开发,并提供对现有协议更深层设施的访问。

套接字通信

首先,让我们弄清楚如何确保每个套接字都是唯一的。否则,您将无法建立可靠的沟通通道(channel)。

为每个进程(process)提供唯一的PID有助于解决本地问题。但是,这种方法不适用于网络。要创建唯一的套接字,我们建议使用TCP / IP协议。使用TCP / IP,网络层的IP地址在给定网络内是唯一的,并且协议和端口在主机应用程序之间是唯一的。

TCP和UDP是用于主机之间通信的两个主要协议。让我们看看您的应用程序如何连接到TCP和UDP套接字。

  • 连接到TCP套接字

为了建立TCP连接,Go客户端使用net程序包中的DialTCP函数。DialTCP返回一个TCPConn对象。建立连接后,客户端和服务器开始交换数据:客户端通过TCPConn向服务器发送请求,服务器解析请求并发送响应,TCPConn从服务器接收响应。

img{512x368}
图:TCP Socket

该连接将持续保持有效,直到客户端或服务器将其关闭。创建连接的函数如下:

客户端:

// init
   tcpAddr, err := net.ResolveTCPAddr(resolver, serverAddr)
   if err != nil {
        // handle error
   }
   conn, err := net.DialTCP(network, nil, tcpAddr)
   if err != nil {
           // handle error
   }

   // send message
    _, err = conn.Write({message})
   if err != nil {
        // handle error
   }

   // receive message
   var buf [{buffSize}]byte
   _, err := conn.Read(buf[0:])
   if err != nil {
        // handle error
   }

服务端:

// init
   tcpAddr, err := net.ResolveTCPAddr(resolver, serverAddr)
       if err != nil {
           // handle error
       }

       listener, err := net.ListenTCP("tcp", tcpAddr)
    if err != nil {
        // handle error
    }

    // listen for an incoming connection
    conn, err := listener.Accept()
    if err != nil {
        // handle error
    }

    // send message
    if _, err := conn.Write({message}); err != nil {
        // handle error
    }
    // receive message
    buf := make([]byte, 512)
    n, err := conn.Read(buf[0:])
    if err != nil {
        // handle error
    }

  • 连接到UDP套接字

与TCP套接字相反,使用UDP套接字,客户端只是向服务器发送数据报。没有Accept函数,因为服务器不需要接受连接,而只是等待数据报到达。

img{512x368}
图:UDP Socket

其他TCP函数都具有UDP对应的函数;只需在上述函数中将TCP替换为UDP。

客户端:

// init
    raddr, err := net.ResolveUDPAddr("udp", address)
    if err != nil {
        // handle error
    }

    conn, err := net.DialUDP("udp", nil, raddr)
    if err != nil {
        // handle error
    }
        .......
    // send message
    buffer := make([]byte, maxBufferSize)
    n, addr, err := conn.ReadFrom(buffer)
    if err != nil {
        // handle error
    }
         .......
    // receive message
    buffer := make([]byte, maxBufferSize)
    n, err = conn.WriteTo(buffer[:n], addr)
    if err != nil {
        // handle error
    }

服务端:

// init
    udpAddr, err := net.ResolveUDPAddr(resolver, serverAddr)
    if err != nil {
        // handle error
    }

    conn, err := net.ListenUDP("udp", udpAddr)
    if err != nil {
        // handle error
    }
        .......
    // send message
    buffer := make([]byte, maxBufferSize)
    n, addr, err := conn.ReadFromUDP(buffer)
    if err != nil {
        // handle error
    }
         .......
    // receive message
    buffer := make([]byte, maxBufferSize)
    n, err = conn.WriteToUDP(buffer[:n], addr)
    if err != nil {
        // handle error
    }

什么是WebSocket

WebSocket通信协议通过单个TCP连接提供全双工通信通道。与HTTP相比,WebSocket不需要您发送请求即可获得响应。它们允许双向数据流,因此您只需等待服务器响应即可。可用时,它将向您发送一条消息。

对于需要连续数据交换的服务(例如即时通讯程序,在线游戏和实时交易系统),WebSockets是一个很好的解决方案。您可以在RFC 6455规范中找到有关WebSocket协议的完整信息。

WebSocket连接由浏览器请求发起,并由服务器响应,之后连接就建立起来了。此过程通常称为握手。WebSockets中的特殊标头仅需要浏览器与服务器之间的一次握手即可建立连接,该连接将在其整个生命周期内保持活动状态。

WebSockets解决了许多实时Web开发的难题,与传统的HTTP相比,它具有许多优点:

  • 轻量级报头减少了数据传输开销。
  • 单个Web客户端仅需要一个TCP连接。
  • WebSocket服务器可以将数据推送到Web客户端。

img{512x368}
图:WebSocket

WebSocket协议实现起来相对简单。它使用HTTP协议进行初始握手。成功握手后,连接就建立起来了,并且WebSocket实质上使用原始TCP(raw tcp)来读取/写入数据。

客户端请求如下所示:

GET /chat HTTP/1.1
    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13
    Origin: http://example.com

这是服务器响应:

HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
    Sec-WebSocket-Protocol: chat

如何在Go中创建WebSocket应用

要基于该net/http 库编写简单的WebSocket echo服务器,您需要:

  • 发起握手
  • 从客户端接收数据帧
  • 发送数据帧给客户端
  • 关闭握手

首先,让我们创建一个带有WebSocket端点的HTTP处理程序:

// HTTP server with WebSocket endpoint
func Server() {
        http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
            ws, err := NewHandler(w, r)
            if err != nil {
                 // handle error
            }
            if err = ws.Handshake(); err != nil {
                // handle error
            }
        …

然后初始化WebSocket结构。

初始握手请求始终来自客户端。服务器确定了WebSocket请求后,需要使用握手响应进行回复。

请记住,您无法使用http.ResponseWriter编写响应,因为一旦开始发送响应,它将关闭基础TCP连接。

因此,您需要使用HTTP劫持(hijack)。通过劫持,您可以接管基础的TCP连接处理程序和bufio.Writer。这使您可以在不关闭TCP连接的情况下读取和写入数据。

// NewHandler initializes a new handler
func NewHandler(w http.ResponseWriter, req *http.Request) (*WS, error) {
        hj, ok := w.(http.Hijacker)
        if !ok {
            // handle error
        }                  .....
}

要完成握手,服务器必须使用适当的头进行响应。

// Handshake creates a handshake header
    func (ws *WS) Handshake() error {

        hash := func(key string) string {
            h := sha1.New()
            h.Write([]byte(key))
            h.Write([]byte("258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))

        return base64.StdEncoding.EncodeToString(h.Sum(nil))
        }(ws.header.Get("Sec-WebSocket-Key"))
      .....
}

“Sec-WebSocket-key”是随机生成的,并且是Base64编码的。接受请求后,服务器需要将此密钥附加到固定字符串。假设您有x3JJHMbDL1EzLkh9GBhXDw== 钥匙。在这个例子中,可以使用SHA-1计算二进制值,并使用Base64对其进行编码。假设你得到HSmrc0sMlYUkAGmm5OPpG2HaGWk=。使,用它作为Sec-WebSocket-Accept 响应头的值。

传输数据帧

握手成功完成后,您的应用程序可以从客户端读取数据或向客户端写入数据。WebSocket规范定义了的一个客户机和服务器之间使用的特定帧格式。这是框架的位模式:

img{512x368}
图:传输数据帧的位模式

使用以下代码对客户端有效负载进行解码:

// Recv receives data and returns a Frame
    func (ws *WS) Recv() (frame Frame, _ error) {
        frame = Frame{}
        head, err := ws.read(2)
        if err != nil {
            // handle error
        }

反过来,这些代码行允许对数据进行编码:

// Send sends a Frame
    func (ws *WS) Send(fr Frame) error {
        // make a slice of bytes of length 2
        data := make([]byte, 2)

        // Save fragmentation & opcode information in the first byte
        data[0] = 0x80 | fr.Opcode
        if fr.IsFragment {
            data[0] &= 0x7F
        }
        .....

关闭握手

当各方之一发送状态为关闭的关闭帧作为有效负载时,握手将关闭。可选地,发送关闭帧的一方可以在有效载荷中发送关闭原因。如果关闭是由客户端发起的,则服务器应发送相应的关闭帧作为响应。

// Close sends a close frame and closes the TCP connection
func (ws *Ws) Close() error {
    f := Frame{}
    f.Opcode = 8
    f.Length = 2
    f.Payload = make([]byte, 2)
    binary.BigEndian.PutUint16(f.Payload, ws.status)
    if err := ws.Send(f); err != nil {
        return err
    }
    return ws.conn.Close()
}

WebSocket库列表

有几个第三方库可简化开发人员的开发工作,并极大地促进使用WebSockets。

  • STDLIB(golang.org/x/net/websocket)

此WebSocket库是标准库的一部分。如RFC 6455规范中所述,它为WebSocket协议实现了客户端和服务器。它不需要安装并且有很好的官方文档。但是,另一方面,它仍然缺少其他WebSocket库中可以找到的某些功能。/x/net/websocket软件包中的Golang WebSocket实现不允许用户以明确的方式重用连接之间的I/O缓冲区。

让我们检查一下STDLIB软件包的工作方式。这是用于执行基本功能(如创建连接以及发送和接收消息)的代码示例。

首先,要安装和使用此库,应将以下代码行添加到您的:

import "golang.org/x/net/websocket"

客户端:

    // create connection
    // schema can be ws:// or wss://
    // host, port – WebSocket server
    conn, err := websocket.Dial("{schema}://{host}:{port}", "", op.Origin)
    if err != nil {
        // handle error
    }
    defer conn.Close()
             .......
      // send message
        if err = websocket.JSON.Send(conn, {message}); err != nil {
         // handle error
    }
              .......
        // receive message
    // messageType initializes some type of message
    message := messageType{}
    if err := websocket.JSON.Receive(conn, &message); err != nil {
          // handle error
    }
        .......

服务器端:

    // Initialize WebSocket handler + server
    mux := http.NewServeMux()
        mux.Handle("/", websocket.Handler(func(conn *websocket.Conn) {
            func() {
                for {

                    // do something, receive, send, etc.
                }
            }
            .......
        // receive message
    // messageType initializes some type of message
    message := messageType{}
    if err := websocket.JSON.Receive(conn, &message); err != nil {
        // handle error
    }
        .......
    // send message
    if err := websocket.JSON.Send(conn, message); err != nil {
        // handle error
    }
        ........
  • GORILLA

Gorilla Web工具包中的WebSocket软件包拥有WebSocket协议的完整且经过测试的实现以及稳定的软件包API。WebSocket软件包文档齐全,易于使用。您可以在Gorilla官方网站上找到文档。

安装

go get github.com/gorilla/websocket
Examples of code
Client side:
 // init
    // schema – can be ws:// or wss://
    // host, port – WebSocket server
    u := url.URL{
        Scheme: {schema},
        Host:   {host}:{port},
        Path:   "/",
    }
    c, _, err := websocket.DefaultDialer.Dial(u.String(), nil)
    if err != nil {
        // handle error
    }
        .......
    // send message
    err := c.WriteMessage(websocket.TextMessage, {message})
    if err != nil {
        // handle error
    }
        .......
    // receive message
    _, message, err := c.ReadMessage()
    if err != nil {
        // handle error
    }
        .......

服务器端:

  // init
    u := websocket.Upgrader{}
    c, err := u.Upgrade(w, r, nil)
    if err != nil {
        // handle error
    }
        .......
    // receive message
    messageType, message, err := c.ReadMessage()
    if err != nil {
        // handle error
    }
        .......
    // send message
    err = c.WriteMessage(messageType, {message})
    if err != nil {
        // handle error
    }
        .......
  • GOBWAS

这个微小的WebSocket封装具有强大的功能列表,例如零拷贝升级(zero-copy upgrade)和允许构建自定义数据包处理逻辑的低级API。GOBWAS在I/O期间不需要中间做额外分配操作。它还在wsutil软件包中提供了围绕API的高级包装API和帮助API,使开发人员可以快速使用,而无需深入研究协议的内部。该库具有灵活的API,但这是以可用性和清晰度为代价的。

可在GoDoc网站上找到文档。您可以通过下面代码行来安装它:

go get github.com/gobwas/ws

客户端:

    // init
    // schema – can be ws or wss
    // host, port – ws server
    conn, _, _, err := ws.DefaultDialer.Dial(ctx, {schema}://{host}:{port})
    if err != nil {
        // handle error
    }
        .......
    // send message
    err = wsutil.WriteClientMessage(conn, ws.OpText, {message})
    if err != nil {
        // handle error
    }

        .......
    // receive message
    msg, _, err := wsutil.ReadServerData(conn)
    if err != nil {
        // handle error
    }
        .......

服务器端:

   // init
    listener, err := net.Listen("tcp", op.Port)
    if err != nil {
        // handle error
    }
    conn, err := listener.Accept()
    if err != nil {
        // handle error
    }
    upgrader := ws.Upgrader{}
    if _, err = upgrader.Upgrade(conn); err != nil {
        // handle error
    }
        .......
    // receive message
    for {
         reader := wsutil.NewReader(conn, ws.StateServerSide)
         _, err := reader.NextFrame()
         if err != nil {
             // handle error
         }
         data, err := ioutil.ReadAll(reader)
         if err != nil {
             // handle error
         }
            .......
    }
        .......
    // send message
    msg := "new server message"
    if err := wsutil.WriteServerText(conn, {message}); err != nil {
        // handle error
    }
        .......
  • GOWebsockets

该工具提供了广泛的易于使用的功能。它允许并发控制,数据压缩和设置请求标头。GoWebsockets支持代理和子协议,用于发送和接收文本和二进制数据。开发人员还可以启用或禁用SSL验证。

您可以在GoDoc网站和项目的GitHub页面上找到有关如何使用GOWebsockets的文档和示例。通过添加以下代码行来安装软件包:

go get github.com/sacOO7/gowebsocket

客户端:

    // init
    // schema – can be ws or wss
    // host, port – ws server
    socket := gowebsocket.New({schema}://{host}:{port})
    socket.Connect()
        .......
    // send message
    socket.SendText({message})
    or
    socket.SendBinary({message})
        .......
    // receive message
    socket.OnTextMessage = func(message string, socket gowebsocket.Socket) {
        // hande received message
    };
    or
    socket.OnBinaryMessage = func(data [] byte, socket gowebsocket.Socket) {
        // hande received message
    };
        .......

服务器端:

    // init
    // schema – can be ws or wss
    // host, port – ws server
    conn, _, _, err := ws.DefaultDialer.Dial(ctx, {schema}://{host}:{port})
    if err != nil {
        // handle error
    }
        .......
    // send message
    err = wsutil.WriteClientMessage(conn, ws.OpText, {message})
    if err != nil {
        // handle error
    }
        .......
    // receive message
    msg, _, err := wsutil.ReadServerData(conn)
    if err != nil {
        // handle error
    }

比较现有解决方案

我们已经描述了Go中使用最广泛的四个WebSocket库。下表包含这些工具的详细比较。

img{512x368}
图 Websocket库比较

为了更好地分析其性能,我们还进行了一些基准测试。结果如下:

img{512x368}

  • 如您所见,GOBWAS与其他库相比具有明显的优势。每个操作分配的内存更少,每个分配使用的内存和时间更少。另外,它的I/O分配为零。此外,GOBWAS还具有创建WebSocket客户端与服务器的交互并接收消息片段所需的所有方法。您也可以使用它轻松地使用TCP套接字。

  • 如果您真的不喜欢GOBWAS,则可以使用Gorilla。它非常简单,几乎具有所有相同的功能。您也可以使用STDLIB,但由于它缺少许多必要的功能,并且在生产中表现不佳,而且正如您在基准测试中所看到的那样,它的性能较弱。GOWebsocket与STDLIB大致相同。但是,如果您需要快速构建原型或MVP,则它可能是一个合理的选择。

除了这些工具之外,还有几种替代实现可让您构建强大的流处理解决方案。其中有:

流技术的不断发展以及WebSockets等文档较好的可用工具的存在,使开发人员可以轻松创建真正的实时应用程序。 如果您需要使用WebSockets创建实时应用程序的建议或帮助,请给我们写信。希望本教程对您有所帮助。

本文翻译自《How to Use Websockets in Golang : Best Tools and Step-by-Step Guide》


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

在Kubernetes上如何基于自定义指标实现应用的自动缩放

$
0
0

img{512x368}

如何在Kubernetes上实现应用缩放?

使用静态配置将应用程序部署到生产环境并不是最佳选择。

流量模式可能会快速变化,应用程序应该能够实现自适应:

  • 当需求增加时,应用程序应扩大规模(增加副本数)以保持响应速度。
  • 当需求减少时,应用程序应缩小规模(减少副本数量),以免浪费资源。

Kubernetes以Horizontal Pod Autoscaler的形式为自动缩放应用程序提供了出色的支持。

下面我们将学习如何使用它。

不同类型的自动缩放

首先,为了消除任何误解,让我们澄清一下Kubernetes中的术语“自动缩放”的不同用法。

在Kubernetes中,有几件事可被称为“自动缩放”,包括:

  • 水平Pod自动缩放器:调整应用程序的副本数
  • Vertical Pod Autoscaler:调整容器的资源请求(request)和限制(limit)
  • 集群自动缩放器:调整集群的节点数

尽管这些组件都可以“自动缩放”某些东西,但是它们彼此之间完全不相关。

它们都针对非常不同的用例,并使用不同的概念和机制。

它们是在单独的项目中开发的,可以彼此独立使用。

本文介绍的是水平Pod自动缩放器。

什么是水平Pod自动缩放器?

水平Pod自动配置器是Kubernetes内置的功能,允许基于一个或多个被监测的指标水平缩放应用规模。

水平缩放意味着增加和减少副本数量。垂直缩放意味着增加和减少单个副本的计算资源。

从技术上讲,Horizontal Pod Autoscaler是Kubernetes控制器管理器(controller manager)中的控制器(controller),它是由HorizontalPodAutoscaler资源对象配置的。

Horizontal Pod Autoscaler可以监视有关应用程序的指标,并不断调整副本数以最佳地满足当前需求。

Horizontal Pod Autoscaler可缩放的资源包括Deployment,StatefulSet,ReplicaSet和ReplicationController。

为了自动缩放应用程序,Horizontal Pod自动缩放器会执行一个永久控制循环:

img{512x368}

此控制循环的步骤为:

  • 查询缩放指标
  • 计算所需的副本数
  • 将应用程序缩放到所需数量的副本

控制循环的默认周期为15秒

所需副本数的计算基于缩放度量和该度量的用户提供的目标值。

目的是计算一个副本计数,该副本计数将使度量值尽可能接近目标值。

例如,假设缩放指标是每个副本的每秒请求速率:

  • 如果目标值为10 req / sec,而当前值为20 req / sec,则Horizontal Pod Autoscaler将按比例放大应用程序(即增加副本数),以使度量标准减小并更接近目标值。
  • 如果目标值为10 req / sec,当前值为2 req / sec,则Horizontal Pod Autoscaler将按比例缩小应用程序(即减少副本数),以使度量标准增加并更接近目标值。

用于计算所需副本数的算法基于以下公式:

X = N * (c/t)

其中X是所需的副本数,N是当前副本数,c是度量的当前值,t是目标值。

您可以在文档中找到有关算法的详细信息。

这就是Horizontal Pod Autoscaler的工作方式,但是如何使用它呢?

如何配置水平pod自动缩放器?

通过创建HorizontalPodAutoscaler资源,可以将Horizontal Pod Autoscaler配置为自动缩放应用程序。

此资源使您可以指定以下参数:

  • 可扩展的资源(例如,部署)
  • 最小和最大副本数
  • 缩放指标
  • 缩放指标的目标值

创建此资源后,Horizontal Pod Autoscaler将使用提供的参数开始对您的应用执行上述控制循环。

具体的HorizontalPodAutoscaler资源如下所示:

//hpa.yaml

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myhpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metric:
          name: myapp_requests_per_second
        target:
          type: AverageValue
          averageValue: 2

存在清单文件结构不同的HorizontalPodAutoscaler资源的不同版本。上面的示例使用version v2beta2,它是撰写本文时的最新版本。

此资源myapp根据myapp_requests_per_second一个目标值为2 的指标指定一个名为Deployment的部署,该部署将在1到10个副本之间自动缩放。

您可以想象到,该myapp_requests_per_second指标代表此部署中各个Pod的请求率-因此,本规范的目的是自动调整Deployment的目标,以使每个Pod保持每秒2个请求的请求率。

到目前为止,这听起来不错,但有一个问题。

指标来自哪里?

什么是指标注册表?

整个自动缩放机制均基于代表应用程序当前负载的指标。

定义HorizontalPodAutoscaler资源时,您必须指定此类指标。

但是Horizontal Pod Autoscaler如何知道如何获取这些指标?

事实证明,还有另一个组件在起作用-指标注册表。

Horizontal Pod Autoscaler从指标注册表查询指标:

img{512x368}

度量标准注册表是集群中的中心位置,度量标准(任何类型)向客户端(任何类型)公开。

Horizontal Pod Autoscaler是这些客户端之一。

度量标准注册表的目的是为客户端提供从中查询度量标准的标准接口。

指标注册表的接口包含三个单独的API:

img{512x368}

这些API旨在提供不同类型的指标:

  • 资源度量标准API: Pod和节点的预定义资源使用度量标准(CPU和内存)
  • 自定义指标API:与Kubernetes对象关联的自定义指标
  • 外部指标API:与Kubernetes对象不关联的自定义指标

所有这些度量标准API都是扩展API

这意味着它们是核心Kubernetes API的扩展,可通过Kubernetes API服务器进行访问。

如果要自动缩放应用程序,这对您意味着什么?

您想要用作缩放指标的任何指标都必须通过这三个指标API之一公开。

因为只有这样,Horizontal Pod Autoscaler才能访问它们。

因此,要自动缩放应用程序,您的任务不仅是配置Horizontal Pod自动缩放器…

您还必须通过度量标准注册表公开所需的缩放度量标准。

如何通过度量标准API公开度量标准?

通过在集群中安装和配置其他组件。

对于每个度量标准API,您需要一个相应的度量标准API服务器,并且需要对其进行配置以通过度量标准API公开特定的度量标准。

默认情况下,Kubernetes中未安装任何度量标准API服务器,这意味着默认情况下未启用度量标准API 。

此外,您需要一个指标收集器,该指标收集器从源(例如,从目标应用的Pod)收集所需的指标,并将其提供给指标API服务器。

img{512x368}

对于不同的度量标准API,度量标准API服务器和度量标准收集器有不同的选择。

资源指标API:

  • 指标收集器是cAdvisor,它在每个工作程序节点上作为kubelet的一部分运行(因此默认情况下已安装)
  • 资源指标API的官方指标API服务器是metrics-server

自定义指标API和外部指标API:

  • 指标收集器的一个流行选择是Prometheus。但是,也可以使用其他指标系统(例如Datadog或Google Stackdriver)代替
  • prometheus适配器是与普罗米修斯集成为度量收集的度量标准API服务器-但是,其他度量收集器有自己的度量标准API服务器

因此,要通过一种度量标准API公开度量标准,您必须执行以下步骤:

  • 安装指标收集器(例如Prometheus)并将其配置为收集所需指标(例如从您的应用程序的Pod中收集)
  • 安装度量标准API服务器(例如Prometheus适配器)并将其配置为通过相应的度量标准API从度量标准收集器暴露度量数据

请注意,这专门适用于提供自定义指标的自定义指标API和外部指标API。Resource Metrics API仅提供默认指标,而不能配置为提供自定义指标。

以上信息很多,让我们把它们放在一起再完整过一遍。

放在一起

让我们来看一个完整的示例,该示例将应用配置为由Horizontal Pod Autoscaler自动缩放。

想象一下,您想基于副本的平均每秒请求速率来自动缩放Web应用程序。

另外,假设您要使用基于Prometheus的设置来通过Custom Metrics API公开请求率指标。

请求速率是与Kubernetes对象(Pods)关联的自定义指标,因此必须通过Custom Metrics API公开。

以下是达到目标的一系列步骤:

  • 设置您的应用程序,以将接收到的请求总数作为Prometheus指标公开
  • 安装Prometheus并将其配置为从应用程序的所有Pod中收集此指标
  • 安装Prometheus适配器并将其配置为将度量标准从Prometheus转换为每秒请求速率(使用PromQL)并且作为myapp_requests_per_second指标通过Custom Metrics API 公开
  • 创建一个HorizontalPodAutoscaler资源(如上所示),指定myapp_requests_per_second为缩放指标和适当的目标值

一旦创建HorizontalPodAutoscaler资源,Horizontal Pod Autoscaler就会启动,并开始根据您的配置自动缩放您的应用程序。

现在,您可以观察您的应用程序适应流量的情况。

本文为基于自定义指标自动缩放应用程序设置了理论框架。

在以后的文章中,您将把这些知识付诸实践,并在自己的集群上使用自己的应用程序执行上述步骤。

本文翻译自《How to autoscale apps on Kubernetes with custom metrics》


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Uber Go语言编码规范

$
0
0

Uber是世界领先的生活出行服务提供商,也是Go语言的早期adopter,根据Uber工程博客的内容,大致可以判断出Go语言在Uber内部扮演了十分重要的角色。Uber内部的Go语言工程实践也是硕果累累,有大量Go实现的内部工具被Uber开源到github上,诸如被Gopher圈熟知的zapjaeger等。2018年年末Uber将内部的Go风格规范开源到github,经过一年的积累和更新,该规范已经初具规模,并受到广大Gopher的关注。本文是该规范的中文版本,并”夹带“了部分笔者的点评,希望对国内Gopher有所帮助。

注:该版本基于commit 3baa2bd翻译,后续不会持续更新。

img{512x368}

一. 介绍

样式(style)是支配我们代码的惯例。术语“样式”有点用词不当,因为这些约定涵盖的范围不限于由gofmt替我们处理的源文件格式。

本指南的目的是通过详细描述在Uber编写Go代码的注意事项来管理这种复杂性。这些规则的存在是为了使代码库易于管理,同时仍然允许工程师更有效地使用Go语言功能。

该指南最初由Prashant VaranasiSimon Newton编写,目的是使一些同事能快速使用Go。多年来,该指南已根据其他人的反馈进行了修改。

本文档记录了我们在Uber遵循的Go代码中的惯用约定。其中许多是Go的通用准则,而其他扩展准则依赖于下面外部的指南:

所有代码都应该通过golintgo vet的检查并无错误。我们建议您将编辑器设置为:

  • 保存时运行goimports
  • 运行golint和go vet检查源码

您可以在以下Go编辑器工具支持页面中找到更为详细的信息:https://github.com/golang/go/wiki/IDEsAndTextEditorPlugins

二. 指导原则

指向interface的指针

您几乎不需要指向接口类型的指针。您应该将接口作为值进行传递,在这样的传递过程中,实质上传递的底层数据仍然可以是指针。

接口实质上在底层用两个字段表示:

  • 一个指向某些特定类型信息的指针。您可以将其视为“类型”。
  • 数据指针。如果存储的数据是指针,则直接存储。如果存储的数据是一个值,则存储指向该值的指针。

如果要接口方法修改底层数据,则必须用指向目标对象的指针赋值给接口类型变量(译注:感觉原指南中这里表达过于简略,不是很清晰,因此在翻译时增加了自己的一些诠释)。

接收器(receiver)与接口

使用值接收器的方法既可以通过值调用,也可以通过指针调用。

例如:

type S struct {
  data string
}

func (s S) Read() string {
  return s.data
}

func (s *S) Write(str string) {
  s.data = str
}

sVals := map[int]S{1: {"A"}}

// 你只能通过值调用Read
sVals[1].Read()

// 下面无法通过编译:
//  sVals[1].Write("test")

sPtrs := map[int]*S{1: {"A"}}

// 通过指针既可以调用Read,也可以调用Write方法
sPtrs[1].Read()
sPtrs[1].Write("test")

同样,即使该方法具有值接收器,也可以通过指针来满足接口。

type F interface {
  f()
}

type S1 struct{}

func (s S1) f() {}

type S2 struct{}

func (s *S2) f() {}

s1Val := S1{}
s1Ptr := &S1{}
s2Val := S2{}
s2Ptr := &S2{}

var i F
i = s1Val
i = s1Ptr
i = s2Ptr

// 下面代码无法通过编译。因为s2Val是一个值,而S2的f方法中没有使用值接收器
//   i = s2Val

《Effective Go》中有一段关于“pointers vs values”的精彩讲解。

译注:关于Go类型的method集合的问题,在我之前的文章《关于Go,你可能不注意的7件事》中有详尽说明。

零值Mutex是有效的

sync.Mutex和sync.RWMutex是有效的。因此你几乎不需要一个指向mutex的指针。

Bad:

mu := new(sync.Mutex)
mu.Lock()

vs.

Good:

var mu sync.Mutex
mu.Lock()

如果你使用结构体指针,mutex可以非指针形式作为结构体的组成字段,或者更好的方式是直接嵌入到结构体中。

如果是私有结构体类型或是要实现Mutex接口的类型,我们可以使用嵌入mutex的方法:

type smap struct {
  sync.Mutex

  data map[string]string
}

func newSMap() *smap {
  return &smap{
    data: make(map[string]string),
  }
}

func (m *smap) Get(k string) string {
  m.Lock()
  defer m.Unlock()

  return m.data[k]
}

对于导出类型,请使用私有锁:

type SMap struct {
  mu sync.Mutex

  data map[string]string
}

func NewSMap() *SMap {
  return &SMap{
    data: make(map[string]string),
  }
}

func (m *SMap) Get(k string) string {
  m.mu.Lock()
  defer m.mu.Unlock()

  return m.data[k]
}

在边界处拷贝Slices和Maps

slices和maps包含了指向底层数据的指针,因此在需要复制它们时要特别注意。

接收Slices和Maps

请记住,当map或slice作为函数参数传入时,如果您存储了对它们的引用,则用户可以对其进行修改。

Bad

func (d *Driver) SetTrips(trips []Trip) {
  d.trips = trips
}

trips := ...
d1.SetTrips(trips)

// 你是要修改d1.trips吗?
trips[0] = ...

vs.

Good

func (d *Driver) SetTrips(trips []Trip) {
  d.trips = make([]Trip, len(trips))
  copy(d.trips, trips)
}

trips := ...
d1.SetTrips(trips)

// 这里我们修改trips[0],但不会影响到d1.trips
trips[0] = ...

返回slices或maps

同样,请注意用户对暴露内部状态的map或slice的修改。

Bad

type Stats struct {
  sync.Mutex

  counters map[string]int
}

// Snapshot返回当前状态
func (s *Stats) Snapshot() map[string]int {
  s.Lock()
  defer s.Unlock()

  return s.counters
}

// snapshot不再受到锁的保护
snapshot := stats.Snapshot()

vs.

Good

type Stats struct {
  sync.Mutex

  counters map[string]int
}

func (s *Stats) Snapshot() map[string]int {
  s.Lock()
  defer s.Unlock()

  result := make(map[string]int, len(s.counters))
  for k, v := range s.counters {
    result[k] = v
  }
  return result
}

// snapshot现在是一个拷贝
snapshot := stats.Snapshot()

使用defer做清理

使用defer清理资源,诸如文件和锁。

Bad

p.Lock()
if p.count < 10 {
  p.Unlock()
  return p.count
}

p.count++
newCount := p.count
p.Unlock()

return newCount

// 当有多个return分支时,很容易遗忘unlock

vs.

Good

p.Lock()
defer p.Unlock()

if p.count < 10 {
  return p.count
}

p.count++
return p.count

// 更可读

Defer的开销非常小,只有在您可以证明函数执行时间处于纳秒级的程度时,才应避免这样做。使用defer提升可读性是值得的,因为使用它们的成本微不足道。尤其适用于那些不仅仅是简单内存访问的较大的方法,在这些方法中其他计算的资源消耗远超过defer。

Channel的size要么是1,要么是无缓冲的

channel通常size应为1或是无缓冲的。默认情况下,channel是无缓冲的,其size为零。任何其他尺寸都必须经过严格的审查。考虑如何确定大小,是什么阻止了channel在负载下被填满并阻止写入,以及发生这种情况时发生了什么。

Bad

// 应该足以满足任何人
c := make(chan int, 64)

vs.

Good

// 大小:1
c := make(chan int, 1) // 或
// 无缓冲channel,大小为0
c := make(chan int)

枚举从1开始

在Go中引入枚举的标准方法是声明一个自定义类型和一个使用了iota的const组。由于变量的默认值为0,因此通常应以非零值开头枚举。

Bad

type Operation int

const (
  Add Operation = iota
  Subtract
  Multiply
)

// Add=0, Subtract=1, Multiply=2

vs.

Good

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
)

// Add=1, Subtract=2, Multiply=3

在某些情况下,使用零值是有意义的(枚举从零开始),例如,当零值是理想的默认行为时。

type LogOutput int

const (
  LogToStdout LogOutput = iota
  LogToFile
  LogToRemote
)

// LogToStdout=0, LogToFile=1, LogToRemote=2

错误类型

Go中有多种声明错误(Error)的选项:

  • errors.New 对于简单静态字符串的错误
  • fmt.Errorf 用于格式化的错误字符串
  • 实现Error()方法的自定义类型
  • 使用 “pkg/errors”.Wrap的wrapped error

返回错误时,请考虑以下因素以确定最佳选择:

  • 这是一个不需要额外信息的简单错误吗?如果是这样,errors.New 就足够了。
  • 客户需要检测并处理此错误吗?如果是这样,则应使用自定义类型并实现该Error()方法。
  • 您是否正在传播下游函数返回的错误?如果是这样,请查看本文后面有关错误包装(Error Wrap)部分的内容
  • 否则,fmt.Errorf就可以。

如果客户端需要检测错误,并且您已使用创建了一个简单的错误errors.New,请使用一个错误变量(sentinel error )。

Bad

// package foo

func Open() error {
  return errors.New("could not open")
}

// package bar

func use() {
  if err := foo.Open(); err != nil {
    if err.Error() == "could not open" {
      // handle
    } else {
      panic("unknown error")
    }
  }
}

vs.

Good

// package foo

var ErrCouldNotOpen = errors.New("could not open")

func Open() error {
  return ErrCouldNotOpen
}

// package bar

if err := foo.Open(); err != nil {
  if err == foo.ErrCouldNotOpen {
    // handle
  } else {
    panic("unknown error")
  }
}

如果您有可能需要客户端检测的错误,并且想向其中添加更多信息(例如,它不是静态字符串),则应使用自定义类型。

Bad

func open(file string) error {
  return fmt.Errorf("file %q not found", file)
}

func use() {
  if err := open(); err != nil {
    if strings.Contains(err.Error(), "not found") {
      // handle
    } else {
      panic("unknown error")
    }
  }
}

vs.

Good

type errNotFound struct {
  file string
}

func (e errNotFound) Error() string {
  return fmt.Sprintf("file %q not found", e.file)
}

func open(file string) error {
  return errNotFound{file: file}
}

func use() {
  if err := open(); err != nil {
    if _, ok := err.(errNotFound); ok {
      // handle
    } else {
      panic("unknown error")
    }
  }
}

直接导出自定义错误类型时要小心,因为它们已成为程序包公共API的一部分。最好公开匹配器功能以检查错误。

// package foo

type errNotFound struct {
  file string
}

func (e errNotFound) Error() string {
  return fmt.Sprintf("file %q not found", e.file)
}

func IsNotFoundError(err error) bool {
  _, ok := err.(errNotFound)
  return ok
}

func Open(file string) error {
  return errNotFound{file: file}
}

// package bar

if err := foo.Open("foo"); err != nil {
  if foo.IsNotFoundError(err) {
    // handle
  } else {
    panic("unknown error")
  }
}

错误包装(Error Wrapping)

一个(函数/方法)调用失败时,有三种主要的错误传播方式:

  • 如果没有要添加的其他上下文,并且您想要维护原始错误类型,则返回原始错误。
  • 添加上下文,使用”pkg/errors”.Wrap以便错误消息提供更多上下文,”pkg/errors”.Cause可用于提取原始错误。
  • 使用fmt.Errorf,如果调用者不需要检测或处理的特定错误情况。

建议在可能的地方添加上下文,以使您获得诸如“调用服务foo:连接被拒绝”之类的更有用的错误,而不是诸如“连接被拒绝”之类的模糊错误。

在将上下文添加到返回的错误时,请避免使用“ failed to”之类的短语来保持上下文简洁,这些短语会陈述明显的内容,并随着错误在堆栈中的渗透而逐渐堆积:

Bad

s, err := store.New()
if err != nil {
    return fmt.Errorf(
        "failed to create new store: %s", err)
}

failed to x: failed to y: failed to create new store: the error

vs.

Good

s, err := store.New()
if err != nil {
    return fmt.Errorf(
        "new store: %s", err)
}

x: y: new store: the error

但是,一旦将错误发送到另一个系统,就应该明确消息是错误消息(例如使用err标记,或在日志中以”Failed”为前缀)。

另请参见Don’t just check errors, handle them gracefully.

处理类型断言失败

类型断言的单个返回值形式针对不正确的类型将产生panic。因此,请始终使用“comma ok”的惯用法。

Bad

t := i.(string)

vs.

Good

t, ok := i.(string)
if !ok {
  // 优雅地处理错误
}

不要panic

在生产环境中运行的代码必须避免出现panic。panic是级联失败的主要根源 。如果发生错误,该函数必须返回错误,并允许调用方决定如何处理它。

Bad

func foo(bar string) {
  if len(bar) == 0 {
    panic("bar must not be empty")
  }
  // ...
}

func main() {
  if len(os.Args) != 2 {
    fmt.Println("USAGE: foo <bar>")
    os.Exit(1)
  }
  foo(os.Args[1])
}

vs.

Good

func foo(bar string) error {
  if len(bar) == 0
    return errors.New("bar must not be empty")
  }
  // ...
  return nil
}

func main() {
  if len(os.Args) != 2 {
    fmt.Println("USAGE: foo <bar>")
    os.Exit(1)
  }
  if err := foo(os.Args[1]); err != nil {
    panic(err)
  }
}

panic/recover不是错误处理策略。仅当发生不可恢复的事情(例如:nil引用)时,程序才必须panic。程序初始化是一个例外:程序启动时应使程序中止的不良情况可能会引起panic。

var _statusTemplate = template.Must(template.New("name").Parse("_statusHTML"))

即便是在test中,也优先使用t.Fatal或t.FailNow来标记test是失败的,而不是panic。

Bad

// func TestFoo(t *testing.T)

f, err := ioutil.TempFile("", "test")
if err != nil {
  panic("failed to set up test")
}

vs.

Good

// func TestFoo(t *testing.T)

f, err := ioutil.TempFile("", "test")
if err != nil {
  t.Fatal("failed to set up test")
}

使用go.uber.org/atomic

使用sync/atomic包的原子操作对原始类型(int32,int64等)进行操作(译注:指atomic包的方法名中均使用原始类型名,如SwapInt32等),因此很容易忘记使用原子操作来读取或修改变量。

go.uber.org/atomic通过隐藏基础类型为这些操作增加了类型安全性。此外,它包括一个方便的atomic.Bool类型。

Bad

type foo struct {
  running int32  // atomic
}

func (f* foo) start() {
  if atomic.SwapInt32(&f.running, 1) == 1 {
     // already running…
     return
  }
  // start the Foo
}

func (f *foo) isRunning() bool {
  return f.running == 1  // race!
}

vs.

Good

type foo struct {
  running atomic.Bool
}

func (f *foo) start() {
  if f.running.Swap(true) {
     // already running…
     return
  }
  // start the Foo
}

func (f *foo) isRunning() bool {
  return f.running.Load()
}

三. 性能

性能方面的特定准则,适用于热路径。

优先使用strconv而不是fmt

将原语转换为字符串或从字符串转换时,strconv速度比fmt快。

Bad

for i := 0; i < b.N; i++ {
  s := fmt.Sprint(rand.Int())
}

BenchmarkFmtSprint-4    143 ns/op    2 allocs/op

vs.

Good

for i := 0; i < b.N; i++ {
  s := strconv.Itoa(rand.Int())
}

BenchmarkStrconv-4    64.2 ns/op    1 allocs/op

避免字符串到字节的转换

不要反复从固定字符串创建字节slice。相反,请执行一次转换并捕获结果。

Bad

for i := 0; i < b.N; i++ {
  w.Write([]byte("Hello world"))
}

BenchmarkBad-4   50000000   22.2 ns/op

vs.

Good

data := []byte("Hello world")
for i := 0; i < b.N; i++ {
  w.Write(data)
}

BenchmarkGood-4  500000000   3.25 ns/op

四. 样式

相似的声明放在一组

Go语言支持将相似的声明放在一个组内:

Bad

import "a"
import "b"

vs.

Good

import (
  "a"
  "b"
)

这同样适用于常量、变量和类型声明:

Bad

const a = 1
const b = 2

var a = 1
var b = 2

type Area float64
type Volume float64

vs.

Good

const (
  a = 1
  b = 2
)

var (
  a = 1
  b = 2
)

type (
  Area float64
  Volume float64
)

仅将相关的声明放在一组。不要将不相关的声明放在一组。

Bad

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
  ENV_VAR = "MY_ENV"
)

vs.

Good

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
)

const ENV_VAR = "MY_ENV"

分组使用的位置没有限制,例如:你可以在函数内部使用它们:

Bad

func f() string {
  var red = color.New(0xff0000)
  var green = color.New(0x00ff00)
  var blue = color.New(0x0000ff)

  ...
}

vs.

Good

func f() string {
  var (
    red   = color.New(0xff0000)
    green = color.New(0x00ff00)
    blue  = color.New(0x0000ff)
  )

  ...
}

import组内的包导入顺序

应该有两类导入组:

  • 标准库
  • 其他一切

默认情况下,这是goimports应用的分组。

Bad

import (
  "fmt"
  "os"
  "go.uber.org/atomic"
  "golang.org/x/sync/errgroup"
)

vs.

Good

import (
  "fmt"
  "os"

  "go.uber.org/atomic"
  "golang.org/x/sync/errgroup"
)

包名

当命名包时,请按下面规则选择一个名称:

  • 全部小写。没有大写或下划线。
  • 大多数使用命名导入的情况下,不需要重命名。
  • 简短而简洁。请记住,在每个使用的地方都完整标识了该名称。
  • 不用复数。例如net/url,而不是net/urls。
  • 不是“common”,“util”,“shared”或“lib”。这些是不好的,信息量不足的名称。

另请参阅Go包名称Go包样式指南

函数名

我们遵循Go社区关于使用MixedCaps作为函数名的约定。有一个例外,为了对相关的测试用例进行分组,函数名可能包含下划线,如: TestMyFunction_WhatIsBeingTested。

包导入别名

如果程序包名称与导入路径的最后一个元素不匹配,则必须使用导入别名。

import (
  "net/http"

  client "example.com/client-go"
  trace "example.com/trace/v2"
)

在所有其他情况下,除非导入之间有直接冲突,否则应避免导入别名。

Bad

import (
  "fmt"
  "os"

  nettrace "golang.net/x/trace"
)

vs.

Good

import (
  "fmt"
  "os"
  "runtime/trace"

  nettrace "golang.net/x/trace"
)

函数分组与顺序

  • 函数应按粗略的调用顺序排序。
  • 同一文件中的函数应按接收者分组。

因此,导出的函数应先出现在文件中,放在struct、const和var定义的后面。

在定义类型之后,但在接收者的其余方法之前,可能会出现一个newXYZ()/ NewXYZ()。

由于函数是按接收者分组的,因此普通工具函数应在文件末尾出现。

Bad

func (s *something) Cost() {
  return calcCost(s.weights)
}

type something struct{ ... }

func calcCost(n int[]) int {...}

func (s *something) Stop() {...}

func newSomething() *something {
    return &something{}
}

vs.

Good

type something struct{ ... }

func newSomething() *something {
    return &something{}
}

func (s *something) Cost() {
  return calcCost(s.weights)
}

func (s *something) Stop() {...}

func calcCost(n int[]) int {...}

减少嵌套

代码应通过尽可能先处理错误情况/特殊情况并尽早返回或继续循环来减少嵌套。减少嵌套多个级别的代码的代码量。

Bad

for _, v := range data {
  if v.F1 == 1 {
    v = process(v)
    if err := v.Call(); err == nil {
      v.Send()
    } else {
      return err
    }
  } else {
    log.Printf("Invalid v: %v", v)
  }
}

vs.

Good

for _, v := range data {
  if v.F1 != 1 {
    log.Printf("Invalid v: %v", v)
    continue
  }

  v = process(v)
  if err := v.Call(); err != nil {
    return err
  }
  v.Send()
}

不必要的else

如果在if的两个分支中都设置了变量,则可以将其替换为单个if。

Bad

var a int
if b {
  a = 100
} else {
  a = 10
}

vs.

Good

a := 10
if b {
  a = 100
}

顶层变量声明

在顶层,使用标准var关键字。请勿指定类型,除非它与表达式的类型不同。

Bad

var _s string = F()

func F() string { return "A" }

vs.

Good

var _s = F()
// 由于F已经明确了返回一个字符串类型,因此我们没有必要显式指定_s的类型

func F() string { return "A" }

如果表达式的类型与所需的类型不完全匹配,请指定类型。

type myError struct{}

func (myError) Error() string { return "error" }

func F() myError { return myError{} }

var _e error = F()
// F返回一个myError类型的实例,但是我们要error类型

对于未导出的顶层常量和变量,使用_作为前缀

译注:这个是Uber内部的惯用法,目前看并不普适。

在未导出的顶级vars和consts, 前面加上前缀_,以使它们在使用时明确表示它们是全局符号。

例外:未导出的错误值,应以err开头。

基本依据:顶级变量和常量具有包范围作用域。使用通用名称可能很容易在其他文件中意外使用错误的值。

Bad

// foo.go

const (
  defaultPort = 8080
  defaultUser = "user"
)

// bar.go

func Bar() {
  defaultPort := 9090
  ...
  fmt.Println("Default port", defaultPort)

  // We will not see a compile error if the first line of
  // Bar() is deleted.
}

vs.

Good

// foo.go

const (
  _defaultPort = 8080
  _defaultUser = "user"
)

结构体中的嵌入

嵌入式类型(例如mutex)应位于结构体内的字段列表的顶部,并且必须有一个空行将嵌入式字段与常规字段分隔开。

Bad

type Client struct {
  version int
  http.Client
}

vs.

Good

type Client struct {
  http.Client

  version int
}

使用字段名初始化结构体

初始化结构体时,几乎始终应该指定字段名称。现在由go vet强制执行。

Bad

k := User{"John", "Doe", true}

vs.

Good

k := User{
    FirstName: "John",
    LastName: "Doe",
    Admin: true,
}

例外:如果有3个或更少的字段,则可以在测试表中省略字段名称。

tests := []struct{
}{
  op Operation
  want string
}{
  {Add, "add"},
  {Subtract, "subtract"},
}

本地变量声明

如果将变量明确设置为某个值,则应使用短变量声明形式(:=)。

Bad

var s = "foo"

vs.

Good

s := "foo"

但是,在某些情况下,var 使用关键字时默认值会更清晰。例如,声明空切片。

Bad

func f(list []int) {
  filtered := []int{}
  for _, v := range list {
    if v > 10 {
      filtered = append(filtered, v)
    }
  }
}

vs.

Good

func f(list []int) {
  var filtered []int
  for _, v := range list {
    if v > 10 {
      filtered = append(filtered, v)
    }
  }
}

nil是一个有效的slice

nil是一个有效的长度为0的slice,这意味着:

  • 您不应明确返回长度为零的切片。返回nil 来代替。

Bad

if x == "" {
  return []int{}
}

vs.

Good

if x == "" {
  return nil
}
  • 要检查切片是否为空,请始终使用len(s) == 0。不要检查 nil。

Bad

func isEmpty(s []string) bool {
  return s == nil
}

vs.

Good

func isEmpty(s []string) bool {
  return len(s) == 0
}

  • 零值切片可立即使用,无需调用make创建。

Bad

nums := []int{}
// or, nums := make([]int)

if add1 {
  nums = append(nums, 1)
}

if add2 {
  nums = append(nums, 2)
}

vs.

Good

var nums []int

if add1 {
  nums = append(nums, 1)
}

if add2 {
  nums = append(nums, 2)
}

缩小变量作用域

如果有可能,尽量缩小变量作用范围。除非它与减少嵌套的规则冲突。

Bad

err := ioutil.WriteFile(name, data, 0644)
if err != nil {
    return err
}

vs.

Good

if err := ioutil.WriteFile(name, data, 0644); err != nil {
    return err
}

如果需要在if之外使用函数调用的结果,则不应尝试缩小范围。

Bad

if data, err := ioutil.ReadFile(name); err == nil {
  err = cfg.Decode(data)
  if err != nil {
    return err
  }

  fmt.Println(cfg)
  return nil
} else {
  return err
}

vs.

Good

data, err := ioutil.ReadFile(name)
if err != nil {
   return err
}

if err := cfg.Decode(data); err != nil {
  return err
}

fmt.Println(cfg)
return nil

避免裸参数

函数调用中的裸参数可能会损害可读性。当参数名称的含义不明显时,请为参数添加C样式注释(/* … */)。

Bad

// func printInfo(name string, isLocal, done bool)

printInfo("foo", true, true)

vs.

Good

// func printInfo(name string, isLocal, done bool)

printInfo("foo", true /* isLocal */, true /* done */)

更好的作法是,将裸bool类型替换为自定义类型,以获得更易读和类型安全的代码。将来,该参数不仅允许两个状态(true/false)。

type Region int

const (
  UnknownRegion Region = iota
  Local
)

type Status int

const (
  StatusReady = iota + 1
  StatusDone
  // Maybe we will have a StatusInProgress in the future.
)

func printInfo(name string, region Region, status Status)

使用原始字符串字面值,避免转义

Go支持原始字符串字面值,可以跨越多行并包含引号。使用这些字符串可以避免更难阅读的手工转义的字符串。

Bad

wantError := "unknown name:\"test\""

vs.

Good

wantError := `unknown error:"test"`

初始化结构体引用

在初始化结构引用时,请使用&T{}代替new(T),以使其与结构体初始化一致。

Bad

sval := T{Name: "foo"}

// 不一致
sptr := new(T)
sptr.Name = "bar"

vs.

Good

sval := T{Name: "foo"}

sptr := &T{Name: "bar"}

格式化字符串放在Printf外部

如果你为Printf-style函数声明格式字符串,请将格式化字符串放在外面,并将其设置为const常量。

这有助于go vet对格式字符串执行静态分析。

Bad

msg := "unexpected values %v, %v\n"
fmt.Printf(msg, 1, 2)

vs.

Good

const msg = "unexpected values %v, %v\n"
fmt.Printf(msg, 1, 2)

命名Printf样式的函数

声明Printf-style函数时,请确保go vet可以检测到它并检查格式字符串。

这意味着您应尽可能使用预定义的Printf-style函数名称。go vet将默认检查这些。有关更多信息,请参见Printf系列

如果不能使用预定义的名称,请以f结束选择的名称:Wrapf,而不是Wrap。go vet可以要求检查特定的Printf样式名称,但名称必须以f结尾。

$ go vet -printfuncs = wrapf,statusf

另请参阅”go vet:Printf家族检查“。

五. 模式

测试表

在核心测试逻辑重复时,将表驱动测试与子测试一起使用,以避免重复代码。

Bad

// func TestSplitHostPort(t *testing.T)

host, port, err := net.SplitHostPort("192.0.2.0:8000")
require.NoError(t, err)
assert.Equal(t, "192.0.2.0", host)
assert.Equal(t, "8000", port)

host, port, err = net.SplitHostPort("192.0.2.0:http")
require.NoError(t, err)
assert.Equal(t, "192.0.2.0", host)
assert.Equal(t, "http", port)

host, port, err = net.SplitHostPort(":8000")
require.NoError(t, err)
assert.Equal(t, "", host)
assert.Equal(t, "8000", port)

host, port, err = net.SplitHostPort("1:8")
require.NoError(t, err)
assert.Equal(t, "1", host)
assert.Equal(t, "8", port)

vs.

Good

// func TestSplitHostPort(t *testing.T)

tests := []struct{
  give     string
  wantHost string
  wantPort string
}{
  {
    give:     "192.0.2.0:8000",
    wantHost: "192.0.2.0",
    wantPort: "8000",
  },
  {
    give:     "192.0.2.0:http",
    wantHost: "192.0.2.0",
    wantPort: "http",
  },
  {
    give:     ":8000",
    wantHost: "",
    wantPort: "8000",
  },
  {
    give:     "1:8",
    wantHost: "1",
    wantPort: "8",
  },
}

for _, tt := range tests {
  t.Run(tt.give, func(t *testing.T) {
    host, port, err := net.SplitHostPort(tt.give)
    require.NoError(t, err)
    assert.Equal(t, tt.wantHost, host)
    assert.Equal(t, tt.wantPort, port)
  })
}

测试表使向错误消息添加上下文,减少重复的逻辑以及添加新的测试用例变得更加容易。

我们遵循这样的约定:将结构体切片称为tests。 每个测试用例称为tt。此外,我们鼓励使用give和want前缀说明每个测试用例的输入和输出值。

tests := []struct{
  give     string
  wantHost string
  wantPort string
}{
  // ...
}

for _, tt := range tests {
  // ...
}

功能选项

功能选项是一种模式,您可以在其中声明一个不透明Option类型,该类型在某些内部结构中记录信息。您接受这些选项的可变编号,并根据内部结构上的选项记录的全部信息采取行动。

将此模式用于您需要扩展的构造函数和其他公共API中的可选参数,尤其是在这些功能上已经具有三个或更多参数的情况下。

Bad

// package db

func Connect(
  addr string,
  timeout time.Duration,
  caching bool,
) (*Connection, error) {
  // ...
}

// Timeout and caching must always be provided,
// even if the user wants to use the default.

db.Connect(addr, db.DefaultTimeout, db.DefaultCaching)
db.Connect(addr, newTimeout, db.DefaultCaching)
db.Connect(addr, db.DefaultTimeout, false /* caching */)
db.Connect(addr, newTimeout, false /* caching */)

vs.

Good

type options struct {
  timeout time.Duration
  caching bool
}

// Option overrides behavior of Connect.
type Option interface {
  apply(*options)
}

type optionFunc func(*options)

func (f optionFunc) apply(o *options) {
  f(o)
}

func WithTimeout(t time.Duration) Option {
  return optionFunc(func(o *options) {
    o.timeout = t
  })
}

func WithCaching(cache bool) Option {
  return optionFunc(func(o *options) {
    o.caching = cache
  })
}

// Connect creates a connection.
func Connect(
  addr string,
  opts ...Option,
) (*Connection, error) {
  options := options{
    timeout: defaultTimeout,
    caching: defaultCaching,
  }

  for _, o := range opts {
    o.apply(&options)
  }

  // ...
}

// Options must be provided only if needed.

db.Connect(addr)
db.Connect(addr, db.WithTimeout(newTimeout))
db.Connect(addr, db.WithCaching(false))
db.Connect(
  addr,
  db.WithCaching(false),
  db.WithTimeout(newTimeout),
)

还可以参考下面资料:


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Go 1.13中的错误处理

$
0
0

介绍

在过去的十年中, Go的errors are values的理念在编码实践中运行得也很良好。尽管标准库对错误处理的的支持很少(只有errors.New和fmt.Errorf函数可以用来构造仅包含字符串消息的错误),但是内置的error接口使Go程序员可以添加所需的任何信息。它所需要的只是一个实现Error方法的类型:

type QueryError struct {
    Query string
    Err   error
}

func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }

像这样的错误类型无处不在,它们存储的信息变化很大,从时间戳到文件名再到服务器地址。通常,该信息包括另一个较低级别的错误以提供其他上下文信息。

在Go代码中,使用一个包含了另一个错误的错误类型的模式十分普遍,以至于经过广泛讨论后,Go 1.13为其添加了明确的支持。这篇文章描述了标准库提供的支持:errors包中的三个新功能,以及fmt.Errorf中添加的新格式化动词。

在详细描述这些变化之前,让我们先回顾一下在Go语言的早期版本中如何检查和构造错误。

Go 1.13版本之前的错误处理

检查错误

错误是值(errors are values)。程序通过几种方式基于这些值来做出决策。最常见的是通过与nil的比较来确定操作是否失败。

if err != nil {
    // 出错了!
}

有时我们将错误与已知的前哨值(sentinel value)进行比较来查看是否发生了特定错误。比如:

var ErrNotFound = errors.New("not found")

if err == ErrNotFound {
    // something wasn't found
}

错误值可以是满足语言定义的error 接口的任何类型。程序可以使用类型断言(type assertion)或类型开关(type switch)来判断错误值是否可被视为特定的错误类型。

type NotFoundError struct {
    Name string
}

func (e *NotFoundError) Error() string { return e.Name + ": not found" }

if e, ok := err.(*NotFoundError); ok {
    // e.Name wasn't found
}

添加信息

函数通常在将错误向上传递给调用堆栈时添加额外错误信息,例如对错误发生时所发生情况的简短描述。一种简单的方法是构造一个新错误,并在其中包括上一个错误:

if err != nil {
    return fmt.Errorf("decompress %v: %v", name, err)
}

使用fmt.Errorf创建的新错误将丢弃原始错误中的所有内容(文本除外)。就像我们在前面所看到的QueryError那样,有时我们可能想要定义一个包含基础错误的新错误类型,并将其保存下来以供代码检查。我们再次来看一下QueryError:

type QueryError struct {
    Query string
    Err   error
}

程序可以查看一个*QueryError值的内部以根据潜在的错误进行决策。有时您会看到称为“展开”错误的信息。

if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
    // query failed because of a permission problem
}

标准库中的os.PathError类型就是另外一个在错误中包含另一个错误的示例。

Go 1.13版本的错误处理

Unwrap方法

Go 1.13在errors和fmt标准库包中引入了新功能以简化处理包含其他错误的错误。其中最重要的不是改变,而是一个约定:包含另一个错误的错误可以实现Unwrap方法来返回所包含的底层错误。如果e1.Unwrap()返回了e2,那么我们说e1包装了e2,您可以Unwrap e1来得到e2

遵循此约定,我们可以为上面的QueryError类型提供一个Unwrap方法来返回其包含的错误:

func (e *QueryError) Unwrap() error { return e.Err }

Unwrap错误的结果本身(底层错误)可能也具有Unwrap方法。我们将这种通过重复unwrap而得到的错误序列为错误链。

使用Is和As检查错误

Go 1.13的errors包中包括了两个用于检查错误的新函数:Is和As。

errors.Is函数将错误与值进行比较。

// Similar to:
//   if err == ErrNotFound { … }
if errors.Is(err, ErrNotFound) {
    // something wasn't found
}

As函数用于测试错误是否为特定类型。

// Similar to:
//   if e, ok := err.(*QueryError); ok { … }
var e *QueryError
if errors.As(err, &e) {
    // err is a *QueryError, and e is set to the error's value
}

在最简单的情况下,errors.Is函数的行为类似于上面对哨兵错误(sentinel error))的比较,而errors.As函数的行为类似于类型断言(type assertion)。但是,在处理包装错误(包含其他错误的错误)时,这些函数会考虑错误链中的所有错误。让我们再次看一下通过展开QueryError以检查潜在错误:

if e, ok := err.(*QueryError); ok && e.Err == ErrPermission {
    // query failed because of a permission problem
}

使用errors.Is函数,我们可以这样写:

if errors.Is(err, ErrPermission) {
    // err, or some error that it wraps, is a permission problem
}

errors包还包括一个新Unwrap函数,该函数返回调用错误Unwrap方法的结果,或者当错误没有Unwrap方法时返回nil。通常我们最好使用errors.Is或errors.As,因为这些函数将在单个调用中检查整个错误链。

用%w包装错误

如前面所述,我们通常使用fmt.Errorf函数向错误添加其他信息。

if err != nil {
    return fmt.Errorf("decompress %v: %v", name, err)
}

在Go 1.13中,fmt.Errorf函数支持新的%w动词。当存在该动词时,所返回的错误fmt.Errorf将具有Unwrap方法,该方法返回参数%w对应的错误。%w对应的参数必须是错误(类型)。在所有其他方面,%w与%v等同。

if err != nil {
    // Return an error which unwraps to err.
    return fmt.Errorf("decompress %v: %w", name, err)
}

使用%w创建的包装错误可用于errors.Is和errors.As:

err := fmt.Errorf("access denied: %w”, ErrPermission)
...
if errors.Is(err, ErrPermission) ...

是否包装

在使用fmt.Errorf或通过实现自定义类型将其他上下文添加到错误时,您需要确定新错误是否应该包装原始错误。这个问题没有统一答案。它取决于创建新错误的上下文。包装错误将会被公开给调用者。如果要避免暴露实现细节,那么请不要包装错误。

举一个例子,假设一个Parse函数从io.Reader读取复杂的数据结构。如果发生错误,我们希望报告发生错误的行号和列号。如果从io.Reader读取时发生错误,我们将包装该错误以供检查底层问题。由于调用者为函数提供了io.Reader,因此有理由公开它产生的错误。

相反,一个对数据库进行多次调用的函数可能不应该将其中调用之一的结果解开的错误返回。如果该函数使用的数据库是实现细节,那么暴露这些错误就是对抽象的违反。例如,如果你的程序包pkg中的函数LookupUser使用了Go的database/sql程序包,则可能会遇到sql.ErrNoRows错误。如果使用fmt.Errorf(“accessing DB: %v”, err)来返回该错误,则调用者无法检视到内部的sql.ErrNoRows。但是,如果函数使用fmt.Errorf(“accessing DB: %w”, err)返回错误,则调用者可以编写下面代码:

err := pkg.LookupUser(...)
if errors.Is(err, sql.ErrNoRows) …

此时,如果您不希望对客户端源码产生影响,该函数也必须始终返回sql.ErrNoRows,即使您切换到其他数据库程序包。换句话说,包装错误会使该错误成为您API的一部分。如果您不想将来将错误作为API的一部分来支持,则不应包装该错误。

重要的是要记住,无论是否包装错误,错误文本都将相同。那些试图理解错误的人将得到相同的信息,无论采用哪种方式; 是否要包装错误的选择是关于是否要给程序提供更多信息,以便他们可以做出更明智的决策,还是保留该信息以保留抽象层。

使用Is和As方法自定义错误测试

errors.Is函数检查错误链中的每个错误是否与目标值匹配。默认情况下,如果两者相等,则错误与目标匹配。另外,链中的错误可能会通过实现Is方法来声明它与目标匹配。

例如,下面的错误类型定义是受Upspin error包的启发,它将错误与模板进行了比较,并且仅考虑模板中非零的字段:

type Error struct {
    Path string
    User string
}

func (e *Error) Is(target error) bool {
    t, ok := target.(*Error)
    if !ok {
        return false
    }
    return (e.Path == t.Path || t.Path == "") &&
           (e.User == t.User || t.User == "")
}

if errors.Is(err, &Error{User: "someuser"}) {
    // err's User field is "someuser".
}

同样,errors.As函数将使用链中某个错误的As方法,如果该错误实现了As方法。

错误和包API

返回错误的程序包(大多数都会返回错误)应描述程序员可能依赖的那些错误的属性。一个经过精心设计的程序包也将避免返回带有不应依赖的属性的错误。

最简单的规约是用于说明操作成功或失败的属性,分别返回nil或non-nil错误值。在许多情况下,不需要进一步的信息了。

如果我们希望函数返回可识别的错误条件,例如“item not found”,则可能会返回包装哨兵的错误。

var ErrNotFound = errors.New("not found")

// FetchItem returns the named item.
//
// If no item with the name exists, FetchItem returns an error
// wrapping ErrNotFound.
func FetchItem(name string) (*Item, error) {
    if itemNotFound(name) {
        return nil, fmt.Errorf("%q: %w", name, ErrNotFound)
    }
    // ...
}

还有其他现有的提供错误的模式,可以由调用方进行语义检查,例如直接返回哨兵值,特定类型或可以使用谓词函数检查的值。

在所有情况下,都应注意不要向用户公开内部细节。正如我们在上面的“是否要包装”中提到的那样,当您从另一个包中返回错误时,应该将错误转换为不暴露基本错误的形式,除非您愿意将来再返回该特定错误。

f, err := os.Open(filename)
if err != nil {
    // The *os.PathError returned by os.Open is an internal detail.
    // To avoid exposing it to the caller, repackage it as a new
    // error with the same text. We use the %v formatting verb, since
    // %w would permit the caller to unwrap the original *os.PathError.
    return fmt.Errorf("%v", err)
}

如果将函数定义为返回包装某些标记或类型的错误,请不要直接返回基础错误。

var ErrPermission = errors.New("permission denied")

// DoSomething returns an error wrapping ErrPermission if the user
// does not have permission to do something.
func DoSomething() {
    if !userHasPermission() {
        // If we return ErrPermission directly, callers might come
        // to depend on the exact error value, writing code like this:
        //
        //     if err := pkg.DoSomething(); err == pkg.ErrPermission { … }
        //
        // This will cause problems if we want to add additional
        // context to the error in the future. To avoid this, we
        // return an error wrapping the sentinel so that users must
        // always unwrap it:
        //
        //     if err := pkg.DoSomething(); errors.Is(err, pkg.ErrPermission) { ... }
        return fmt.Errorf("%w", ErrPermission)
    }
    // ...
}

结论

尽管我们讨论的更改仅包含三个函数和一个格式化动词(%w),但我们希望它们能大幅改善Go程序中错误处理的方式。我们希望通过包装来提供其他上下文的方式得到Gopher们地普遍使用,从而帮助程序做出更好的决策,并帮助程序员更快地发现错误。

正如Russ Cox在GopherCon 2019主题演讲中所说的那样,在Go2的道路上,我们进行了实验,简化和发布。现在,我们已经发布了这些更改,我们期待接下来的实验。

本文翻译自Go官方博客:《Working with Errors in Go 1.13》


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

如何在Ubuntu 18.04 Server上部署Kubernetes集群

$
0
0

如今,你几乎不可避免地会听到来自Kubernetes的发声,你更没有充分的理由拒绝去听。 一旦一切就绪,这个强大的容器编排工具将以您难以想象的敏捷性来扩展您的操作。

为了实际使用Kubernetes进行部署和管理容器,您首先必须创建Kubernetes服务器集群。 一旦集群建立后,您就能够部署,扩展和管理您的容器化应用程序了。

Ubuntu Server 18.04的帮助下,我将引导您完成此过程。 我们至少需要2个Ubuntu Server 18.04实例和一个具有sudo特权的用户帐户才能完成此工作。 您需要确保所有计算机都已做完更新(使用sudo apt-get update和sudo apt-get upgrade -y命令)。

还需要一些时间,大约30分钟左右。

我将在两台机器上进行示范操作:一个master节点和一个worker节点。

我们开始吧!

安装Docker

master节点和worker节点上都需要进行下面的操作。

我们要做的第一件事就是安装Docker。要安装docker,先要登录到Server上,输入并执行下面命令:

sudo apt-get install docker.io

一旦docker安装成功后,你需要将你的账号添加到docker组中(否则,每次运行docker命令,都需要带上sudo,这可能导致安全问题)。执行下面命令将你的账号添加到docker组中:

sudo usermod -aG docker $USER

登出并重新登录,这样上述配置变化才能生效。

启动并使能docker后台驻留程序:

sudo systemctl start docker
sudo systemctl enable docker

安装Kubernetes

现在我们需要在所有节点上安装Kubernetes了。首先,我们通过下面命令添加Kubernetes GPG key:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add

如果没有安装curl,可以通过下面命令安装:

sudo apt-get install curl -y

接下来,添加必要的仓库:

sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

通过下面命令安装必要的软件:

sudo apt-get install kubeadm kubelet kubectl -y

上面的命令将自动安装目标软件以及它们的依赖。

主机名

为了让后续操作更简单,我们通过下面命令为每个server赋予新的主机名。

sudo hostnamectl set-hostname HOSTNAME

HOSTNAME是主机的名字

你可以使用下面这些主机名:

  • kubemaster
  • node1
  • node2
  • node3
  • 其他等等

登出并重新登录。最后,将主机名映射为IP地址。通过下面命令打开host文件并编辑:

sudo nano /etc/hosts

在文件末尾附加类似下面的内容(保证你的主机名与其正确的ip一一对应):

192.168.1.218 kubemaster
192.168.1.219 kubenode1
192.168.1.220 kubenode2

关闭并保存文件。

关闭Swap

要运行kubernetes,你必须首先关闭swap。我们可以通过下面命令来做到这一点:

sudo swapoff -a

如果要使修改永久生效(否则,下次重启时,swap会重新启用),执行下面命令:

sudo nano /etc/fstab

在fstab文件中,将swap入口注释掉,如下图:

img{512x368}
图: 通过fstab关闭swap

初始化Master

接下来,我们通过下面命令来初始化master节点。

sudo kubeadm init --pod-network-cidr=192.168.1.90/16

初始化结束后,你将看到将worker node加入集群的精确命令(如下图),保证要拷贝下该命令:

img{512x368}
图: 将worker node加入master的命令

仅在master上创建下面目录:

mkdir -p $HOME/.kube

将相应的配置你文件拷贝到该目录下:

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

赋予配置文件适当的权限:

sudo chown $(id -u):$(id -g) $HOME/.kube/config

部署Pod网络

在将worker加入到master之前,你必须先部署pod网络(否则,所有事情都无法按照预期那样正常工作)。Flannel是可选的Pod网络之一。我们通过下面命令安装它(仅在master运行下面命令):

sudo kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

将worker node加入到master

现在我们具备将worker node加入master的条件了。登录到worker node上,执行类型下面的命令:

sudo kubeadm join 192.168.1.190:6443 --token bzbwl4.ll5o9x3jjhqqwofa --discovery-token-ca-cert-hash sha256:ecb0223a05be3502c2d102f3e56104b10fcd105430eb723d3b3e816618323d73

在每个worker node上执行join命令。一旦join命令执行成功,返回master node执行下面命令:

kubectl get nodes

你可以看到所有加入到集群的worker node列表:

img{512x368}
图: 我们的node已经加入并处于ready状态

到此,kubernetes集群已经就绪并可以部署你的第一个容器化的应用或服务了。不要忘了,如果你要加入更多worker node(提高伸缩能力),你需要join命令。如果你忘记保存之前那个join命令了,你可以在任何时候通过下面命令获取它:

kubeadm token create --print-join-command

上面命令将输出join命令,在你的新worker node上执行它即可。

本文翻译自《How to Deploy a Kubernetes Cluster with Ubuntu Server 18.04》

文本首次发表在慕课网上。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.


Go 1.13中值得关注的几个变化

$
0
0

2019年对于Go语言来说也是一个重要的年份,因为在2019年的11月10日,Go即将迎来其开源10周年的纪念日。在这个重要日子的前夕,在GopherCon 2019大会后,Go项目组在2019.9.4日发布了Go 1.13版本

img{512x368}

这是自2017年GopherCon大会上Russ Cox“Toward Go 2″主题演讲以来Go项目发布的第四个版本(前三个分别是:go 1.10go 1.11go 1.12)。

Go2是这两年Go项目的核心主题。Go项目组也一直在摸索着向Go2演化的节奏和过程规范,并已经从Go 1.11版本起做出了实质性的动作:添加go module机制错误处理优化泛型讨论和多次草案的发布等。Russ Cox这段时间还在自己的博客上撰写了一系列有关Go proposal流程究竟该如何改进的探索性文章,这与当年vgo“放大招”前的节奏有些相似:)。

回归正题,我们来说Go 1.13这个版本。Go 1.13延续了对之前版本添加的Go2特性:Go module的优化;并且从该版本开始,Go项目组开启了Go2中呼声也很高的错误处理的优化。下面我们详细来看看Go 1.13中值得关注的几个变化。

1. 语言

Go 1.13中,Go语言规范有了一些小变化。

Go在设计伊始就和多数C-Family语言一样继承了C语言关于数字字面量(number literal)的语法形式,和1978年发布的K&R C一样,Go仅支持十进制、八进制、十六进制和十进制形式的浮点数的数字字面量形式,比如:

a := 53        //十进制

b := 0700      // 八进制,以"0"开头
c := 0xaabbcc  // 十六进制 以"0x"开头

c1 := 0Xddeeff // 十六进制 以"0X"开头

f1 := 10.24  // 十进制浮点数
f2 := 1.e+0  // 十进制浮点数
f3 := 31415.e-4 // 十进制浮点数

这些数字字面量语法应该说是够用的,但是和其他语言在进化过程中添加的其他数字字面量表达形式相比,又显得有些不足。于是Go设计者决定在Go 1.13版本中增加Go对数字字面量的表达能力,在这方面对Go语言做了如下补充:

  • 增加二进制数字字面量,以0b或0B开头

  • 在保留以”0″开头的八进制数字字面量形式的同时,增加以”0o”或”0O”开头的八进制数字字面量形式

  • 增加十六进制形式的浮点数字面量,以0x或0X开头的、形式如0×123.86p+2的浮点数

  • 为提升可读性,在数字字面量中增加数字分隔符”_”,分隔符可以用来分隔数字(起到分组提高可读性作用,比如每3个数字一组),也可以用来分隔前缀与第一个数字。

a := 5_3_7
b := 0o700
b1 := 0O700
b2 := 0_700
b3 := 0o_700
c := 0b111
c1 := 0B111
c2 := 0b_111
f1 := 0x10.24p+3
f2 := 0x1.Fp+0
f3 := 0x31_415.p-4

注:截至目前,有些第三方工具依然无法识别数字字面量中的分隔符,会误报其为语法错误。

Go 1.13中关于语言规范方面的另一个变动点是取消了移位操作(>>的<<)的右操作数仅能是无符号数的限制,以前必须的强制到uint的转换现在不必要了:

var i int = 5

fmt.Println(2 << uint(i)) // before go 1.13
fmt.Println(2 << i)       // in go 1.13 and later version

不过值得注意的是:go 1.12版本在go.mod文件中增加了一个go version的指示字段,用于指示该module内源码所使用的 go版本。Go 1.13的发布文档强调了只有在go.mod中的go version指示字段为go 1.13(以及以后版本)时,上述的语言特性变更才会生效,否则就会报类似下面的错误:

// github.com/bigwhite/experiments/go1.13-examples/number_literal.go

$go run number_literal.go
# command-line-arguments
./number_literal.go:23:7: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:24:7: 0o/0O-style octal literals only supported as of -lang=go1.13
./number_literal.go:25:8: 0o/0O-style octal literals only supported as of -lang=go1.13
./number_literal.go:26:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:27:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:28:7: binary literals only supported as of -lang=go1.13
./number_literal.go:29:8: binary literals only supported as of -lang=go1.13
./number_literal.go:30:8: underscores in numeric literals only supported as of -lang=go1.13
./number_literal.go:31:8: hexadecimal floating-point literals only supported as of -lang=go1.13
./number_literal.go:32:8: hexadecimal floating-point literals only supported as of -lang=go1.13
./number_literal.go:32:8: too many errors

// github.com/bigwhite/experiments/go1.13-examples/shift_with_signed_operand.go

$go run shift_with_signed_operand.go
# command-line-arguments
./shift_with_signed_operand.go:8:16: invalid operation: 2 << i (signed shift count type int, only supported as of -lang=go1.13)

当然,如果repo下没有go.mod或者单独在某个没有go.mod的目录下使用go 1.13编译器运行上面代码,则是无问题的。

2. Go module机制的继续优化以及行为变化

Go module自Go 1.11版本加入Go以来收到了Go社区的大量反馈,Go核心团队也针对这些反馈对Go module机制进行了持续地优化。在Go 1.13中,Go module的一些改变如下:

1) GO111MODULE=auto的行为变化

在Go 1.12版本中,GO111MODULE默认值为auto,在auto模式下,GOPATH/src下面的repo以及在GOPATH之外的repo依旧使用GOPATH mode,不使用go.mod来管理依赖;在Go 1.13中,module mode优先级提升,GO111MODULE的默认值依然为auto,但在这个auto下,无论是在GOPATH/src下还是GOPATH之外的repo中,只要目录下有go.mod,go编译器都会使用go module来管理依赖。

2) GOPROXY有默认初值并支持设置成多个代理的列表

之前版本中,GOPROXY这个环境环境变量默认值为空,go编译器都是直接与类似github.com这样的代码托管站点通信并获取相关依赖库的数据的;一些第三方GOPROXY服务发布后,迁移到go module的gopher们发现:大多数情况下通过proxy获取依赖包数据的速度要远高于直接从代码托管站点获取,因此GOPROXY总是会配置上一个值。Go核心团队也希望Go世界能有一个像nodejs那样的中心化的module仓库为大家提供服务,于是在Go 1.13中将https://proxy.golang.org作为GOPROXY环境变量的默认值之一,这也是Go官方提供的GOPROXY服务。

同时GOPROXY支持设置为多个proxy的列表(多个proxy之间采用逗号分隔),Go编译器会按顺序尝试列表中的proxy以获取依赖包数据,但是当有proxy server服务不可达或者是返回的http状态码不是404也不是410时,go会终止数据获取。

Go 1.13中,GOPROXY的默认值为https://proxy.golang.org,direct。当官方代理返回404或410时,Go编译器会尝试直接连接依赖module的代码托管站点以获取数据。

由于国内无法访问Go官方的proxy,因此我一般会将我的工作环境下的GOPROXY设置为:

export GOPROXY=https://goproxy.cn,自己在国外主机使用athens搭建的代理,direct

3) GOSUMDB

我们知道go会在go module启用时在本地建立一个go.sum文件,用来存储依赖包特定版本的加密校验和。同时,Go维护下载的软件包的缓存,并在下载时计算并记录每个软件包的加密校验和。在正常操作中,go命令对照这些预先计算的校验和去检查某repo下的go.sum文件,而不是在每次命令调用时都重新计算它们。

在日常开发中,特定module版本的校验和永远不会改变。每次运行或构建时,go命令都会通过本地的go.sum去检查其本地缓存副本的校验和是否一致。如果校验和不匹配,则go命令将报告安全错误,并拒绝运行构建或运行。在这种情况下,重要的是找出正确的校验和,确定是go.sum错误还是下载的代码是错误的。如果go.sum中尚未包含已下载的module,并且该模块是公共module,则go命令将查询Go校验和数据库以获取正确的校验和数据存入go.sum。如果下载的代码与校验和不匹配,则go命令将报告不匹配并退出。

Go 1.13提供了GOSUMDB环境变量用于配置Go校验和数据库的服务地址(和公钥),其默认值为”sum.golang.org”,这也是Go官方提供的校验和数据库服务(大陆gopher可以使用sum.golang.google.cn)。

出于安全考虑,建议保持GOSUMDB开启。但如果因为某些因素,无法访问GOSUMDB(甚至是sum.golang.google.cn),可以通过下面命令将其关闭:

go env -w GOSUMDB=off

GOSUMDB关闭后,仅能使用本地的go.sum进行包的校验和校验了。

4)面向私有模块的GOPRIVATE

有了GOPROXY后,公共module的数据获取变得十分easy。但是如果依赖的是企业内部module或托管站点上的private库,通过GOPROXY(默认值)获取显然会得到一个失败的结果,除非你搭建了自己的公私均可的goproxy server并将其设置到GOPROXY中。

Go 1.13提供了GOPRIVATE变量,用于指示哪些仓库下的module是private,不需要通过GOPROXY下载,也不需要通过GOSUMDB去验证其校验和。不过要注意的是GONOPROXY和GONOSUMDB可以override GOPRIVATE中的设置,因此设置时要谨慎,比如下面的例子:

GOPRIVATE=pkg.tonyba.com/private
GONOPROXY=none

GONOSUMDB=none

GOPRIVATE指示pkg.tonybai.com/private下的包不经过代理下载,不经过SUMDB验证。但GONOPROXY和GONOSUMDB均为none,意味着所有module,不管是公共的还是私有的,都要经过proxy下载,经过sumdb验证。前面提到过了,GONOPROXY和GONOSUMDB会override GOPRIVATE的设置,因此在这样的配置下,所有依赖包都要经过proxy下载,也要经过sumdb验证。不过这个例子中的GOPRIVATE的值也不是一无是处,它可以给其他go tool提供私有module的指示信息。

3. Go错误处理优化迈出第一步

Go核心团队早在一年前就提出了关于go错误处理的多个proposal,其中涉及解决if err != nil 大量重复问题的,有解决错误包装(wrap)问题的,有解决error value比较问题的。在Go 1.13中,Go核心团队落实了后两个:

  • 通过标准库增加了errors.Is和As函数来解决error value比较问题

  • 增加errors.Unwrap来解决error unwrap问题。

并且Go通过在fmt.Errorf中新增的”%w”动词来协助Gopher快速创建一个包装错误,创建的error变量实现了下面接口:

interface { // 一个匿名接口

    Unwrap() error

}

关于Go 1.13中错误处理的改进,Go官方发表了一篇博客《Go 1.13中的错误处理》给出了十分详尽的说明,这里就不赘述了。

4. 性能

个人觉得Go 1.13中能带来性能提升的变动主要有三个:

第一个就是defer的性能提升。

defer语法让Gopher在进行资源(文件、锁)释放的过程变动优雅很多,也不易出错。但在性能敏感的应用中,defer带来的性能负担也是Gopher必须要权衡的问题。在Go 1.13中,Go核心团队对defer性能做了大幅优化,官方给出了在大多数情况下,defer性能提升30%的说法。

这里可以来验证一下:我们使用Go 1.13和Go 1.12.7两个版本运行同一个benchmark(macos 1.6G 8核 16G内存):

// github.com/bigwhite/experiments/go1.13-examples/defer_benchmark_test.go

package defer_test

import "testing"

func sum(max int) int {
        total := 0
        for i := 0; i < max; i++ {
                total += i
        }

        return total
}

func foo() {
        defer func() {
                sum(10)
        }()

        sum(100)
}

func BenchmarkDefer(b *testing.B) {
        for i := 0; i < b.N; i++ {
                foo()
        }
}

go 1.13下的benchmark结果:

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8       17341530            67.3 ns/op
PASS
ok      command-line-arguments    1.245s

go 1.12.7下的benchmark结果:

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8       20000000            76.5 ns/op
PASS
ok      command-line-arguments    1.618s

我们看到性能的确有提升,但没有到30%这么大幅度,也许这仅仅是一个个例吧。
第二个是优化后的逃逸分析(escape analysis)让编译器在选择究竟将变量分配在stack上还是heap上的时候更加精确。在老版本里分配到heap上的变量,在Go 1.13中可能就会分配到stack上,从而减少内存分配的次数,一定程度上减轻gc的压力,达到性能提升的目的。

第三个是sync包中Mutex、RWMutex的方法的inline化带来的性能提升,官方说法是10%。我们同样来benchmark一下:

// github.com/bigwhite/experiments/go1.13-examples/mutex_benchmark_test.go

package mutex_test

import (
        "sync"
        "testing"
)

func sum(max int) int {
        total := 0
        for i := 0; i < max; i++ {
                total += i
        }

        return total
}

func foo() {
        var mu sync.Mutex
        mu.Lock()
        sum(10)
        mu.Unlock()
}

func BenchmarkMutex(b *testing.B) {
        for i := 0; i < b.N; i++ {
                foo()
        }
}

Go 1.13下的结果:

$go test -bench . mutex_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkMutex-8       43395768            26.4 ns/op
PASS
ok      command-line-arguments    1.182s

Go 1.12.7下的结果:

$go test -bench . mutex_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkMutex-8       50000000            28.4 ns/op
PASS
ok      command-line-arguments    1.457s

从结果看,提升在7%左右,约等于10%吧。

5. 其他变化

简单罗列一些我认为值得关注的小变化:

  • Go 1.13现在支持Android 10了;对MacOS的支持需要至少10.11版本;

  • godoc不再和go、gofmt放入go release版中,需要godoc的,需要单独从golang.org/x/tools/cmd/godoc中下载安装;

  • crypto/tls默认开启tls 1.3支持;

  • unicode包支持的unicode标准从10.0版本升级到Unicode 11.0版本

6. 小结

Go 1.13版本的发布标志着Go向着Go2的目标又迈出了坚实的一步,Go的演化节奏也是恰到好处:

  • go module已经落地成型,逐渐打磨到成熟;

  • 错误处理:迈出阶段性的一步,后续持续改进

  • Go generics: 是Go2最大的”挑战”。我们看到在GopherCon 2019大会上,Ian Lance Taylor带来的有关Go generics的proposal的改进正在被越来越多Gopher所认可。

不过按照go team的行事风格,任何一个proposal都会经历”实验,简化和发布”的步骤,Go generics还有很长的路要走,让我们共同期待!

本文中涉及的样例源码可以在这里获取到。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Go语言的遗产

$
0
0

本文是gohugo作者Steve Francia在意大利佛罗伦萨举办的GoLab上分享的闭幕演讲讲稿的文字版,该演讲的主题为”Go的遗产”。该演讲讨论了Go语言继承的遗产,以及它是如何尊重这些遗产的,并在最后总结了Go希望留给后来者的遗产。

img{512x368}

演讲胶片

我们有责任保留好留给我们的遗产,并留下值得我们子孙后代继承的遗产 – 克里斯汀·格雷格(Christine Gregoire)

1. Go语言之前

img{512x368}

1950年

在1950年代后期,人们对每台新计算机如何产生自己独特的语言而感到不安。当时,编程语言是由硬件制造商提供的,并且因型号而异。跨计算机且保持一致的第一门编程语言是Fortran,但这仍然仅适用于其制造商IBM(生产的计算机)。而后,人们成立了一个委员会,该委员会的使命就是设计第一种真正通用的、独立于机器的编程语言。

img{512x368}
图:编程语言历史Babel塔,CACM封面,1961年1月

1960年

1960年1月,有13位计算机科学家在巴黎举行了一次空前的会议,旨在(设计)开发出这样一种语言。美国派出了6位代表,欧洲派出了7位代表。

会议上无休止、令人振奋的讨论也让科学家们筋疲力尽。当一个人的好主意与他人的坏主意一起被抛弃时,一个人就会变得更加恼火。然而,在整个会议期间内,大家都没有懈怠,持续地努力投入着。

最终这13名科学家的思想碰撞产生了良好的化学反应 – Alan Perlis

Algol

img{512x368}

这是一种远远超越其时代的语言,它不仅是对其前辈的一种改进,而且对其所有后继者也产生了重大影响。- Tony Hoare关于编程语言设计的提示– 1973年

img{512x368}

之后,原本一脉相承的语言出现了分裂:

  • Pascal这一分支在欧洲蓬勃发展,有许多继任者,包括ModulaOberon

img{512x368}

  • C语言在美国激增,激发和促进了C++、C#、Java以及JavaScript、Python、Perl、PHP和许多其他语言的诞生和发展。

img{512x368}

  • 到2007年,存在的数十种编程语言都可以追溯到其共同祖先:Algol。

img{512x368}

1964年

我们的并发故事始于Doug McIlroy,他在1964年提出了一些新的想法,这些想法最终演化为Unix Pipes。

当有必要以另一种方式处理数据时,我们应该有一些耦合程序的方法,例如像将花园软管拧入另一部分那样。这也是IO的方式。- Doug McIlroy

背后故事

在1970年至1972年的一段时间内,我不时说:“如何做这样的事情?”,然后我提出了另一个建议,另一个建议,另一个建议。有一天,我想出了一种shell语法用于支持管道使用,Ken说:“我要去实现它!”他厌倦了听到所有这些内容……[并且]他说,“要去实现它”。他没有完全按照我为管道系统调用所建议的去做。他发明了一种更好一点的东西,终于又改变了今天的样子。他在一夜之间将管道符放入了Unix(并且他做到了)……。

麦克罗伊(McIlroy)引述:布赖恩(Brian)的墙上还挂着一张纸,在那张纸上我谈到了像花园软管那样将流(stream)拧在一起。所以这个想法在我脑海中徘徊了很长时间。

同时,在Thompson和Ritchie在黑板上,草拟了一个文件系统,我正在草拟如何在黑板上进行数据处理,方法是将一系列过程串联在一起,并寻找一种将过程连接在一起的前缀表示法语言。之所以失败,是因为很容易说出“cat into grep into……”或“who into cat into grep”等等。这么说很容易,而且从一开始就很清楚,这就是您想说的。但是这些命令具有所有这些附带的参数。它们不仅具有输入和输出参数,还具有选项,并且在语法上还不清楚如何将这些选项插入以前缀表示法编写的链中,比如:cat(grep(who …))。在句法上很多人不知道如何做。所以我把这些非常漂亮的程序写在黑板上,用的语言不够强大,无法应付现实。因此,我们实际上并未这样做。

1978年

到1978年,在对多处理器进行编程的背景下,有许多提议的方法被用于通信和同步。共享内存是最常见的通信机制。

托尼·霍尔(Tony Hoare)发表了一篇论文,该论文改变了一切。它比时代提前了几十年。他称他的论文为:”通讯顺序进程,communicating sequential processes”,就是大家熟知的CSP。

img{512x368}

  • 进程(Processes):执行单元
  • 顺序(Sequential):每个进程都作为一个普通的单线程程序运行
  • 通讯(Communicating):进程如何协调
  • 没有内存共享
  • 没有线程,没有互斥体

Hoare的论文提出了一种语言,每个进程(或者作为一个普通的单线程程序)按顺序执行,通过无缓冲通道(unbuffered channel)相互通信。Hoare的通信进程比典型的Unix Shell管道更通用,因为它们可以以任意模式连接。

img{512x368}

三个语言分支因Hoare的CSP论文而诞生:ErlangOccamNewsqueak

  • 1983年诞生的Occam最接近CSP论文(由Hoare推荐)
  • Erlang在80年代后期专注于CSP的功能方面,并使用mailbox在进程之间进行通信
  • Rob Pike(Newsqueak之父)追逐了并发白鲸(the concurrency white whale)长达20年

img{512x368}

Go是第一种可以同时拥有欧洲和美国语言设计分支传统的语言。实际上,它已经统一了这三个分支

2016年,黑客新闻评论(Hacker News)上的一则帖子称Go语言时停留在70年代的一种语言,这引起了一些对Go的批评……

2. 对过去伟大思想的复兴

img{512x368}

编程语言发展的四波浪潮

img{512x368}

  • 第一波浪潮:语言扩张 – 巴别塔

特征:多样化。很久以前,语言是多种多样的,并在在思想、方法和意见等方面体现出多样性。

  • 第二波浪潮:语言的标准化

特征:快速、复杂且对开发不友好。语言的标准化发生了数十年。到2000年代,事情开始停滞。他们融合为两个阵营:Java/JVM和C/CLR。C++、Java、C#都非常相似。

  • 第三波浪潮:脚本语言

特征:慢、不安全但对开发友好。脚本语言作为对上述语言的复杂性和痛苦的回应而应运而生。它们开发快速而松散,对开发人员友好,但缺乏性能和安全性。

  • 第四波浪潮:恢复

特征:快速、安全、对开发人员友好

Go是对这些语言的复杂性和痛苦的一种反应,也是对脚本语言快速开发和松散本质的反应。

Go恢复了早期语言的简单性和灵活性,增加了现代语言的安全性和开发友好性。Go以一种非常真实的方式复兴了许多伟大的想法,这些想法终于准备就绪。

Go给人的感觉就像是来自60年代,70年代,80年代,90年代,00s,10年代的语言……Steve Francia 2019

Go感觉像这样是因为它由过去60年来的许多伟大构想组成。

img{512x368}

现在,我想谈谈Go中的3种特定功能(简单、并发和Go的OO)以及这些思想起源的4种语言(Oberon、Newsqueak、Simula和Smalltalk)。在Go恢复它们之前,许多思想被遗忘了。

1988年

简单易读的结构和语法: Oberon&C

Niklaus Wirth负责Algol-W,Pascal,Modula。现在是1988年,他的最新语言是Oberon

Oberon的程序结构,以“hello, world”例子为例:

MODULE hello;

IMPORT Out;

BEGIN
    Out.String("Hello, World"); Out.Ln
END hello.

Oberon围绕着爱因斯坦(Albert Einstein)的座右铭设计:“使事情尽可能简单,但不要过于简单。”

程序结构非常简单。

下面是Go的”hello world”程序结构:

package main

import "fmt"

func main(){
    fmt.Println"hello world")
}

这个例子看起来应该很熟悉,它直接采用Oberon的结构。

我们再来看看Oberon的声明结构

CONST n = 42;
TYPE mystring = ARRAY 32 OF CHAR;
VAR s: mystring;

PROCEDURE squared(x:INTEGER):INTEGER;
BEGIN
    RETURN x * x
END squared;
VAR b,c: INTEGER = 1,2;

再来看看Go的声明结构:

const n = 42

type mystring string

var s mystring

func squared(x int) int {
    return x*x
}

var b, c int = 1, 2

在Go和Oberon中,声明都是从左到右(名称,类型,可选值),这恰与C相反,在C语言中,类型放在前面。

很多人看到Go后会问为什么我们要翻转C语法,他们错误地认为Go的声明结构来自C语言。它不是,它来自Oberon。

Go使用了Oberon形态,但却用C的token:

  • {}代替BEGIN END
  • ++,– 代替(内置)的INC和DEC
  • != 代替#
  • %代替MOD
  • || 代替OR
  • []代替ARRAY
  • 结构体代替RECORD
  • *代替POINTER TO

虽然结构来自Oberon,但Go使用的token却来自C。

  • 这里没有太多,这就是重点。语法和结构都很简单。
  • 没有继承,没有层次。没有复杂的作用域(scope)系统。
  • 它们尽可能简单,但并不过于简单。

您可以看到Go如何采用Oberon的简单结构,但是删除了笨拙的语法,并采用C语言的更加优雅和熟悉的语法替换了它们。

这样做的结果是一种非常易读的语言诞生了。

1989年

并发与Newsqueak

罗伯·派克(Rob Pike),他于1989年在贝尔实验室工作。他在这里设计了Newsqueak

  • Newsqueak是一门用于研究和探索的编程语言
  • 它致力于在Sequeak基础上添加实用的、切实可行的并发(concurrency)支持
  • Newsqueak语法上类似C
  • 像CSP一样,Newsqueak使用Channel作为Process的集合点

Rob Pike的Newsqueak在语法上看起来像C,但对并发支持的更好。Squeak用于设计菜单和滚动条之类的设备,Newsqueak解决了同样的问题,但涉及范围更广:Newsqueak用于编写整个应用程序,尤其是窗口系统。

Newsqueak-Prime Sieve pt.1

译注:Rob Pike拿手的素数筛例子

counter := prog(end: int, c: chan of int) {
    i: int;
    for(i = 2; i<end; i++) c<-=i;
};

filter := prog(prime: int, listen, send: chan of int) {
    i: int;
    for(;;)
        if((i=<-listen)%prime)
            send<-=i;
};

Newsqueak-Prime Sieve pt.2

sieve := prog(c: chan of int) {
    for(;;) {
        prime := <-c;
        print(prime, “ “);
        newc := mk(chan of int);
        begin filter(prime, c, newc);
        c = newc;
    }
};

count := mk(chan of int);

begin counter(10000, count);
sieve(count);

与CSP和Squeak不同,Newsqueak将channel视为一等公民:channel可以存储在变量中,可以作为参数传递给函数,甚至channel自身也可以通过channel发送。

另外”<-c(receive)”表达式也是第一次在这里介绍。

channel和routine

Go:

c := make(chan int)
c <- 1
x = <-c
go f(x)

vs.

Newsqueak:

c := mk(chan of int);
c <- = 1;
x = <-c;
begin f(x);

我们看到:Go的并发方法几乎与Newsqueak完全相同,channel和 goroutines的使用方式也是相同的。

select

Newsqueak还使用了看起来与Go的select语句非常相似的select。

select {
    case msg1 = <-c1:
        print(“received”, msg1, “\n”);
    case msg2 = <-c2:
        print(“received”, msg2, “\n”);
}

您可以清楚地看到Go并发的基础在25年前是如何在Newqueak中被建立起来的。Go采纳了这些”老想法”,并对其进行了改进,使其可以投入生产。

Ryan Dahl: Node.js的创建者的访谈(2017)

我喜欢Go的编程模型。使用goroutine是如此简单和有趣……如果您要构建服务器,那么我无法想象使用Go以外的任何工具。Goroutine使Go的并发变得简单。

1965年

面向对象基础(Smalltalk)

OO在C++/Java之前就已存在,在C++和Java重新定义面向对象之前。

什么是面向对象?

  • 附加到数据对象的过程(Procedure)
  • Procedure的可重用性

Procedure+数据

img{512x368}

Simula继承了Algol,并在其中添加了对象,类,继承和子类。 Simula被认为是第一种面向对象的编程语言,并且在Smalltalk和所有随后的OO语言的开发中具有重要的影响力。

Simula改变了一直以来的从Procedure的角度来看的思维方式,…他将其翻转为…面向对象的视角,即在每种类型的对象中,您都有处理它的所有方法。- Small Talk的实现者Dan Ingalls

1980

接下来是Smalltalk,其中一切都是对象,并且仅通过发送消息与对象进行通信。

img{512x368}

我确实发明了“面向对象”这个术语,但这是一个错误的选择,因为它没有强调消息发送这个更重要的思想。 – Alan Kay: 从A到Z的编程语言:Smalltalk-80 – 2010

1989年

Procedure重用

我们将讨论两个出版物:

如果系统的任何部分取决于另一部分的内部结构,那么复杂度会随着系统大小的平方而增加 – Dan Ingalls面向对象编程— 1989年

继承。 我们看到了继承带来的这种指数级复杂性

对于使用半新的OO语言进行编程的任何人,这应该看起来都很熟悉。关系线无处不在。 – SPAGHETTI CODE的诞生

论文《强类型面向对象编程的接口》中所提到的系统提供了Ada和Modula-2之类的语言中的模块接口的优点,同时保留了可表达性,使无类型的面向对象的语言(如Smalltalk)具有灵活性。

Go interfaces

type Point interface {
    X() int
    Y() int
    Move(int,int)
    Point Equal(Point) bool
}

Go团队在实现interface时并不知道到该论文的存在。由于这两种方法的明显相似性,后来与他们share了该论文。

Go采取了非常相似的方法,但是对上面论文中想法进行了改进,因为Go接口是隐式的,这使Go应用程序解耦并提供了极大的灵活性。

当您尝试分解一个复杂的问题时,您想要尝试将其分解为尽可能少的部分,并且希望它们尽可能独立。 – Dan Ingalls 面向对象编程— 1989

Go的interface和method采用尽可能独立的方式。只要添加正确的方法,任何类型都可以满足任何接口。可以在满足该接口的类型之前或之后定义一个接口。事实证明,这种方式是有效的,而且效果很好。

Go的OO

  • method提供任何类型的消息发送机制
  • 接口通过动态调度多态性提供可重用性

Go提供了像Smalltalk定义的那种面向对象编程,只是更加贴近实际,即使它不包含类,对象或继承。

  • Smalltalk: OO是关于消息发送
  • Go的interface允许方法像Smalltalk的消息一样自由使用,但是是在一种有类型的语言中使用

3. Go的设计哲学

img{512x368}

2007年

在一次耗时45分钟的C++构建过程中……

罗勃·派克:把时钟拨回到2007年9月,当时我正在对一个巨大的谷歌C++程序做一些微小但重要的优化工作,你们都与这个庞大的程序做过交互。我得这个编译过程在我们的巨大的分布式编译集群上跑了约45分钟。我收到一条消息:为C++标准委员会服务的几位Google员工将进行一个演讲,他们将告诉我们C++ 11的新功能。

在一个小时的演讲中,我们听到了有关计划中的35个新功能的消息。……这时我问自己一个问题:”C++委员会真的相信C++的不足之处在于它没有足够的功能吗?” 当然……,简化语言而不是为其添加更多功能将是一个更大的成就。Rob Pike和他的办公室同事(Robert Griesemer、Ken Thompson)回到了办公桌前。这真的让他们开始思考…

现代实用的编程语言应该是什么样?到45分钟构建完成时,他们已经有了一个充满想法的白板。

语言设计的进化过程

我们从头开始构建,仅从C中借鉴了一些小东西,例如运算符和大括号,以及一些通用关键字。当然,我们还借鉴了我们所知道的其他语言的想法。- 罗伯·派克(Rob Pike)

少即是(指数级的)多 – 2012年,在谈到Go的灵感时 Rob Pike

Go的众多祖先和对Go有影响的语言:

img{512x368}

我要说的是,没有哪位语言设计师比这三位语言设计师(Rob Pike, Robert Griesemer, Ken Thompson) 具有更广泛或更深的语言设计专业知识。他们对以前发生的事情有很丰富的了解,他们知道该采摘什么。他们还具有事后观察的优势(后发优势)。这是修复他们认为可以做得更好的事情的机会。

进化不是革命

  • 原则1:大多数思想都来自先前的思想

大多数思想根本不是新事物

进化不是革命:新语言应该巩固而不是发明新特性

等待良好的设计

  • 原则2:No是暂时的,Yes是永远的。

在Go的整个历史中,有很多这样的实例。通常的想法是,在设计语言时,不会出现“撤消(undo)”的情况。如果您今天说“No”,那么您明天总是可以说“Yes”,但是如果今天您说“Yes”,那么您将在很长一段时间或永远被它“困”住…。

如有疑问,请将其排除在外。- Joshua Bloch:关于设计的对话– 2002

共识驱动的设计

  • 原则3: 应该使一切都尽可能简单,但不要过于简单。-爱因斯坦

当我们三个人开始时,这纯粹是研究。…我们从一个想法开始,即我们三个人都必须针对该语言的每个特性进行讨论,因此,无论出于何种原因,都不会在该语言中放入多余的垃圾。 – 肯·汤普森(Ken Thompson)访谈– 2011年,肯从Bell Labs学习了这种做法

有两种构建软件设计的方法。一种方法是使其变得如此简单,以至于显然没有缺陷。另一种方法是使其变得如此复杂,以至于没有明显的缺陷。 – 托尼·霍尔(Tony Hoare)皇帝的旧衣服-1981年,Go采取了第一种方法,而大多数其他语言都采用第二种方法。

快速迭代期待并实现大规模改变

  • 最后一个原则是快速迭代的原则。

当您处于语言的设计阶段时,您将需要进行频繁且有时是巨大的更改。朝着这个期望前进,并围绕它建立您的流程。

4. 今天的Go

img{512x368}

我们来看Go如今是如何演变的。

2019年

Go今天是如何继续进行演化的。

上面的4条原则在该语言的初期,在发行稳定版之前和被采用之前都非常有效。

但我们现在的处境非常不同。我们不再能够将所有贡献者都放在白板上,甚至不能放在如此大的房间中(译注:Go目前的contributor数量庞大)。

现在,我想与大家分享Go项目今天如何进行更改的。

我们的原则是“等待良好的设计”,这似乎意味着这是一种消极的活动,但这与事实相去甚远。真正的意思是,除非我们非常有信心采用正确的方法,否则我们不会接受更改。

这意味着所有问题的默认答案是“否”。“是”的成本非常高,因此需要一个压倒性的理由。

对一件事说“Yes”意味着对其他一切都说“No”。

软件复杂性的主要原因是供应商不加批判地采用了用户想要的几乎所有功能。人们似乎将复杂误解为先进。

不可理解的应该引起怀疑而不是钦佩。- Niklaus Wirth, 1995年

我们对Go进行了长期展望。为下一个十年或两个或更多个而设计。大多数项目的运行时间要短得多,因此通常会接受第一个可通过的解决方案。

随着时间的流逝,经过长时间这种训练的人们已经意识到:如果一个好主意会被接受,或者反之,不好的主意会被拒绝。

由于我们的长期观点,在为Go项目做出贡献时人们挣扎并不罕见。当他们的想法不能被接受时,许多人感到被亲自拒绝。

或更糟糕的是,人们会感到自己不合格或不称职。我记得有这种感觉。

几年前,我创建了一个网站引擎Hugo,随着时间的推移,它成为Go模板的第一用户,并在此过程中发现了几个问题。尽管如此,我感到非常没有资格报告这些问题,因为我认为创建这些库的“专家”显然比我了解更多,并且我无能为力。在第一次或第二次Gophercon上,我碰巧在午餐台上站在Russ Cox旁边,我们开始交谈。他强烈鼓励我报告这些问题,并让我知道他们多么地需要反馈。

几年后,我加入了Go团队,并从这个经验中学到了很多。我观察到的一件事是,Go团队那些加入较久的核心成员有一件事比大多数其他成员都做得更好,这可能不是您的想法。Go团队的老成员已经非常习惯于听到“不”的声音。我们团队成员的提议被拒绝的比率很高,甚至高于Go团队之外的提议。我们已经了解到,每个“No”都与拥有正确的“Yes”仅一步之遥。

因为我们经常听到“No”的声音,所以我们同情别人被拒绝的感觉。

今天我要传达给您的信息是您受到重视和需要。请继续尝试。在接下来的十年或二十年或更长的时间内,您是Go演化的关键部分。

Go开发流程

Go开发流程

实验流程简化始于今年早些时候,Russ Cox谈论了我们用来对Go进行更改的流程以及它的演变方式。在演讲中,他讨论了实验的两个步骤,并简化了我们的迭代过程。

我们的过程不是为了速度而建立的,而是为了正确。我们花费大量时间进行实验和简化,然后完善自己的想法,直到它们正确为止。

你们都是Go伟大实验的一部分,并且是继续构建Go的过程的关键部分

我想与大家分享3种方法,每个人都可以为Go做出贡献。

  • 使用Go -> 识别问题 -> 您遇到的事情/体验并写下来。
  • 您有想法-> 编写建议 -> 纳入反馈
  • 您阅读提案 -> 阅读评论 > 添加您的声音

img{512x368}

Go开发过程:实验 -> 简化 -> 最终交付。通过此提炼过程,想法将准备就绪,我们将进行交付。我想对过程的这一部分及其工作原理提供更多见解。

共识驱动的设计

  • 误解:谷歌有一小群“决策者”
  • 真相:评论者之间达成共识

关于提案过程的事实

  • 事实上,大多提案提案都很小
  • 几乎所有提案的讨论最终都在参与者(评论员)之间达成了共识。
  • 提案审核委员会主要进行一些“园艺劳动”(译者:社区行为培养)

您看到这不是一件非常迷人的工作。我们评论的大多数问题都要求您澄清问题或什么也不做,让对话继续进行。我们还会考虑谁在对话中丢失,并邀请他们加入对话。

当讨论似乎已经解决(赞成或反对)时,我们将关闭其中的一小部分。

让我们看一下最近的一个建议。这只是从最近提案池中随机选取的一个。

它具有一些有趣的属性:大量参与,来自9个参与者的25条评论引用用户问题(体验)。早期该issue尚无共识(由点赞决定)。

在对该想法进行讨论和完善之后,很明显已经达成了普遍共识。

它被标记为“可能接受”,并且留下足够的时间窗口允许任何人提供我们不接受的理由。

这是一组最近审核的提案。您会注意到,他们每个人都引用了之前的评论,并根据这些评论提出了建议。

在提案审核委员会中,通常会有一个人留下评论,但代表所有出席者。Russ Cox通常志愿承担了这个角色,这就是为什么所有这些issue上面都加上他的名字的原因。在大多数情况下,此窗口不会附加注释。我们觉得这个窗口虽然很少使用,但对于建立共识的过程至关重要。

变化是缓慢发生的

这是设计使然。这是缓慢的、谨慎和有条不紊的,以确保我们最终达到想要的目标。

过去十年的主要里程碑

尽管Go的变化缓慢,但增长迅速。我想了解一下过去十年中的一些主要里程碑。

img{512x368}

  • 2009年, Go语言开源,Gopher诞生,Go脱离了Google的实验场;
  • 2010年,获得年度TIOBE语言,Bossie奖,引入append和go tour;
  • 2011年,gccgo合并到GCC中,引入gofix,YouTube在生产中采用了Go;
  • 2012年,Go 1.0发布!发布Go1兼容性承诺;在Google内部发布第一项Go生产服务

img{512x368}

  • 2013年,Packer,Docker,Hugo用Go编写;6个月发布周期;第一个Go大会举行(日本东京)
  • 2014年,Kubernetes使用Go开发;代码仓库由Mercurial→Git;第一次美国和欧洲会议;Go项目贡献者达到500名;
  • 2015年,Go编译器使用Go重写,实现自举;GC精化; Women Who Go&GoBridge born; 印度、中国第一次go大会举行;
  • 2016年,支持HTTP/2和Context;第一次拉丁&中东Go大会举行;最受喜欢的5门编程语言;第一次Go用户调查;贡献者达1000名;

img{512x368}

  • 2017年,GC小于ms级的暂停; 引入type alias;开发人员想要使用编程语言第一名第一次); 13次会议; 第一届贡献者峰会
  • 2018年,引入Go模块;来自Go团队之外的贡献者人数首次超过Go团队;19次Go会议;Go新品牌和logo发布;PR数在github排名第四; 开发人员打算学习的语言中排名第一

5. Go的遗产

img{512x368}

没有时间机器可以达到未来。未来的到来缓慢而又出乎意料。我们不知道Go或世界将会发生什么。但是我们确实知道我们想留下什么标记。

  • 我们希望Go能够留下创新的遗产

Go向主流受众带来了创新的想法,例如goroutine,channel,简单的interface。这些想法现在正在其他语言中出现,我们为这一趋势继续感到高兴。

Go fmt于2009年推出时颇有争议。现在,大多数语言都采用了类似的方法。

也许我们最有影响力的遗产将是,我们像Go一样激励人们挑战既定的规范,并在各处寻找灵感。

  • 我们希望Go留下增强信心和能力的遗产

Go使开发人员能够编写生产服务器软件而无需C和C++所需的额外专业知识,而无需现代Java的复杂性,也无需解释语言的性能成本。

Go比其他任何语言都更能使人们把他们的想法变成现实。当我第一次开始撰写Hugo时,我个人感觉到了这一点,这是Go最吸引我的地方。

其他那些也被赋予了类似的能力和信心的人,其中许多人在本次会议上谈到了Go的创造性用途,包括Florin的家庭自动化研讨会,Ron的机器人,Elias的GUI等。

  • Go改变生活。

我有幸环游世界,在任何地方遇到的男人和女人,他们通常没有CS背景或学位,但能够学习Go并用它来创办公司,获得更好的工作并改善他们和他们家人的生活。

遗产不会为人们留下任何东西。它在人们身上留下了一些东西。- 彼得·斯特普尔

我们每个人都受到过往历史的影响。我们是遗产。我们被影响,我们影响别人。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

图解中文字符编码-Go语言例解

$
0
0

今天几个同事在处理一个有关中文字符编码的问题,感觉他们对字符编码这件事依然理解不够透彻。这里用图文方式对中文字符编码做一个简要的解释,例子使用Go语言

我们知道每个英文字母和数字在计算机中都会对应一个字节,或者说用一个字节来表示,这就是最初的ASCII码。但是随着计算机在全球范围内的广泛使用,非英语国家也要在计算机使用自己的字符,于是出现了字符集“百花齐放”的情况,我国在早期也颁布了自己的中文字符集标准。字符集一多,难免出现字符集编码不兼容的情况,比如:A字符集中某字符X的编码值是Y,但是在B字符集中Y这个值所表示的字符却是Z,这种不兼容的情况在一段时间内长期存在,导致因字符集导致的传输、处理、呈现、存储等问题常常发生,非常恼人。直到Unicode(万国码/统一码)在1994年发布,人类终于有了以统一人类所有字符为目的的统一字符集。Unicode的普及也是花费了不少的时间。但在2019年的今天,世界上绝大多数系统都支持了Unicode。

Unicode究竟是啥?Unicode就是一个表,如下图:

img{512x368}

图:unicode是什么

我们看到这个表中有两列:序号和字符。其中序号就是为全世界所有国家的所有语言文字的符号做的编码,每个字符分配一个序号,序号的范围从0×000000到0x10FFFF,一共110多万个字符,这个序号也被称为Unicode码点(code point)。第二列的字符就称为“Unicode字符”。注意:同样一个“中”字,在Unicode表中的”中”称为Unicode字符“中”;在GB18030码表中的“中”称为GB18030字符“中”。计算机中的字符是有字符集属性的,因此虽然字符外形相同(都是“中”),但在计算机内部的存储表示是不同的。

img{512x368}

图:拉丁字符对应的unicode表段

试想一下如果全世界的计算机系统都将Unicode序号作为Unicode字符的编码方案进行编解码,那么字符集问题便会从地球上彻底消失。但这个“理想的情况”并未发生。原因是什么呢?原因就是如果按照”理想方案”编码,那么无论是世界上最常用的26个字母a-z还是亚马逊森林中某个尚处于原始社会形态的某个部落的一个符号都要用一个”三字节”的存储单元表示,这意味着现实世界中所有数字资料的存储空间要变为原先的三倍(注:世界上大部分资料是用英语的26个字母编写的,原先每个字母仅需一个字节存储)、在传输相同信息的情况下,传输压力增加为原来的三倍,这是世界所无法接受的。Unicode组织其实也没有要求大家使用这种“理想的编码方案”对Unicode字符进行编码。于是就出现了UTF-8、UTF-16等变长的Unicode字符的编码方案,专门用于在存储和传输Unicode字符时使用。其中UTF-8经过实践,已经成为如今世界的Unicode字符的编码方案事实标准。

img{512x368}

图:凤凰网默认采用utf-8编码方案

UTF-8这种Unicode字符的编码方案有几个特点:

  • 使用变长字节对Unicode字符进行编码。采用什么编码与Unicode字符的序号有关,序号小的使用的字节就少,序号大的使用的字节就多。使用的字节个数从 1 到 4 个不等。

  • 兼容ASCII字符集编码。这点非常重要,这意味着采用Unicode字符集时,已有的ASCII字符存储和传输方式无需改变,依然兼容可用。

  • UTF-8 的编码单元为一个字节(也就是一次编解码一个字节),所以在处理UTF8字符的时候就不需要考虑这一个字节的存储是在高位还是在低位。

下面我们结合图、代码示例来更清晰地了解一下Unicode字符、UTF-8编码、GB18030编码的区别。

img{512x368}

图: “中国人”三个字对应Unicode字符、字符对应的码点(序号)、UTF-8编码与GB18030编码

从上图中,我们看到三个Unicode字符:中、国、人对应的在Unicode表中的序号(码点)分别是:U+4E2D、U+56FD和U+4EBA。我们可以通过一段Go代码来输出Unicode字符的码点。

package main

import "fmt"

func main() {
        var s = "中国人"
        for _, v := range s {
                fmt.Printf("%s => 码点:%X\n", string(v), v)
        }
}

运行该程序的输出结果:

中 => 码点:4E2D
国 => 码点:56FD
人 => 码点:4EBA

我们知道在Go语言中,rune这种builtin类型被用来表示一个“Unicode字符”,因此一个rune的值就是其对应Unicode字符的序号,即码点。通过for range语句对字符串进行迭代访问是,range会依次返回Unicode字符对应的rune,即码点。这里可以看到Unicode字符“中”对应的rune(码点)为0x4E2D。

前面我们说过,Unicode字符在存储和传输时采用的并非“理想编码方案”,而多维UTF-8编码,也就是说在上面的例子中“中国人”这三个Unicode字符在内存中并不是以码点值存储的,而是以UTF-8编码后的值存储的。还以Unicode字符“中”为例,在上图中,我们看到其对应的UTF-8编码为0xE4B8AD这三个字节,我们用Go代码来验证一下:

package main

import "fmt"

func main() {
        var s = "中"
        fmt.Printf("%s => UTF8编码: ", s)
        for _, v := range []byte(s) {
                fmt.Printf("%X", v)
        }
        fmt.Printf("\n")
}

运行该程序得到如下结果:

中 => UTF8编码: E4B8AD

我们将字符串转换为对应的切片元素,然后按字节逐一输出便得到了Unicode字符“中”所对应的UTF-8编码,即存储“中”这个字符时,内存所使用的字节(三个)和对应的值。

“中”这个字符也存在于我们的国标GB18030编码表中,那么GB18030表中是如何对GB18030字符“中”进行编码的呢?我们来看一个全面些的例子:

// github.com/bigwhite/experiments/non-ascii-char-encoding/demo1.go

package main

import (
        "fmt"

        utils "github.com/bigwhite/gocmpp/utils"
)

func main() {
        var stringLiteral = "中国人"
        var stringUsingRuneLiteral = "\u4E2D\u56FD\u4EBA"

        if stringLiteral != stringUsingRuneLiteral {
                fmt.Println("stringLiteral is not equal to stringUsingRuneLiteral")
                return
        }
        fmt.Println("stringLiteral is equal to stringUsingRuneLiteral")

        for i, v := range stringLiteral {
                fmt.Printf("中文字符: %s <=> Unicode码点(rune): %X <=> UTF8编码(内存值): ", string(v), v)
                s := stringLiteral[i : i+3]
                for _, v := range []byte(s) {
                        fmt.Printf("0x%X ", v)
                }

                s1, _ := utils.Utf8ToGB18030(s)
                fmt.Printf("<=> GB18030编码(内存值): ")
                for _, v := range []byte(s1) {
                        fmt.Printf("0x%X ", v)
                }
                fmt.Printf("\n")
        }
}

运行该程序,得到如下结果:

$go run demo1.go
stringLiteral is equal to stringUsingRuneLiteral
中文字符: 中 <=> Unicode码点(rune): 4E2D <=> UTF8编码(内存值): 0xE4 0xB8 0xAD <=> GB18030编码(内存值): 0xD6 0xD0
中文字符: 国 <=> Unicode码点(rune): 56FD <=> UTF8编码(内存值): 0xE5 0x9B 0xBD <=> GB18030编码(内存值): 0xB9 0xFA
中文字符: 人 <=> Unicode码点(rune): 4EBA <=> UTF8编码(内存值): 0xE4 0xBA 0xBA <=> GB18030编码(内存值): 0xC8 0xCB

我们看到,如果使用GB18030编码,中文字符“中”字仅需要在内存中使用两个字节0xD6和0xD0表示。

综上,关于中文字符编码,需记住以下要点:

  • Unicode是目前被支持最为广泛的字符集

  • Utf-8是目前被支持最为广泛的Unicode字符的编码方式(还有其他方式,比如UTF-16、UTF-32等);

  • 针对同一个字符,比如:“中”,如果该字符存在于两个字符集编码方案A(比如:utf8)和B(比如gb18030)中,那么我们可以通过转换,将该字符在A中的编码(如:”中”的E4B8AD)转换为在B中的编码(如“中”的D6D0)。

>本文涉及的例子源码可以在这里下载。

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Go语言项目的安全评估技术

$
0
0

在今年夏天我们对Kubernetes的评估成功之后,我们收到了大量Go项目的安全评估需求。为此,我们将在其他编译语言中使用过的安全评估技术和策略调整适配到多个Go项目中。

我们从了解语言的设计开始,识别出开发人员可能无法完全理解语言语义特性的地方。多数这些被误解的语义来自我们向客户报告的调查结果以及对语言本身的独立研究。尽管不是详尽无遗,但其中一些问题领域包括作用域、协程、错误处理和依赖管理。值得注意的是,其中许多与运行时没有直接关系。默认情况下,Go运行时本身的设计是安全的,避免了很多类似C语言的漏洞。

对根本原因有了更好地理解后,我们搜索了现有的能帮助我们快速有效检测客户端代码库的工具。结果我们找到一些静态和动态开源工具,其中包括了一些与Go无关的工具。为了配合这些工具使用,我们还确定了几种有助于检测的编译器配置。

一. 静态分析

由于Go是一种编译型语言,因此编译器在生成二进制可执行文件之前就检测并杜绝了许多潜在的错误模式。虽然对于新的Go开发人员来说,这些编译器的输出比较烦,但是这些警告对于防止意外行为以及保持代码的清洁和可读性非常重要。

静态分析趋向于捕获很多未包括在编译器错误和警告中的悬而未决的问题。在Go语言生态系统中,有许多不同的工具,例如go-vetstaticcheckanalysis包中的工具。这些工具通常会识别出诸如变量遮蔽、不安全的指针使用以及未使用的函数返回值之类的问题。调查这些工具显示警告的项目区域通常会发现可被利用(进行安全攻击)的功能特性。

这些工具绝不是完美的。例如,go-vet可能会错过非常常见的问题,例如下面例子中这种。

package main

import "fmt"

func A() (bool, error) { return false, fmt.Errorf("I get overridden!") }

func B() (bool, error) { return true, nil }

func main() {
    aSuccess, err := A()
    bSuccess, err := B()
    if err != nil {
        fmt.Println(err)
    }
    fmt.Println(aSuccess, ":", bSuccess)
}

这个例子未使用A函数的err返回值,并在表达式左侧为bSuccess赋值期间立即重新对err做了赋值。编译器针对这种情况不会提供警告,而go-vet也不会检测到该问题;errcheck也不会。实际上,能成功识别这种情况的工具是前面提到的staticcheck和ineffassign,它们将A的错误返回值标识为未使用或无效。

示例程序的输出以及errcheck,go-vet,staticcheck和ineffassign的检查结果如下:

$ go run .
false : true
$ errcheck .
$ go vet .
$ staticcheck .
main.go:5:50: error strings should not be capitalized (ST1005)
main.go:5:50: error strings should not end with punctuation or a newline (ST1005)
main.go:10:12: this value of err is never used (SA4006)
$ ineffassign .
main.go:10:12: ineffectual assignment to err

当您深入研究此示例时,您可能会想知道为什么编译器没有针对此问题发出警告。当程序中有未使用的变量时,Go编译器将出错,但此示例成功通过编译。这是由“短变量声明”的语义引起的。下面是短变量声明的语法规范:

ShortVarDecl = IdentifierList ":=" ExpressionList .

根据规范,短变量声明具有重新声明变量的特殊功能,只要:

  • 重新声明在多变量短声明中。
  • 重新声明的变量在同一代码块或函数的参数列表中声明较早。
  • 重新声明的变量与先前的声明具有相同的类型。
  • 声明中至少有一个非空白变量(“_”)是新变量。

所有这些约束在上一个示例中均得到满足,从而防止了编译器针对此问题产生编译错误。

许多工具都具有类似这样的极端情况,即它们在识别相关问题或识别问题但以不同的方式描述时均未成功。使问题复杂化的是,这些工具通常需要先构建Go源代码,然后才能执行分析。如果分析人员无法轻松构建代码库或其依赖项,这将使第三方安全评估变得复杂。

尽管存在这些困难,但只要付出一点点努力,这些工具就可以很好地提示我们在项目中从何处查找问题。我们建议至少使用gosecgo-vetstaticcheck。对大多数代码库而言,这些工具具有良好的文档和人机工效。他们还提供了针对常见问题的多种检查(例如ineffassign或errcheck)。但是,要对特定类型的问题进行更深入的分析,可能必须使用更具体的分析器,直接针对SSA开发定制的工具或使用semmle

二. 动态分析

一旦执行了静态分析并检查了结果,动态分析技术通常是获得更深层结果的下一步。由于Go的内存安全性,动态分析通常发现的问题是导致硬崩溃(hard crash)或程序状态无效的问题。Go社区已经建立了各种工具和方法来帮助识别Go生态系统中这些类型的问题。此外,可以改造现有的与语言无关的工具以满足Go动态分析的需求,我们将在下面展示。

1. 模糊测试

Go语言领域中最著名的动态测试工具可能是Dimitry Vyukovgo-fuzz了。该工具使您可以快速有效地实施模糊测试,并且它已经有了不错的战利品。更高级的用户在猎错过程中可能还会发现分布式的模糊测试libFuzzer的支持非常有用。

Google还发布了一个更原生的模糊器(fuzzer),它拥有一个与上面的go-fuzz相似的名字:gofuzz。它通过初始化具有随机值的结构来帮助用户。与Dimitry的go-fuzz不同,Google的gofuzz不会生成夹具(harness)或协助提供存储崩溃时的输出信息、模糊输入或任何其他类型的信息。尽管这对于测试某些目标可能是不利的,但它使轻量级且可扩展的框架成为可能。

为了简洁起见,我们请您参考各自自述文件中这两个工具的示例。

2. 属性测试(property test)

译注:属性测试指编写对你的代码来说为真的逻辑语句(即“属性”),然后使用自动化工具来生成测试输入(一般来说,是指某种特定类型的随机生成输入数据),并观察程序接受该输入时属性是否保持不变。如果某个输入违反了某一条属性,则证明用户程序存在错误 – 摘自网络。

与传统的模糊测试方法不同,Go的testing包(通常用于单元测试和集成测试)为Go函数的“黑盒测试” 提供了testing/quick子包。换句话说,它提供了属性测试的基本原语。给定一个函数和生成器,该包可用于构建夹具,以测试在给定输入生成器范围的情况下潜在的属性违规。以下示例是直接摘自官方文档。

func TestOddMultipleOfThree(t *testing.T) {
    f := func(x int) bool {
        y := OddMultipleOfThree(x)
        return y%2 == 1 && y%3 == 0
    }
    if err := quick.Check(f, nil); err != nil {
        t.Error(err)
    }
}

上面示例正在测试OddMultipleOfThree函数,其返回值应始终为3的奇数倍。如果不是,则f函数将返回false并将违反该属性。这是由quick.Check功能检测到的。

虽然此包提供的功能对于属性测试的简单应用是可以接受的,但重要的属性通常不能很好地适合这种基本界面。为了解决这些缺点,诞生了leanovate/gopter框架。Gopter为常见的Go类型提供了各种各样的生成器,并且支持您创建与Gopter兼容的自定义生成器。通过gopter/commands子包还支持状态测试,这对于测试跨操作序列的属性是否有用很有有帮助。除此之外,当违反属性时,Gopter会缩小生成的输入。请参阅下面的输出中输入收缩的属性测试的简要示例。

Compute结构的测试夹具:

package main_test
import (
  "github.com/leanovate/gopter"
  "github.com/leanovate/gopter/gen"
  "github.com/leanovate/gopter/prop"
  "math"
  "testing"
)

type Compute struct {
  A uint32
  B uint32
}

func (c *Compute) CoerceInt () { c.A = c.A % 10; c.B = c.B % 10; }
func (c Compute) Add () uint32 { return c.A + c.B }
func (c Compute) Subtract () uint32 { return c.A - c.B }
func (c Compute) Divide () uint32 { return c.A / c.B }
func (c Compute) Multiply () uint32 { return c.A * c.B }

func TestCompute(t *testing.T) {
  parameters := gopter.DefaultTestParameters()
  parameters.Rng.Seed(1234) // Just for this example to generate reproducible results

  properties := gopter.NewProperties(parameters)

  properties.Property("Add should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Add()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.Property("Subtract should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Subtract()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.Property("Multiply should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Multiply()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.Property("Divide should never fail.", prop.ForAll(
    func(a uint32, b uint32) bool {
      inpCompute := Compute{A: a, B: b}
      inpCompute.CoerceInt()
      inpCompute.Divide()
      return true
    },
    gen.UInt32Range(0, math.MaxUint32),
    gen.UInt32Range(0, math.MaxUint32),
  ))

  properties.TestingRun(t)
}

执行测试夹具并观察属性测试的输出(除法失败):

user@host:~/Desktop/gopter_math$ go test
+ Add should never fail.: OK, passed 100 tests.
Elapsed time: 253.291µs
+ Subtract should never fail.: OK, passed 100 tests.
Elapsed time: 203.55µs
+ Multiply should never fail.: OK, passed 100 tests.
Elapsed time: 203.464µs
! Divide should never fail.: Error on property evaluation after 1 passed
   tests: Check paniced: runtime error: integer divide by zero
goroutine 5 [running]:
runtime/debug.Stack(0x5583a0, 0xc0000ccd80, 0xc00009d580)
    /usr/lib/go-1.12/src/runtime/debug/stack.go:24 +0x9d
github.com/leanovate/gopter/prop.checkConditionFunc.func2.1(0xc00009d9c0)
    /home/user/go/src/github.com/leanovate/gopter/prop/check_condition_func.g
  o:43 +0xeb
panic(0x554480, 0x6aa440)
    /usr/lib/go-1.12/src/runtime/panic.go:522 +0x1b5
_/home/user/Desktop/gopter_math_test.Compute.Divide(...)
    /home/user/Desktop/gopter_math/main_test.go:18
_/home/user/Desktop/gopter_math_test.TestCompute.func4(0x0, 0x0)
    /home/user/Desktop/gopter_math/main_test.go:63 +0x3d
# snip for brevity;

ARG_0: 0
ARG_0_ORIGINAL (1 shrinks): 117380812
ARG_1: 0
ARG_1_ORIGINAL (1 shrinks): 3287875120
Elapsed time: 183.113µs
--- FAIL: TestCompute (0.00s)
    properties.go:57: failed with initial seed: 1568637945819043624
FAIL
exit status 1
FAIL    _/home/user/Desktop/gopter_math 0.004s

3. 故障注入

在攻击Go系统时,故障注入令人惊讶地有效。我们使用此方法发现的最常见错误包括对error类型的处理。因为error在Go中只是一种类型,所以当它返回时,它不会像panic语句那样自行改变程序的执行流程。我们通过强制生成来自最低级别(内核)的错误来识别此类错误。由于Go会生成静态二进制文件,因此必须在不使用LD_PRELOAD的情况下注入故障。我们的工具之一KRF使我们能够做到这一点。

在我们最近的Kubernetes代码库评估中,我们使用KRF找到了一个vendored依赖深处的问题,只需通过随机为进程和其子进程发起的read和write系统调用制造故障。该技术对通常与底层系统交互的Kubelet十分有效。该错误是在ionice命令出现错误时触发的,未向STDOUT输出信息并向STDERR发送错误。记录错误后,将继续执行而不是将STDERR的错误返回给调用方。这导致STDOUT后续被索引,从而导致索引超出范围导致运行时panic。

下面是导致kubelet panic的调用栈信息:

E0320 19:31:54.493854    6450 fs.go:591] Failed to read from stdout for cmd [ionice -c3 nice -n 19 du -s /var/lib/docker/overlay2/bbfc9596c0b12fb31c70db5ffdb78f47af303247bea7b93eee2cbf9062e307d8/diff] - read |0: bad file descriptor
panic: runtime error: index out of range

goroutine 289 [running]:
k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs.GetDirDiskUsage(0xc001192c60, 0x5e, 0x1bf08eb000, 0x1, 0x0, 0xc0011a7188)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs/fs.go:600 +0xa86
k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs.(*RealFsInfo).GetDirDiskUsage(0xc000bdbb60, 0xc001192c60, 0x5e, 0x1bf08eb000, 0x0, 0x0, 0x0)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/fs/fs.go:565 +0x89
k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common.(*realFsHandler).update(0xc000ee7560, 0x0, 0x0)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common/fsHandler.go:82 +0x36a
k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common.(*realFsHandler).trackUsage(0xc000ee7560)
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common/fsHandler.go:120 +0x13b
created by
k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common.(*realFsHandler).Start
    /workspace/anago-v1.13.4-beta.0.55+c27b913fddd1a6/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/vendor/github.com/google/cadvisor/container/common/fsHandler.go:142 +0x3f

下面例子:记录了STDERR日志但未将error返回调用方。

stdoutb, souterr := ioutil.ReadAll(stdoutp)
if souterr != nil {
    klog.Errorf("Failed to read from stdout for cmd %v - %v", cmd.Args, souterr)
}

当stdout为空,也尝试使用索引,这是运行时出现panic的原因:

usageInKb, err := strconv.ParseUint(strings.Fields(stdout)[0], 10, 64)

更完整的包含重现上述问题的步骤,可参见我们的Kubernetes最终报告附录G(第109页),那里详细介绍了针对Kubelet使用KRF的方法。

Go的编译器还允许将测量工具包含在二进制文件中,从而可以在运行时检测race状况,这对于将潜在的race识别为攻击者非常有用,但也可以用来识别对defer、panic和recover的不正确处理。我们构建了Trailofbits/on-edge来做到这一点:识别函数入口点和函数panic点之间的全局状态变化,并通过Go race检测器”泄露”此信息。有关OnEdge的更多详细信息,请参见我们以前的博客文章“在Go中选择正确panic的方式”

实践中,我们建议使用:

  • dvyukov/go-fuzz为组件解析输入建立夹具
  • google/gofuzz用于测试结构验证
  • leanovate/gopter用于增强现有的单元和集成测试以及测试规范的正确性
  • Trailofbits/krf和Trailofbits/on-edge用于测试错误处理。

除KRF外,所有这些工具在实践中都需要付出一些努力。

三. 利用编译器的优势

Go编译器具有许多内置功能和指令(directive),可帮助我们查找错误。这些功能隐藏在各种开关中中,并且需要一些配置才能达到我们的目的。

1. 颠覆类型系统

有时在尝试测试系统功能时,导出函数不是我们要测试的。要获得对所需的函数的测试访问权,可能需要重命名许多函数,以便可以将其导出,这可能会很麻烦。要解决此问题,可以使用编译器的build指令(directive)进行名称链接(name linking)以及导出系统的访问控制。作为此功能的示例,下面的程序(从Stack Overflow答案中提取)访问未导出的reflect.typelinks函数,并随后迭代类型链接表以识别已编译程序中存在的类型。

下面是使用linkname build directive的Stack Overflow答案的通用版本:

package main

import (
    "fmt"
    "reflect"
    "unsafe"
)

func Typelinks() (sections []unsafe.Pointer, offset [][]int32) {
    return typelinks()
}

//go:linkname typelinks reflect.typelinks
func typelinks() (sections []unsafe.Pointer, offset [][]int32)

func Add(p unsafe.Pointer, x uintptr, whySafe string) unsafe.Pointer {
    return add(p, x, whySafe)
}

//go:linkname add reflect.add
func add(p unsafe.Pointer, x uintptr, whySafe string) unsafe.Pointer

func main() {
    sections, offsets := Typelinks()
    for i, base := range sections {
        for _, offset := range offsets[i] {
            typeAddr := Add(base, uintptr(offset), "")
            typ := reflect.TypeOf(*(*interface{})(unsafe.Pointer(&amp;typeAddr)))
            fmt.Println(typ)
        }
    }
}

下面是typelinks表的输出:

$ go run main.go
**reflect.rtype
**runtime._defer
**runtime._type
**runtime.funcval
**runtime.g
**runtime.hchan
**runtime.heapArena
**runtime.itab
**runtime.mcache
**runtime.moduledata
**runtime.mspan
**runtime.notInHeap
**runtime.p
**runtime.special
**runtime.sudog
**runtime.treapNode
**sync.entry
**sync.poolChainElt
**syscall.Dirent
**uint8

如果需要在运行时进行更精细的控制(即,不仅仅是linkname指令),则可以编写Go的中间汇编码,并在编译过程中包括它。尽管在某些地方它可能不完整且有些过时,但是teh-cmc/go-internals提供了有关Go如何组装函数的很好的介绍。

2. 编译器生成的覆盖图

为了帮助进行测试,Go编译器可以执行预处理以生成coverage信息。这旨在标识单元测试和集成测试的测试覆盖范围信息,但是我们也可以使用它来标识由模糊测试和属性测试生成的测试覆盖范围。Filippo Valsorda在博客文章中提供了一个简单的示例。

3. 类型宽度安全

Go支持根据目标平台自动确定整数和浮点数的大小。但是,它也允许使用固定宽度的定义,例如int32和int64。当混合使用自动宽度和固定宽度大小时,对于跨多个目标平台的行为,可能会出现错误的假设。

针对目标的32位和64位平台构建进行测试将有助于识别特定于平台的问题。这些问题通常在执行验证、解码或类型转换的时候发现,原因在于对源和目标类型属性做出了不正确的假设。在Kubernetes安全评估中就有一些这样的示例,特别是TOB-K8S-015:使用strconv.Atoi并将结果向下转换时的溢出(Kubernetes最终报告中的第42页),下面是这个示例。

// updatePodContainers updates PodSpec.Containers.Ports with passed parameters.
func updatePodPorts(params map[string]string, podSpec *v1.PodSpec) (err error) {
    port := -1
    hostPort := -1
    if len(params["port"]) > 0 {
        port, err = strconv.Atoi(params["port"]) // <-- this should parse port as strconv.ParseUint(params["port"], 10, 16)
        if err != nil {
            return err
        }
    }
       // (...)
    // Don't include the port if it was not specified.
    if len(params["port"]) > 0 {
        podSpec.Containers[0].Ports = []v1.ContainerPort{
            {
                ContainerPort: int32(port), // <-- this should later just be uint16(port)
            },
        }

错误的类型宽度假设导致的溢出:

root@k8s-1:/home/vagrant# kubectl expose deployment nginx-deployment --port 4294967377 --target-port 4294967376
E0402 09:25:31.888983    3625 intstr.go:61] value: 4294967376 overflows int32
goroutine 1 [running]:
runtime/debug.Stack(0xc000e54eb8, 0xc4f1e9b8, 0xa3ce32e2a3d43b34)
    /usr/local/go/src/runtime/debug/stack.go:24 +0xa7
k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/intstr.FromInt(0x100000050, 0xa, 0x100000050, 0x0, 0x0)
...
service/nginx-deployment exposed

实际上,很少需要颠覆类型系统。最需要的测试目标已经是导出了的,可以通过import获得。我们建议仅在需要助手和测试类似的未导出函数时才使用此功能。至于测试类型宽度安全性,我们建议您尽可能对所有目标进行编译,即使没有直接支持也是如此,因为不同目标上的问题可能更明显。最后,我们建议至少生成包含单元测试和集成测试的项目的覆盖率报告。它有助于确定未经直接测试的区域,这些区域可以优先进行审查。

四. 有关依赖的说明

在诸如JavaScript和Rust的语言中,依赖项管理器内置了对依赖项审核的支持-扫描项目依赖项以查找已知存在漏洞的版本。在Go中,不存在这样的工具,至少没有处于公开可用且非实验状态的。

这种缺乏可能是由于存在多种不同的依赖关系管理方法:go-modgo-getvendored等。这些不同的方法使用根本不同的实现方案,导致无法直接识别依赖关系及其版本。此外,在某些情况下,开发人员通常会随后修改其vendor的依赖的源代码。

在Go的开发过程中,依赖管理问题的解决已经取得了进展,大多数开发人员都在朝使用go mod的方向发展。这样就可以通过项目中的go.mod跟踪和依赖项并进行版本控制,从而为以后的依赖项扫描工作打开了大门。我们可以在OWASP DependencyCheck工具中看到此类工作的示例,该工具是具有实验性质的go mod插件。

五. 结论

最终,Go生态系统中有许多可以使用的工具。尽管大多数情况是完全不同的,但是各种静态分析工具可帮助识别给定项目中的“悬而未决的问题”。当寻求更深层次的关注时,可以使用模糊测试,属性测试和故障注入工具。编译器配置随后增强了动态技术,使构建测试夹具和评估其有效性变得更加容易。

本文翻译自“Security assessment techniques for Go projects”


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Go语言开源十周年

$
0
0

本文翻译自Go官方博客Russ Cox代表Go核心团队发表的“Go Turns 10″一文。

生日快乐,Go!

这个周末,我们庆祝Go正式对外发布10周年,即Go作为开源编程语言和构建现代网络软件生态系统的10周年诞辰。

为了纪念这一时刻,Go gopher的创建者Renee French(用下面的新作)描绘了这个令人愉快的场景:

img{512x368}

庆祝Go十周年让我回想起2009年11月上旬,那时我们正准备与世界分享Go。我们不知道会发生什么样的反应,是否有人会关心这种新生的小语言。我希望即使没有人最终使用Go,我们也至少会引起人们对一些好的想法的关注,尤其是Go的并发和接口,这些想法可能会影响后续语言

当看到人们对Go感到兴奋,我便查看了CC++、Perl、Python和Ruby等流行语言的历史,并研究了每种语言花了多长时间才被广泛采用。例如,在我看来,Perl在1990年代中后期就已经完全形成了,带有CGI脚本和Web,但它于1987年首次发布。这种模式在我所研究的几乎所有语言中都重现了:在新语言真正腾飞之前,需要大约十年的时间进行安静、稳定的改进和传播。

(当时的)我想知道:十年后的Go会在哪里?

今天,我们可以回答这个问题:Go无处不在,全世界至少有100万开发人员在使用它。

Go最初的目标是网络系统基础架构,现在我们称为云软件(cloud software)。如今,每个主要的云计算平台提供商都使用用Go语言编写的核心云基础架构,例如DockerEtcdhttps://etcd.io/,IstioKubernetesPrometheusTerraformCloud Native Computing Foundation的大多数项目都是用Go编写的。无数公司也在使用Go将自己的工作迁移到云上,从初创公司从头开始构建到大企业更新软件堆栈。Go还发现对其的采用已经远远超出了最初的云计算目标,其使用范围从使用GoBotTinyGo控制小型嵌入式系统到使用GRAIL进行大规模的大数据分析和机器学习进行癌症检测,以及介于两者之间的所有内容。

这一切都说明Go超越了我们最疯狂的梦想。Go的成功不仅仅在于语言。这是关于语言,生态系统,尤其是社区的共同努力。

在2009年,该语言是一个不错的主意,并带有一个实现的工作草图。那时候go命令还不存在:我们使用命令6g编译源码和6l链接二进制文件,并借助Makefile实现这个过程的自动化。我们在语句末尾键入分号。整个程序在垃圾回收期间停止,然后努力利用两个CPU核。当时Go只能在Linux和Mac,32位和64位x86和32位ARM上运行。

在过去的十年中,在世界各地的Go开发人员的帮助下,我们已经将这一想法和草图发展为拥有出色的工具,生产级质量实现,先进的垃圾收集器和得到广泛移植的高效语言,Go支持12种操作系统和10种CPU体系结构

任何编程语言都需要蓬勃发展的生态系统的支持。开源发布是该生态系统的种子,但是自那时以来,许多人贡献了自己的时间和才干,用出色的教程,书籍,课程,博客文章,播客,工具,集成以及可重复使用的、支持go get的Go包来填充Go生态系统。没有这个生态系统的支持,Go永远不可能成功。

当然,生态系统需要蓬勃发展的社区的支持。在2019年,全球有数十个Go(技术)会议,以及超过150个Go聚会组织和90000名参会人员GoBridgeGoing Who Go通过指导,培训和会议奖学金帮助将新的声音带入Go社区。仅今年一年,他们就在讲习班上向数百名来自传统团体的人们进行了培训,在这些讲习班上,社区成员教导和指导刚接触Go的人。

全球有超过一百万的Go开发人员,全球各地的公司都在寻求雇用更多的人。实际上,人们经常告诉我们,学习Go帮助他们获得了技术行业的第一份工作。最后,我们为Go感到最自豪的不是设计完善的功能或巧妙的代码,而是Go在这么多人的生活中产生的积极影响。我们旨在创建一种可以帮助我们成为更好的开发人员的语言,我们很高兴Go帮助了许多其他人。

恰逢Go开源十周年的时刻,我希望每个人都花一点时间来庆祝Go社区以及我们所取得的一切。我代表Google的整个Go团队,感谢过去十年来加入我们的每个人。让我们开启下一个更加不可思议的十年吧!

img{512x368}


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Go官方发布的go.dev给gopher们带来了什么

$
0
0

众所周知,Go是一个诞生于Google内部的编程语言,它在2019年11月份开源,在开源后立即受到了来自全世界开发人员的关注与贡献。但初期的Go语言的发展依旧是由Go核心团队的若干leader决定的,这种类“民主集中制”的方法延续了若干年。直到Go核心团队逐渐意识到Go应该更多倾听社区的声音,并让更多的gopher参与到Go项目的开发和贡献中来,甚至影响和决定一些语言特定的演化。于是Go团队开始特意为Go社区发展招兵买马。像Steve FranciaFrancesc Campoy(后已经从google离职加入Dgraph)等都是在这个阶段加入Go team的。

Go团队在很长一段时间里尤其重视与社区的互动,比如连续多年发起Go user调查Gophercon大会后的Go team与社区的见面会和分组讨论去GOPATH降低Go入门学习曲线发布Go新品牌标识、添加Go module机制改善官网等。

在今天Go官博发文:“Go.dev: a new hub for Go developers”,正式发布go.dev站点,该站点被Go核心团队寄望于成为全世界Gopher开发人员的中心。它将告诉gopher(无论新手还是老油条):谁在使用Go、用Go做什么、怎么学习Go(Go的各种学习资源、受欢迎的Go package都有哪些以及这些package的详细信息)。

img{512x368}

go.dev发布之后,golang.org官网将更加聚焦go开源项目本身的开发、语言演化以及Go版本发布。而go.dev将成为gopher日常使用go语言的中心,包括go学习、go方案、go应用案例等。在这里我们简单探索一下go.dev这个站点究竟给gopher们带来了什么(这仅仅是go.dev的最小功能发布,后续go.dev可能会演化出更多特性、并根据社区反馈更好满足gopher需求)。

一. 学习资源聚合

go.dev的一个重要功能就是帮助首次进入Go世界的开发人员学习Go

在go.dev的”learn”栏目下,我们在第一屏就看到了Go新手入门的三个步骤:安装、”Hello World”、Go tour以及更为详尽文档的入口

img{512x368}

接下来,go.dev提供了这些年口碑较好、受到gopher欢迎的一些初级在线学习资源:

img{512x368}

像gobyexample.com、gophercises.com都在推荐行列。

Go技术类书籍以及培训资源是gopher学习Go过程中不可缺少的:

img{512x368}

Go.dev在learn栏目下推荐了一些口碑不错的Go书籍,比如:Alan A. A. Donovan和Brian W. Kernighan合著的Go圣经:《The Go Programming Language》被在首位推荐。知名Go培训师William Kennedy的培训也被推荐给了大家。不过口碑不错的书籍《Go in action》我觉得也应该列入推荐行列。

在Learn栏目最后,是全世界各地近期有关Go的meetup活动的schedule,Gopher可以得到最及时的meetup信息,并选择参加。

二. 成熟解决方案参考

img{512x368}

go.dev开辟的”solution”栏目旨在提升go的开发过程。栏目从“云原生和网络服务开发”、“命令行程序开发”、“web开发”以及Devops/Site Reliability四个方面提供聚合化的资料。以“云原生和网络服务开发”为例,Go.dev提供了这方面的典型项目和用户、使用方法、关键方案(一些书籍、成熟框架、客户端库以及其他资源)。

go.dev solution栏目还提供了一些Go的典型客户以及这些客户使用Go的典型案例:

img{512x368}

三、Package信息聚合中心

在go.dev的“explore”栏目下,我们看到的是Go package的信息中心:

img{512x368}

就如上图所示,这里提供了受欢迎的package和特色package的推荐列表,以及package信息的搜索功能。

logrus为例

img{512x368}

logrus包的主页,我们看到了有关logrus的各种信息,项目repo地址、最新版本号、module名字、开源许可证信息、文档(应该是集成了godoc返回的结果)、它的依赖、以及以它为依赖的项目(见下图):

img{512x368}

四. 小结

go.dev目前处于最小产品状态(mvp),从目前已经提供的栏目来看,go.dev能为gopher提供的帮助已经很全面了。后续go.dev站点的运营好坏(比如:信息更新是否及时等)将决定go.dev是否能达到其预期的期望。

go.dev目前似乎还缺少论坛功能。不过已有的golang-nutsgobridge已经承担了这个角色,但如果能有一个官方论坛(一站式)就再好不过了。

go.dev在国内可以访问,就是速度有些慢(可能因地区而异)。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

计算重现性:一些挑战

$
0
0

写在Go语言开源十周年的日子 by Rob Pike

近期,有人对科学结果的可重现性进行了讨论,并得出了一些让人沮丧的结论。一项研究表明:这种可重现性只有62%。

在某些领域,情况可能更糟。任何依赖于计算的结果都面临着其编程环境不断变化的巨大风险:十年前编写的程序如果没有更改,今天构建成功的机会几乎微乎其微,更不用说运行或正确运行了。

这种担忧并不普遍,但正在增长。一个标志就是十年重现性挑战的创建,该挑战要求研究人员重新运行他们的旧代码(十年或以上,按计算标准非常旧的代码),并查看它是否仍然有效。

您还能找到你的旧代码吗? 这本身就是一个挑战。

我们鼓励任何对计算有兴趣的研究人员接受挑战。上面的链接包含了有关此次挑战活动如何进行的详细信息。结果肯定令人大开眼界。即使您不提交结果,该练习也很有价值。

尽管人们都希望结果不要像某些人所预期的那样令人沮丧,但也很少有人会期望获得令人满意的结果。值得花点时间考虑一下为什么计算可重现性是一个问题。计算方法(Computational method)会随着系统,语言,库,方法甚至部署技术的不断变化而偏离。某些更改是必要的,因为这样可以解决库设计不佳导致的安全问题。某些功能确实可以实现,例如转向网络服务器;但是很多改变可以归结为改变本身,也就是“进步”。

本周是2009年11月10日宣布Go编程语言为开源项目的10周年纪念日,因此在本周初我就想到了这个话题。但也许更重要的日期是2012年3月28日,因为那是Go版本1.0宣布的日子。

Go 1.0如此重要的原因在于,它带来了一个承诺,即用户的程序在不确定的将来无需任何修改便可以继续进行编译和运行。从变革考虑,这一承诺恰是反对变革的坚不可摧的堡垒。 Go 1.0远非完美无缺-许多事情本来可以做得更好,其中包括我们当时甚至还不满意的一些事情-但对稳定的承诺远远弥补了此类不足。

为什么没有更多的计算项目像Go做出这样的保证?特别是编程语言?尽管没有Go程序可以参加十年挑战赛,但是如果参与七年挑战赛,与其他大多数语言相比,Go程序获得成功的机会要高得多。

这不仅涉及承诺的兼容性,你还必须交付它。曾经有无数次提议对Go进行更改的建议可以很容易被接受,但是最终因会破坏现有程序,或者至少有这样做的可能而导致被拒绝。真正兼容性的保护墙是有约束力的,但它也有机会做一些事情。它促进了Go生态系统的发展,使社区得以繁荣发展,有助于确保可移植性,并且将许多程序的维护开销降低到几乎为零。

随着对Go 2.0的努力不断发展,兼容性前景依然存在。它实在是太重要了以致于我们不能屈服,尤其是考虑到其到目前为止已经取得的进展。

语义版本控制(semver)有帮助,但这还不够。必须将其部署在所有内容,包括的工具中,并严格遵守其兼容性属性。

所以这是我自己的十年挑战:找出一些已有十年历史的代码,如果可以的话,立即尝试运行。做任何必要的使其重新构建并运行。如果很容易就做到,那就太好了。如果不是,请反思存在的困难,造成这些困难的变化以及这些变化是否值得。他们能得到更好的管理吗?

系统和语言设计师面临的更大挑战:帮您的用户,并编纂您的兼容性规则。您可能不愿像Go开发人员那样僵化,但是您应该让您的社区清楚您提供的保证并兑现他们的保证。

如果您愿意,也许十年后,我们可以再次进行此练习,并获得更好的结果。

本文翻译自Rob Pike的文章:“Computational reproducibility: Some challenges”


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.


Kubernetes Deployment故障排除图解指南

$
0
0

img{512x368}


下面是一个示意图,可帮助你调试Kubernetes Deployment(你可以在此处下载它的PDF版本)。

img{512x368}

当你希望在Kubernetes中部署应用程序时,你通常会定义三个组件:

  • 一个Deployment – 这是一份用于创建你的应用程序的Pod副本的”食谱”;
  • 一个Service – 一个内部负载均衡器,用于将流量路由到内部的Pod上;
  • 一个Ingress – 描述如何流量应该如何从集群外部流入到集群内部的你的服务上。

下面让我们用示意图快速总结一下要点。

img{512x368}

在Kubernetes中,你的应用程序通过两层负载均衡器暴露服务:内部的和外部的

img{512x368}

内部的负载均衡器称为Service,而外部的负载均衡器称为Ingress

img{512x368}

Pod不会直接部署。Deployment会负责创建Pod并管理它们

假设你要部署一个简单的”HelloWorld”应用,该应用的YAML文件的内容应该类似下面这样:

// hello-world.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

这个定义很长,组件之间的相互关系并不容易看出来。

例如:

  • 什么时候应使用端口80,又是何时应使用端口8080?
  • 你是否应该为每个服务创建一个新端口以免它们相互冲突?
  • 标签(label)名重要吗?它们是否在每一处都应该是一样的?

在进行调试之前,让我们回顾一下这三个组件是如何相互关联的。

让我们从Deployment和Service开始。

一. 连接Deployment和Service

令人惊讶的消息是,Service和Deployment之间根本没有连接。

事实是:Service直接指向Pod,并完全跳过了Deployment。

因此,你应该注意的是Pod和Service之间的相互关系。

你应该记住三件事:

  • Service selector应至少与Pod的一个标签匹配;
  • Service的targetPort应与Pod中容器的containerPort匹配;
  • Service的port可以是任何数字。多个Service可以使用同一端口号,因为它们被分配了不同的IP地址。

下面的图总结了如何连接端口:

img{512x368}

考虑上面被一个服务暴露的Pod

img{512x368}

创建Pod时,应为Pod中的每个容器定义containerPort端口

img{512x368}

当创建一个Service时,你可以定义port和targetPort,但是哪个用来连接容器呢?

img{512x368}

targetPort和containerPort应该始终保持匹配

img{512x368}

如果容器暴露3000端口(containerPort),那么targetPort应该匹配这一个端口号

再来看看YAML,标签和ports/targetPort应该匹配:

// hello-world.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    any-name: my-app

那deployment顶部的track: canary标签呢?

它也应该匹配吗?

该标签属于deployment,service的选择器未使用它来路由流量。

换句话说,你可以安全地删除它或为其分配其他值。

matchLabels选择器呢?

它必须始终与Pod的标签匹配,并且被Deployment用来跟踪Pod。

假设你已经进行了所有正确的设置,该如何测试它呢?

你可以使用以下命令检查Pod是否具有正确的标签:

$ kubectl get pods --show-labels

或者,如果你拥有属于多个应用程序的Pod:

$ kubectl get pods --selector any-name=my-app --show-labels

any-name=my-app就是标签:any-name: my-app

还有问题吗?

你也可以连接到Pod!

你可以使用kubectl中的port-forward命令连接到service并测试连接。

$ kubectl port-forward service/<service name> 3000:80
  • service/ 是服务的名称- 在上面的YAML中是“my-service”
  • 3000是你希望在计算机上打开的端口
  • 80是service通过port字段暴露的端口

如果可以连接,则说明设置正确。

如果不行,则很可能是你填写了错误的标签或端口不匹配。

二. 连接Service和Ingress

接下来是配置Ingress以将你的应用暴露到集群外部。

Ingress必须知道如何检索服务,然后检索Pod并将流量路由给它们。

Ingress按名字和暴露的端口检索正确的服务。

在Ingress和Service中应该匹配两件事:

  • Ingress的servicePort应该匹配service的port
  • Ingress的serviceName应该匹配服务的name

下面的图总结了如何连接端口:

img{512x368}

你已经知道servive暴露一个port

img{512x368}

Ingress有一个字段叫servicePort

img{512x368}

service的port和Ingress的service应该始终保持匹配

img{512x368}

如果你为service指定的port是80,那么你也应该将ingress的servicePort改为80

实践中,你应该查看以下几行(下面代码中的my-service和80):

// hello-world.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service   --- 需关注
spec:
  ports:
  - port: 80       --- 需关注
    targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: my-service --- 需关注
        servicePort: 80 --- 需关注
      path: /

你如何测试Ingress是否正常工作呢?

你可以使用与以前相同的策略kubectl port-forward,但是这次你应该连接到Ingress控制器,而不是连接到Service。

首先,使用以下命令检索Ingress控制器的Pod名称:

$ kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

标识Ingress Pod(可能在其他命名空间中)并描述它以检索端口:

$ kubectl describe pod nginx-ingress-controller-6fc5bcc \
 --namespace kube-system \
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

最后,连接到Pod:

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此时,每次你访问计算机上的端口3000时,请求都会转发到Ingress控制器Pod上的端口80。

如果访问http://localhost:3000,则应找到提供网页服务的应用程序。

回顾Port

快速回顾一下哪些端口和标签应该匹配:

  • service selector应与Pod的标签匹配
  • service的targetPort应与Pod中容器的containerPort匹配
  • service的端口可以是任何数字。多个服务可以使用同一端口,因为它们分配了不同的IP地址。
  • ingress的servicePort应该匹配service的port
  • serivce的名称应与ingress中的serviceName字段匹配

知道如何构造YAML定义只是故事的一部分。

出了问题后该怎么办?

Pod可能无法启动,或者正在崩溃。

三. kubernetes deployment故障排除的3个步骤

在深入研究失败的deployment之前,我们必须对Kubernetes的工作原理有一个明确定义的思维模型。

由于每个deployment中都有三个组件,因此你应该自下而上依次调试所有组件。

  • 你应该先确保Pods正在运行
  • 然后,专注于让service将流量路由到到正确的Pod
  • 然后,检查是否正确配置了Ingress

img{512x368}

你应该从底部开始对deployment进行故障排除。首先,检查Pod是否已就绪并正在运行。

img{512x368}

如果Pod已就绪,则应调查service是否可以将流量分配给Pod。

img{512x368}

最后,你应该检查service与ingress之间的连接。

1. Pod故障排除

在大多数情况下,问题出在Pod本身。

你应该确保Pod正在运行并准备就绪。

该如何检查呢?

$ kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

在上述会话中,最后一个Pod处于就绪并正常运行的状态;但是,前两个Pod既不处于Running也不是Ready。

你如何调查出了什么问题?

有四个有用的命令可以对Pod进行故障排除:

  • kubectl logs 有助于检索Pod容器的日志
  • kubectl describe pod 检索与Pod相关的事件列表很有用
  • kubectl get pod 用于提取存储在Kubernetes中的Pod的YAML定义
  • kubectl exec -ti bash 在Pod的一个容器中运行交互式命令很有用

应该使用哪一个呢?

没有一种万能的。

相反,我们应该结合着使用它们。

常见Pod错误

Pod可能会出现启动和运行时错误。

启动错误包括:

  • ImagePullBackoff
  • ImageInspectError
  • ErrImagePull
  • ErrImageNeverPull
  • RegistryUnavailable
  • InvalidImageName

运行时错误包括:

  • CrashLoopBackOff
  • RunContainerError
  • KillContainerError
  • VerifyNonRootError
  • RunInitContainerError
  • CreatePodSandboxError
  • ConfigPodSandboxError
  • KillPodSandboxError
  • SetupNetworkError
  • TeardownNetworkError

有些错误比其他错误更常见。

以下是最常见的错误列表以及如何修复它们的方法。

ImagePullBackOff

当Kubernetes无法获取到Pod中某个容器的镜像时,将出现此错误。

共有三个可能的原因:

  • 镜像名称无效-例如,你拼错了名称,或者image不存在
  • 你为image指定了不存在的标签
  • 你尝试检索的image属于一个私有registry,而Kubernetes没有凭据可以访问它

前两种情况可以通过更正image名称和标记来解决。

针对第三种情况,你应该将私有registry的访问凭证通过Secret添加到k8s中并在Pod中引用它。

官方文档中有一个有关如何实现此目标的示例

CrashLoopBackOff

如果容器无法启动,则Kubernetes将显示错误状态为:CrashLoopBackOff。

通常,在以下情况下容器无法启动:

  • 应用程序中存在错误,导致无法启动
  • 未正确配置容器
  • Liveness探针失败太多次

你应该尝试从该容器中检索日志以调查其失败的原因。

如果由于容器重新启动太快而看不到日志,则可以使用以下命令:

$ kubectl logs <pod-name> --previous

这个命令打印前一个容器的错误消息。

RunContainerError

当容器无法启动时,出现此错误。

甚至在容器内的应用程序启动之前。

该问题通常是由于配置错误,例如:

  • 挂载不存在的卷,例如ConfigMap或Secrets
  • 将只读卷安装为可读写

你应该使用kubectl describe pod 命令收集和分析错误。

处于Pending状态的Pod

当创建Pod时,该Pod保持Pending状态。

为什么?

假设你的调度程序组件运行良好,可能的原因如下:

  • 集群没有足够的资源(例如CPU和内存)来运行Pod
  • 当前的命名空间具有ResourceQuota对象,创建Pod将使命名空间超过配额
  • 该Pod绑定到一个处于pending状态的 PersistentVolumeClaim

最好的选择是检查kubectl describe命令输出的“事件”部分内容:

$ kubectl describe pod <pod name>

对于因ResourceQuotas而导致的错误,可以使用以下方法检查集群的日志:

$ kubectl get events --sort-by=.metadata.creationTimestamp

处于未就绪状态的Pod

如果Pod正在运行但未就绪(not ready),则表示readiness就绪探针失败。

当“就绪”探针失败时,Pod未连接到服务,并且没有流量转发到该实例。

就绪探针失败是应用程序的特定错误,因此你应检查kubectl describe中的“ 事件”部分以识别错误。

2. 服务的故障排除

如果你的Pod正在运行并处于就绪状态,但仍无法收到应用程序的响应,则应检查服务的配置是否正确。

service旨在根据流量的标签将流量路由到Pod。

因此,你应该检查的第一件事是服务关联了多少个Pod。

你可以通过检查服务中的端点(endpoint)来做到这一点:

$ kubectl describe service <service-name> | grep Endpoints

端点是一对,并且在服务(至少)以Pod为目标时,应该至少有一个端点。

如果“端点”部分为空,则有两种解释:

  • 你没有运行带有正确标签的Pod(提示:你应检查自己是否在正确的命名空间中)
  • service的selector标签上有错字

如果你看到端点列表,但仍然无法访问你的应用程序,则targetPort可能是你服务中的罪魁祸首。

你如何测试服务?

无论服务类型如何,你都可以使用kubectl port-forward来连接它:

$kubectl port-forward service/<service-name> 3000:80

这里:

  • 是服务的名称
  • 3000 是你希望在计算机上打开的端口
  • 80 是服务公开的端口

3.Ingress的故障排除

如果你已到达本节,则:

  • Pod正在运行并准备就绪
  • 服务会将流量分配到Pod

但是你仍然看不到应用程序的响应。

这意味着最有可能是Ingress配置错误。

由于正在使用的Ingress控制器是集群中的第三方组件,因此有不同的调试技术,具体取决于Ingress控制器的类型。

但是在深入研究Ingress专用工具之前,你可以用一些简单的方法进行检查。

Ingress使用serviceName和servicePort连接到服务。

你应该检查这些配置是否正确。

你可以通过下面命令检查Ingress配置是否正确:

$kubectl describe ingress <ingress-name>

如果backend一列为空,则配置中必然有一个错误。

如果你可以在“backend”列中看到端点,但是仍然无法访问该应用程序,则可能是以下问题:

  • 你如何将Ingress暴露于公共互联网
  • 你如何将集群暴露于公共互联网

你可以通过直接连接到Ingress Pod来将基础结构问题与Ingress隔离开。

首先,获取你的Ingress控制器Pod(可以位于其他名称空间中):

$ kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

描述它以检索端口:

# kubectl describe pod nginx-ingress-controller-6fc5bcc
 --namespace kube-system \
 | grep Ports

最后,连接到Pod:

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此时,每次你访问计算机上的端口3000时,请求都会转发到Pod上的端口80。

现在可以用吗?

  • 如果可行,则问题出在基础架构中。你应该调查流量如何路由到你的集群。
  • 如果不起作用,则问题出在Ingress控制器中。你应该调试Ingress。

如果仍然无法使Ingress控制器正常工作,则应开始对其进行调试。

目前有许多不同版本的Ingress控制器。

热门选项包括Nginx,HAProxy,Traefik等。

你应该查阅Ingress控制器的文档以查找故障排除指南。

由于Ingress Nginx是最受欢迎的Ingress控制器,因此在下一部分中我们将介绍一些有关调试ingress-nginx的技巧。

调试Ingress Nginx

Ingress-nginx项目有一个Kubectl的官方插件

你可以用kubectl ingress-nginx来:

  • 检查日志,后端,证书等。
  • 连接到ingress
  • 检查当前配置

你应该尝试的三个命令是:

  • kubectl ingress-nginx lint,它会检查 nginx.conf
  • kubectl ingress-nginx backend,以检查后端(类似于kubectl describe ingress
  • kubectl ingress-nginx logs,查看日志

请注意,你可能需要为Ingress控制器指定正确的名称空间–namespace

四. 总结

如果你不知道从哪里开始,那么在Kubernetes中进行故障排除可能是一项艰巨的任务。

你应该始终牢记从下至上解决问题:从Pod开始,然后通过Service和Ingress向上移动堆栈。

你在本文中了解到的调试技术也可以应用于其他对象,例如:

  • failing Job和CronJob
  • StatefulSets和DaemonSets

本文翻译自learnk8s上的文章A visual guide on troubleshooting Kubernetes deployments


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

Go modules:最小版本选择

$
0
0

一. 介绍

每个依赖管理解决方案都必须解决选择依赖项版本的问题。当前存在的许多版本选择算法都试图识别任何依赖项的“最新最大(latest greatest)”版本。如果您认为语义版本控制(sematic versioning)将被正确应用并且这种社会契约得到遵守,那么这是有道理的。在这样的情况下,依赖项的“最新最大”版本应该是最稳定和安全的版本,并且应与较早版本具有向后兼容性。至少在相同的主版本(major verion)依赖树中是如此。

Go决定采用其他方法,Russ Cox花费了大量时间和精力撰写文章演讲探讨Go团队的版本选择方法,即最小版本选择或MVS(Minimal Version Selection)。从本质上讲,Go团队相信MVS为Go程序实现痴线持久的和可重复的构建提供了最佳的方案。我建议大家阅读这篇文章以了解Go团队为什么相信这一点。

在本文中,我将尽最大努力解释MVS语义,展示一个实际的Go语言示例,并实际使用MVS算法。

二. MVS语义

将Go的依赖项版本选择算法命名为“最小版本选择”是有点用词不当,但是一旦您了解了它的工作原理,您会发现这个名称真的很贴切。如我之前所述,许多选择算法会选择依赖项的“最新最大”版本。我喜欢将MVS视为选择“最新非最大(latest non-greatest)”版本的算法。并不是说MVS不能选择“最新最大”,而是只要项目中的任何依赖项都不需要“最新最大”,那么就不需要该版本。

为了更好地理解这一点,让我们创建一种情况,其中几个module(A,B和C)依赖于同一module(D),但是每个module都需要不同的版本。

img{512x368}

上图显示了module A,B和C如何分别独立地需要module D和各自需要D的不同版本。

如果我启动一个需要module A的项目,那么为了构建代码,我还需要module D。module D可能有很多版本可供选择。例如,假设module D代表sirupsen的logrus module。我可以要求Go向我提供module D所有已存在(打tag)的版本列表。

清单1:

$ go list -m -versions github.com/sirupsen/logrus

github.com/sirupsen/logrus v0.1.0 v0.1.1 v0.2.0
v0.3.0 v0.4.0 v0.4.1 v0.5.0 v0.5.1 v0.6.0 v0.6.1
v0.6.2 v0.6.3 v0.6.4 v0.6.5 v0.6.6 v0.7.0 v0.7.1
v0.7.2 v0.7.3 v0.8.0 v0.8.1 v0.8.2 v0.8.3 v0.8.4
v0.8.5 v0.8.6 v0.8.7 v0.9.0 v0.10.0 v0.11.0 v0.11.1
v0.11.2 v0.11.3 v0.11.4 v0.11.5 v1.0.0 v1.0.1 v1.0.3
v1.0.4 v1.0.5 v1.0.6 v1.1.0 v1.1.1 v1.2.0 v1.3.0
v1.4.0 v1.4.1 v1.4.2

清单2显示了module D存在的所有版本,我们看到其中显示的“最新最大”版本为1.4.2。

该项目应选择哪个版本的module D呢?确实有两种选择。首选是选择“最新的”版本(在主要版本为1的这一行中),即v1.4.2。第二个选择是选择module A所需的版本v1.0.6。

dep这样的依赖工具将选择v1.4.2版,并在语义版本化和遵守社会契约的前提下可以正常工作。但是,考虑到Russ Cox在这里阐述的一些原因,Go会尊重module A的要求并选择版本1.0.6。在需要module的项目的所有依赖项的当前所需版本集合中,Go会选择“最小”版本。换句话说,现在只有module A需要module D,而module A已指定它要求的版本为v1.0.6,所需版本集合中只有v1.0.6,因此Go选择的module D的版本即是它。

如果我引入要求项目导入module B的新代码时会怎样?将module B导入项目后,Go会将项目的module D版本从v1.0.6升级到v1.2.0。Go再次在项目依赖项module A和B的当前所需版本集合(v1.0.6和v1.2.0)中选择了module D的“最小”版本。

如果我再次引入需要项目导入module C的新代码时会怎样?Go将从当前所需版本集合(v1.0.6,v1.2.0,v1.3.2)中选择最新版本(v1.3.2)。请注意,版本v1.3.2仍然是module D(v1.4.2)的“最小”版本,而不是“最新最大”版本。

最后,如果删除刚刚添加的依赖module C的代码会怎样?Go会将项目锁定到module D的版本v1.3.2上。降级到版本v1.2.0将是一个更大的更改,而Go知道版本v1.3.2可以正常并稳定运行,因此版本v1.3.2仍然是module D的“最新但非最大(latest non-greatest)“版本。另外,module文件(go.mod)仅维护快照,而不是日志。没有有关历史撤消或降级的信息。

这就是为什么我喜欢将MVS视为选择“最新非最大(latest non-greatest)”module 版本的算法的原因。希望您现在可以理解为什么Russ Cox在命名算法时选择名称“minimal”。

三. 示例项目

有了上述基础,我将用一个示例项目让你看到Go和MVS算法实际是如何工作的。在此项目中,module D将用logrus module代表,而该项目将直接依赖于rethinkdb-go(moduleA)和golib(moduleB)module。rethinkdb-go和golib module直接依赖logrus module,并且每个module都需要一个不同的logrus版本,并且这些版本都不是logrus的“最新”版本。

img{512x368}

上图显示了三个module之间的独立关系。首先,我将创建项目,初始化module,然后加载VS Code

清单2:

$ cd $HOME
$ mkdir app
$ mkdir app/cmd
$ mkdir app/cmd/db
$ touch app/cmd/db/main.go
$ cd app
$ go mod init app
$ code .

清单2显示了所有要运行的命令。运行这些命令后,以下代码应出现在VS Code中。

img{512x368}

上图显示了项目结构和module文件应包含的内容。有了这个,现在该添加使用rethinkdb-go module的代码了。

清单3:

https://play.golang.org/p/bc5I0Afxhvc

01 package main
02
03 import (
04     "context"
05     "log"
06
07     db "gopkg.in/rethinkdb/rethinkdb-go.v5"
08 )
09
10 func main() {
11     c, err := db.NewCluster([]db.Host{{Name: "localhost", Port: 3000}}, nil)
12     if err != nil {
13         log.Fatalln(err)
14     }
15
16     if _, err = c.Query(context.Background(), db.Query{}); err != nil {
17         log.Fatalln(err)
18     }
19 }

清单3引入了rethinkdb-go module的major版本v5。添加并保存此代码后,Go会查找、下载和提取module,并更新go.mod和go.sum文件。

清单4:

01 module app
02
03 go 1.13
04
05 require gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1

清单4显示了go.mod需要rethinkdb-go module作为直接依赖项,并选择了v5.0.1版本,该版本是该module的“最新最大版本”。

清单5:

...
github.com/sirupsen/logrus v1.0.6 h1:hcP1GmhGigz/O7h1WVUM5KklBp1JoNS9FggWKdj/j3s=
github.com/sirupsen/logrus v1.0.6/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc=
...

清单5显示了go.sum文件中引入logrus module v1.0.6版本的两行。在这一点上,您可以看到MVS算法已经选择了满足rethinkdb-go module指定要求所需的logrus module的“最小”版本。记住logrus module的“最新最大”版本是1.4.2。

注意:go.sum文件不应用于理解依赖关系。我在上面所做的版本确定的操作是错误的,稍后我将向您展示确定项目所使用的版本的正确方法。

img{512x368}

上图显示了Go将使用哪个版本的logrus module来构建项目。

接下来,我将添加引入对golib module有依赖关系的代码。

清单6:

https://play.golang.org/p/h23opcp5qd0

01 package main
02
03 import (
04     "context"
05     "log"
06
07     "github.com/Bhinneka/golib"
08     db "gopkg.in/rethinkdb/rethinkdb-go.v5"
09 )
10
11 func main() {
12     c, err := db.NewCluster([]db.Host{{Name: "localhost", Port: 3000}}, nil)
13     if err != nil {
14         log.Fatalln(err)
15     }
16
17     if _, err = c.Query(context.Background(), db.Query{}); err != nil {
18         log.Fatalln(err)
19     }
20
21     golib.CreateDBConnection("")
22 }

清单6向该程序添加了07和21行行代码。Go查找、下载并解压缩golib module后,以下更改将显示在go.mod文件中。

清单7:

01 module app
02
03 go 1.13
04
05 require (
06     github.com/Bhinneka/golib v0.0.0-20191209103129-1dc569916cba
07     gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1
08 )

清单7显示go.mod文件已被修改为包括golib module的“最新最大”版本依赖关系,该版本恰好没有语义版本标签。

清单8:

...
github.com/sirupsen/logrus v1.0.6 h1:hcP1GmhGigz/O7h1WVUM5KklBp1JoNS9FggWKdj/j3s=
github.com/sirupsen/logrus v1.0.6/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc=
github.com/sirupsen/logrus v1.2.0 h1:juTguoYk5qI21pwyTXY3B3Y5cOTH3ZUyZCg1v/mihuo=
github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
...

清单8显示了go.sum文件中的四行,现在包括logrus module的v1.0.6和v1.2.0版本。查看go.sum文件中列出的两个版本会带来两个问题:

  • 为什么在go.sum文件中列出了两个版本?
  • Go执行构建时将使用哪个版本?

Go团队的Bryan Mills很好地回答了go.sum文件中列出两个版本的原因。

“go.sum文件仍包含旧版本(1.0.6),因为其传递依赖的要求可能会影响其他module的选定版本。我们真的只需要为go.mod文件提供校验和,因为go.mod中声明了这些传递要求的内容,但是由于go mod tidy不够精确,最终我们也保留了源代码的校验和。” golang.org/issue/33008

现在仍然存在在构建项目时将使用哪个版本的logrus module的问题。要正确确定将使用哪些module及其版本,请不要查看该go.sum文件,而应使用go list命令。

清单9:

$ go list -m all | grep logrus

github.com/sirupsen/logrus v1.2.0

清单9显示了在构建项目时将使用logrus module的v1.2.0版本。该-m标志指示go list列出module而不是package。

查看module图可以更深入地了解项目对logrus module的要求。

清单10:

$ go mod graph | grep logrus

github.com/sirupsen/logrus@v1.2.0 github.com/pmezard/go-difflib@v1.0.0
github.com/sirupsen/logrus@v1.2.0 github.com/stretchr/objx@v0.1.1
github.com/sirupsen/logrus@v1.2.0 github.com/stretchr/testify@v1.2.2
github.com/sirupsen/logrus@v1.2.0 golang.org/x/crypto@v0.0.0-20180904163835-0709b304e793
github.com/sirupsen/logrus@v1.2.0 golang.org/x/sys@v0.0.0-20180905080454-ebe1bf3edb33
gopkg.in/rethinkdb/rethinkdb-go.v5@v5.0.1 github.com/sirupsen/logrus@v1.0.6
github.com/sirupsen/logrus@v1.2.0 github.com/konsorten/go-windows-terminal-sequences@v1.0.1
github.com/sirupsen/logrus@v1.2.0 github.com/davecgh/go-spew@v1.1.1
github.com/Bhinneka/golib@v0.0.0-20191209103129-1dc569916cba github.com/sirupsen/logrus@v1.2.0
github.com/prometheus/common@v0.2.0 github.com/sirupsen/logrus@v1.2.0

清单10显示了logrus module在项目中的关系。我将直接提取显示对logrus的依赖要求的行。

清单11:

gopkg.in/rethinkdb/rethinkdb-go.v5@v5.0.1 github.com/sirupsen/logrus@v1.0.6
github.com/Bhinneka/golib@v0.0.0-20191209103129-1dc569916cba github.com/sirupsen/logrus@v1.2.0
github.com/prometheus/common@v0.2.0 github.com/sirupsen/logrus@v1.2.0

在清单11中,这些行显示三个module(rethinkdb-go,golib和common)都需要logrus module。由于有了go list命令,我知道所需的最低版本为v1.2.0。

img{512x368}

上图展示了Go现在将使用哪个版本的logrus module来构建项目中的代码。

四. Go Mod Tidy

在将代码提交/推回存储库之前,请运行go mod tidy以确保module文件是最新且准确的。您在本地构建,运行或测试的代码将随时影响Go对module文件中内容的更新。运行go mod tidy将确保项目具有所需内容的准确和完整的快照,这将帮助您团队中的其他人和您的CI/CD环境。

清单12:

$ go mod tidy

go: finding github.com/Bhinneka/golib latest
go: finding github.com/bitly/go-hostpool latest
go: finding github.com/bmizerany/assert latest

清单12显示了运行go mod tidy后的输出结果。您会在输出中看到两个新的依赖项。这将更改module文件。

清单13:

01 module app
02
03 go 1.13
04
05 require (
06     github.com/Bhinneka/golib v0.0.0-20191209103129-1dc569916cba
07     github.com/bitly/go-hostpool v0.0.0-20171023180738-a3a6125de932 // indirect
08     github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869 // indirect
09     gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1
10 )

清单13显示了go-hostpool和assert module被列为构建项目所需的间接module。之所以在此处列出它们,是因为这些项目当前与module机制不兼容。换句话说,这些项目的任何tag版本或master中“最新的”版本都不存在go.mod文件。

为什么运行go mod tidy后包含了这些module?我可以使用go mod why命令找出答案。

清单14:

$ go mod why github.com/hailocab/go-hostpool

# github.com/hailocab/go-hostpool
app/cmd/db
gopkg.in/rethinkdb/rethinkdb-go.v5
github.com/hailocab/go-hostpool

------------------------------------------------

$ go mod why github.com/bmizerany/assert

# github.com/bmizerany/assert
app/cmd/db
gopkg.in/rethinkdb/rethinkdb-go.v5
github.com/hailocab/go-hostpool
github.com/hailocab/go-hostpool.test
github.com/bmizerany/assert

清单14显示了为什么项目间接需要这些module。rethinkdb-go module需要go-hostpool module,而go-hostpool module需要assert module。

五. 升级依赖关系

该项目具有三个依赖项,每个依赖项都需要logrus module,其中当前正在选择logrus module的v1.2.0版本。在项目生命周期的某个时刻,升级直接和间接依赖关系以确保项目所需的代码是最新的并且可以利用新功能、错误修复和升级安全补丁将变得很重要。要进行升级,Go提供了go get命令。

在运行go get升级项目的依赖项之前,需要考虑几个选项。

使用MVS仅升级必需的直接和间接依赖项

我建议从这种升级开始,直到您了解更多有关项目和module的信息。这是的最保守的形式go get。

清单15:

$ go get -t -d -v ./...

清单15显示了如何使用MVS算法对那些必需依赖项的升级。下面是命令中一些命令行选型的定义。

  • -t flag:考虑构建测试所需的module。
  • -d flag:下载每个module的源代码,但不要构建或安装它们。
  • -v flag:提供详细输出。
  • ./… :在整个源代码树中执行这些操作,并且仅更新所需的依赖项。

对当前项目运行此命令不会导致任何更改,因为该项目已经是最新版本,并且具有构建和测试该项目所需的最低版本。那是因为我刚运行了go mod tidy,项目是新的。

使用最新最大版本仅升级必需的直接和间接依赖项

这种升级会将整个项目的依赖性从“最小”提高到“最新最大”。所需要做的只是将-u标志添加到命令行。

清单16:

$ go get -u -t -d -v ./...

go: finding golang.org/x/net latest
go: finding golang.org/x/sys latest
go: finding github.com/hailocab/go-hostpool latest
go: finding golang.org/x/crypto latest
go: finding github.com/google/jsonapi latest
go: finding gopkg.in/bsm/ratelimit.v1 latest
go: finding github.com/Bhinneka/golib latest

清单16显示了运行带有-u标志的go get命令的输出。此输出无法说明真实情况。如果我问go list命令现在使用哪个版本的logrus module来构建项目,会发生什么情况呢?

清单17:

$ go list -m all | grep logrus

github.com/sirupsen/logrus v1.4.2

清单17显示了如何选择“最新”的logrus。为了使这一选择更加明确,对go.mod文件进行了更改。

清单18:

01 module app
02
03 go 1.13
04
05 require (
06     github.com/Bhinneka/golib v0.0.0-20191209103129-1dc569916cba
07     github.com/bitly/go-hostpool v0.0.0-20171023180738-a3a6125de932 // indirect
08     github.com/bmizerany/assert v0.0.0-20160611221934-b7ed37b82869 // indirect
09     github.com/cenkalti/backoff v2.2.1+incompatible // indirect
10     github.com/golang/protobuf v1.3.2 // indirect
11     github.com/jinzhu/gorm v1.9.11 // indirect
12     github.com/konsorten/go-windows-terminal-sequences v1.0.2 // indirect
13     github.com/sirupsen/logrus v1.4.2 // indirect
14     golang.org/x/crypto v0.0.0-20191206172530-e9b2fee46413 // indirect
15     golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553 // indirect
16     golang.org/x/sys v0.0.0-20191210023423-ac6580df4449 // indirect
17     gopkg.in/rethinkdb/rethinkdb-go.v5 v5.0.1
18 )

清单18在第13行显示版本v1.4.2现在是项目中logrus module的选定版本。构建项目时,Go会注意module文件中的这一行。即使删除了对logrus module的依赖关系更改的代码,该项目的v1.4.2版现在也已被锁定。请记住,降级将是一个更大的变化,而v1.4.2版将不受影响。

go.sum文件中可以看到哪些更改?

清单19:

github.com/sirupsen/logrus v1.0.6/go.mod h1:pMByvHTf9Beacp5x1UXfOR9xyW/9antXMhjMPG0dEzc=
github.com/sirupsen/logrus v1.2.0 h1:juTguoYk5qI21pwyTXY3B3Y5cOTH3ZUyZCg1v/mihuo=
github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo=
github.com/sirupsen/logrus v1.4.2 h1:SPIRibHv4MatM3XXNO2BJeFLZwZ2LvZgfQ5+UNI2im4=
github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE=

清单19显示了go.sum文件中表示logrus的所有三个版本。正如上面的Bryan所解释的,这是因为传递要求可能会影响其他module的选定版本。

img{512x368}
上图展示了Go现在将使用哪个版本的logrus module来构建项目中的代码。

使用最新最大版本升级所有直接和间接依赖项

您可以将./…选项替换为all来升级所有直接和间接依赖项,包括构建项目时也并不需要的依赖项。

清单20:

$ go get -u -t -d -v all

go: downloading github.com/mattn/go-sqlite3 v1.11.0
go: extracting github.com/mattn/go-sqlite3 v1.11.0
go: finding github.com/bitly/go-hostpool latest
go: finding github.com/denisenkom/go-mssqldb latest
go: finding github.com/hailocab/go-hostpool latest
go: finding gopkg.in/bsm/ratelimit.v1 latest
go: finding github.com/google/jsonapi latest
go: finding golang.org/x/net latest
go: finding github.com/Bhinneka/golib latest
go: finding golang.org/x/crypto latest
go: finding gopkg.in/tomb.v1 latest
go: finding github.com/bmizerany/assert latest
go: finding github.com/erikstmartin/go-testdb latest
go: finding gopkg.in/check.v1 latest
go: finding golang.org/x/sys latest
go: finding github.com/golang-sql/civil latest

清单20显示了现在为该项目找到、下载和提取了多少个依赖项。

清单21:

Added to Module File
   cloud.google.com/go v0.49.0 // indirect
   github.com/denisenkom/go-mssqldb v0.0.0-20191128021309-1d7a30a10f73 // indirect
   github.com/google/go-cmp v0.3.1 // indirect
   github.com/jinzhu/now v1.1.1 // indirect
   github.com/lib/pq v1.2.0 // indirect
   github.com/mattn/go-sqlite3 v2.0.1+incompatible // indirect
   github.com/onsi/ginkgo v1.10.3 // indirect
   github.com/onsi/gomega v1.7.1 // indirect
   github.com/stretchr/objx v0.2.0 // indirect
   google.golang.org/appengine v1.6.5 // indirect
   gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15 // indirect
   gopkg.in/yaml.v2 v2.2.7 // indirect

Removed from Module File
   github.com/golang/protobuf v1.3.2 // indirect

清单21显示了对该go.mod文件的更改。添加了更多module,并删除了一个module。

注意:如果你使用vendor,则go mod vendor命令将从vendor文件夹中剥离test文件。

通常,通过go get升级项目的依赖项时不要使用all或-u选项。坚持只升级需要的module,并使用MVS算法选择这些module及其版本。必要时手动更改为特定的module版本。手动更改可以通过手动编辑go.mod文件来完成,我将在以后的文章中向您展示。

五. 重置依赖关系

如果您在任何时候都不满意所选的module和版本,则你始终可以通过删除module文件并再次运行go mod tidy来重置选择。当项目还很年轻并且情况不稳定时,这更是一种选择。项目稳定并发布后,我会犹豫重新设置依赖关系。正如我上面提到的,随着时间的推移,可能会设置module版本,并且您需要长期持久且可重复的构建。

清单22:

$ rm go.*
$ go mod init <module name>
$ go mod tidy

清单22显示了允许MVS从头开始再次执行所有选择的命令。在撰写本文的整个过程中,我一直在进行此操作以重置项目并提供本文的代码清单。

六. 结论

在这篇文章中,我解释了MVS语义,并展示了Go和MVS算法实际应用的真实示例。我还展示了一些Go命令,这些命令可以在您遇到未知问题时为您提供信息。在为项目添加越来越多的依赖项时,可能会遇到一些极端情况。这是因为Go生态系统已有10年的历史,所有现有项目都需要更多时间才能符合module要求。

在以后的文章中,我将讨论在同一项目中使用不同主要版本的依赖关系,以及如何手动检索和锁定依赖关系的特定版本。现在,我希望您对module和Go工具有更多的信任,并且对MVS如何随着时间的推移选择版本有了更清晰的了解。如果您遇到任何问题,可以在#module组的Gopher Slack上找到一群愿意提供帮助的人。

本文翻译自《Modules Part 03: Minimal Version Selection》


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2019, bigwhite. 版权所有.

图解Go内存分配器

$
0
0

本文翻译自《A visual guide to Go Memory Allocator from scratch (Golang)》

当我刚开始尝试了解Go的内存分配器时,我发现这真是一件可以令人发疯的事情,因为所有事情似乎都像一个神秘的黑盒(让我无从下手)。由于几乎所有技术魔法都隐藏在抽象之下,因此您需要逐一剥离这些抽象层才能理解它们。

在这篇文章中,我们就来这么做(剥离抽象层去了解隐藏在其下面的技术魔法)。如果您想了解有关Go内存分配器的知识,那么本篇文章正适合您。

一. 物理内存(Physical Memory)和虚拟内存(Virtual Memory)

每个内存分配器都需要使用由底层操作系统管理的虚拟内存空间(Virtual Memory Space)。让我们看看它是如何工作的吧。

img{512x368}

物理存储单元的简单图示(不精确的表示)

单个存储单元(工作流程)的简要介绍:

  1. 地址线(address line, 作为开关的晶体管)提供了访问电容器的入口(数据到数据线(data line))。
  2. 当地址线中有电流流动时(显示为红色),数据线可能会写入电容器,因此电容器已充电,并且存储的逻辑值为“1”。
  3. 当地址线没有电流流动(显示为绿色)时,数据线可能不会写入电容器,因此电容器未充电,并且存储的逻辑值为“0”。
  4. 当处理器(CPU)需要从内存(RAM)中“读取”一个值时,会沿着“地址线”发送电流(关闭开关)。如果电容器保持电荷,则电流流经“ DATA LINE”(数据线)得到的值为1;否则,没有电流流过数据线,电容器将保持未充电状态,得到的值为0。

img{512x368}

物理内存单元如何与CPU交互的简单说明

数据总线(Data Bus):用于在CPU和物理内存之间传输数据。

让我们讨论一下地址线(Address Line)和可寻址字节(Addressable Bytes)。

img{512x368}

CPU和物理内存之间的地址线的表示
  1. DRAM中的每个“字节(BYTE)”都被分配有唯一的数字标识符(地址)。 但“物理字节的表示 != 地址线的数量”。(例如:16位Intel 8088,PAE)
  2. 每条“地址线”都可以发送1bit值,因此它可以表示给定字节地址中指定“bit”。
  3. 在图中,我们有32条地址线。因此,每个可寻址字节都将拥有一个“32bit”的地址。
[ 00000000000000000000000000000000 ] — 低内存地址
[ 11111111111111111111111111111111 ] — 高内存地址

4.由于每个字节都有一个32bit地址,所以我们的地址空间由2的32次方个可寻址字节(即4GB)组成。

因此,可寻址字节取决于地址线的总量,对于64位地址线(x86–64 CPU),其可寻址字节为2的64次方个,但是大多数使用64位指针的体系结构实际上使用48位地址线(AMD64 )和42位地址线(英特尔),理论上支持256TB的物理RAM(Linux 在x86–64上每个进程支持128TB以及4级页表(page table)和Windows每个进程则支持192TB)

由于实际物理内存的限制,因此每个进程都在其自己的内存沙箱中运行-“虚拟地址空间”,即虚拟内存

该虚拟地址空间中字节的地址不再与处理器在地址总线上放置的地址相同。因此,必须建立转换数据结构和系统,以将虚拟地址空间中的字节映射到物理内存地址上的字节。

虚拟地址长什么样呢?

img{512x368}

虚拟地址空间表示

因此,当CPU执行引用内存地址的指令时。第一步是将VMA(virtual memory address)中的逻辑地址转换为线性地址(liner address)。这个翻译工作由内存管理单元MMU(Memory Management Unit)完成。

img{512x368}

这不是物理图,仅是描述。为了简化,不包括地址翻译过程

由于此逻辑地址太大而无法单独管理(取决于各种因素),因此将通过页(page)对其进行管理。当必要的分页构造被激活后,虚拟内存空间将被划分为称为页的较小区域(大多数OS上页大小为4KB,可以更改)。它是虚拟内存中用于内存管理的最小单位。虚拟内存不存储任何内容,仅简单地将程序的地址空间映射到真实的物理内存空间上。

单个进程仅将VMA(虚拟内存地址)视为其地址。这样,当我们的程序请求更多“堆内存(heap memory)”时会发生什么呢?

img{512x368}

一段简单的用户请求更多堆内存的汇编代码

img{512x368}

增加堆内存

程序通过brk(sbrk/mmap等)系统调用请求更多内存。但内核实际上仅是更新了堆的VMA。

注意:此时,实际上并没有分配任何页帧,并且新页面也没有在物理内存存在。这也是VSZ与RSS之间的差异点。

二. 内存分配器

有了“虚拟地址空间”的基本概述以及堆内存增加的理解之后,内存分配器现在变得更容易说明了。

如果堆中有足够的空间来满足我们代码中的内存请求,则内存分配器可以在内核不参与的情况下满足该请求,否则它会通过系统调用brk扩大堆,通常会请求大量内存。(默认情况下,对于malloc而言,大量的意思是 > MMAP_THRESHOLD字节-128kB)。

但是,内存分配器的责任不仅仅是更新brk地址。其中一个主要的工作则是如何的降低内外部的内存碎片以及如何快速分配内存块。考虑按p1~p4的顺序,先使用函数malloc在程序中请求连续内存块,然后使用函数free(pointer)释放内存。

img{512x368}

外部内存碎片演示

在第4步,即使我们有足够的内存块,我们也无法满足对6个连续内存块分配的请求,从而导致内存碎片。

那么如何减少内存碎片呢?这个问题的答案取决于底层库使用的特定的内存分配算法。

我们将研究TCMalloc内存分配器,Go内存分配器采用的就是该内存分配器模型。

三. TCMalloc

TCMalloc(thread cache malloc)的核心思想是将内存划分为多个级别,以减少锁的粒度。在TCMalloc内部,内存管理分为两部分:线程内存和页堆(page heap)。

线程内存(thread memory)

每个内存页分为多级固定大小的“空闲列表”,这有助于减少碎片。因此,每个线程都会有一个无锁的小对象缓存,这使得在并行程序下分配小对象(<= 32k)非常高效。

img{512x368}

线程缓存(每个线程拥有此线程本地线程缓存)

页堆(page heap)

TCMalloc管理的堆由页集合组成,其中一组连续页的集合可以用span表示。当分配的对象大于32K时,将使用页堆进行分配。

img{512x368}

页堆(用于span管理)

如果没有足够的内存来分配小对象,内存分配器就会转到页堆以获取内存。如果还没有足够的内存,页堆将从操作系统中请求更多内存。

由于这种分配模型维护了一个用户空间的内存池,因此极大地提高了内存分配和释放的效率。

注意:尽管go内存分配器最初是基于tcmalloc的,但是现在已经有了很大的不同。

四. Go内存分配器

我们知道Go运行时会将Goroutines(G)调度到逻辑处理器(P)上执行。同样,基于TCMalloc模型的Go还将内存页分为67个不同大小级别。

如果您不熟悉Go调度程序,则可以在这里获取关于Go调度程序的相关知识。

img{512x368}

Go中的内存块的大小级别

Go默认采用8192B大小的页。如果这个页被分成大小为1KB的块,我们一共将拿到8块这样的页:

img{512x368}

将8 KB页面划分为1KB的大小等级(在Go中,页的粒度保持为8KB)

Go中的这些页面运行也通过称为mspan的结构进行管理。

选择要分配给每个尺寸级别的尺寸类别和页面计数(将页面数分成给定尺寸的对象),以便将分配请求圆整(四舍五入)到下一个尺寸级别最多浪费12.5%

mspan

简而言之,它是一个双向链表对象,其中包含页面的起始地址,它具有的页面的span类以及它包含的页面数。

img{512x368}

Go内存分配器中mspan的表示形式

mcache

与TCMalloc一样,Go为每个逻辑处理器(P)提供了一个称为mcache的本地内存线程缓存,因此,如果Goroutine需要内存,它可以直接从mcache中获取它而无需任何锁,因为在任何时间点只有一个Goroutine在逻辑处理器(P)上运行。

mcache包含所有级别大小的mspan作为缓存。

img{512x368}

Go中P,mcache和mspan之间的关系

由于每个P拥有一个mcache,因此从mcache进行分配时无需加锁。

对于每个级别,都有两种类型。
* scan —包含指针的对象。
* noscan —不包含指针的对象。

这种方法的好处之一是在进行垃圾收集时,GC无需遍历noscan对象。

什么Go mcache?

对象大小<= 32K字节的分配将直接交给mcache,后者将使用对应大小级别的mspan应对

当mcache没有可用插槽(slot)时会发生什么?

从mcentral mspan list中获取一个对应大小级别的新的mspan。

mcentral

mcentral对象集合了所有给定大小级别的span,每个mcentral是两个mspan列表。

  1. 空的mspanList — 没有空闲内存的mspan或缓存在mcache中的mspan的列表
  2. 非空mspanList – 仍有空闲内存的span列表。

当从mcentral请求新的Span时,它将从非空mspanList列表中获取(如果可用)。这两个列表之间的关系如下:当请求新的span时,该请求从非空列表中得到满足,并且该span被放入空列表中。释放span后,将根据span中空闲对象的数量将其放回非空列表。

img{512x368}

mcentral表示

每个mcentral结构都在mheap中维护。

mheap

mheap是在Go中管理堆的对象,且只有一个全局mheap对象。它拥有虚拟地址空间。

img{512x368}

mheap的表示

从上图可以看出,mheap具有一个mcentral数组。此数组包含每个大小级别span的mcentral。

central [numSpanClasses]struct {
      mcentral mcentral
        pad      [sys.CacheLineSize unsafe.Sizeof(mcentral{})%sys.CacheLineSize]byte
}

由于我们对每个级别的span都有mcentral,因此当mcache从mcentral请求一个mspan时,仅涉及单个mcentral级别的锁,因此其他mache的不同级别mspan的请求也可以同时被处理。

padding确保将MCentrals以CacheLineSize字节间隔开,以便每个MCentral.lock获得自己的缓存行,以避免错误的共享问题。

那么,当该mcentral列表为空时会发生什么?mcentral将从mheap获取页以用于所需大小级别span的分配。

  • free [_MaxMHeapList]mSpanList:这是一个spanList数组。每个spanList中的mspan由1〜127(_MaxMHeapList-1)页组成。例如,free[3]是包含3个页面的mspan的链接列表。Free表示空闲列表,即尚未进行对象分配。它对应于忙碌列表(busy list)。

  • freelarge mSpanList:mspans列表。每个mspan的页数大于127。Go内存分配器以mtreap数据结构来维护它。对应busyLarge。

大小> 32k的对象是一个大对象,直接从mheap分配。这些较大的请求需要中央锁(central lock),因此在任何给定的时间点只能满足一个P的请求

五. 对象分配流程

  • 大小> 32k是一个大对象,直接从mheap分配。
  • 大小<16B,使用mcache的tiny分配器分配
  • 大小在16B〜32k之间,计算要使用的sizeClass,然后在mcache中使用相应的sizeClass的块分配
  • 如果与mcache对应的sizeClass没有可用的块,则向mcentral发起请求。
  • 如果mcentral也没有可用的块,则向mheap请求。mheap使用BestFit查找最合适的mspan。如果超出了申请的大小,则会根据需要进行划分,以返回用户所需的页面数。其余页面构成一个新的mspan,并返回mheap空闲列表。
  • 如果mheap没有可用的span,请向操作系统申请一组新的页(至少1MB)。

但是Go在OS级别分配的页面甚至更大(称为arena)。分配大量页面将分摊与操作系统进行对话的成本。

所有请求的堆内存都来自于arena。让我们看看arena是什么。

六. Go虚拟内存

让我们看一个简单go程序的内存。

func main(){
    for {}
}

img{512x368}

程序的进程状态

因此,即使是简单的go程序,占用的虚拟空间也是大约100MB而RSS只有696kB。让我们尝试首先找出这种差异的原因。

img{512x368}

map和smap统计信息

因此,内存区域的大小约为〜2MB, 64MB and 32MB。这些是什么?

Arena

原来,Go中的虚拟内存布局由一组arena组成。初始堆映射是一个arena,即64MB(基于go 1.11.5)。

img{512x368}

当前在不同系统上的arena大小。

因此,当前根据程序需要,内存以较小的增量进行映射,并且它以一个arena(〜64MB)开始。

这是可变的。早期的go保留连续的虚拟地址,在64位系统上,arena大小为512 GB。(如果分配足够大并且被mmap拒绝,会发生什么?)

这个arena集合是我们所谓的堆。Go以8192B大小粒度的页面管理每个arena。

img{512x368}

单个arena(64 MB)。

Go还有两个span和bitmap块。它们都在堆外分配,并存储着每个arena的元数据。它主要在垃圾收集期间使用(因此我们现在将其保留)。

我们刚刚讨论过的Go中的内存分配策略,但这些也仅是奇妙多样的内存分配的一些皮毛。

但是,Go内存管理的总体思路是使用不同的内存结构为不同大小的对象使用不同的缓存级别内存来分配内存。将从操作系统接收的单个连续地址块分割为多级缓存以减少锁的使用,从而提高内存分配效率,然后根据指定的大小分配内存分配,从而减少内存碎片,并在内存释放houhou有利于更快的GC。

现在,我将向您提供此Go Memory Allocator的全景图。

img{512x368}

运行时内存分配器的可视化全景图。

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2020, bigwhite. 版权所有.

Go语言之禅

$
0
0

本文翻译自Go社区知名Gopher和博主Dave Cheney的文章《The Zen of Go》

img{512x368}

本文来自我在GopherCon Israel 2020上的演讲。文章很长:) 如果您希望阅读精简版,请移步到the-zen-of-go.netlify.com

该演讲视频还未上线。如上线,我会把它更新到本文中的。

我应该如何编写出好代码?

我最近一直在思考很多事情,每当反思自己的工作成果时,眼前常会出现一行字幕:我该如何编写出好代码? 主观上,没人愿意去编写糟糕的代码,那么问题来了:你是怎么知道你编写出好的Go代码了呢?

如果好与坏之间存在连续性,那么我们怎么知道哪些是好的部分?它的特性、属性、标志、模式和惯用法又是什么呢?

Go语言惯用法(idiomatic Go)

img{512x368}

这让我走进Go惯用法。说某种东西是惯用的,就是说它遵循了时代的风格。如果某些东西不是惯用的,那它没有遵循流行的风格,感觉不时髦。

更重要的是,对某人说他们的代码不复合惯用法并不能解释为什么这些代码不符合惯用法。为什么会这样?像所有真相一样,答案可以在词典中找到:

idiom (noun): a group of words established by usage as having a meaning not deducible from those of the individual words.
惯用法(名词):一组由用法确定的且其含义无法从单个单词的含义中推导出来的单词。

惯用法是共享价值观(value)的标志。Go惯用法不是您从书本中学到的东西,而是通过成为社区的一部分而获得的

img{512x368}

Go惯用法字样用多了,便形成了“口头禅”,这引起我的担忧:这种口头禅在许多方面它可能是具有排他性的。比如:有人说“你不能和我们坐在一起。” 但毕竟这不是我们批评某人的代码不符合惯用法时的索要表达的意思,是吧?他们只是没有做对,看起来不对,它没有遵循流行的风格而已。

我认为Go惯用法不是教如何编写好的Go代码的合适机制,因为从根本上说,它仍然告诉某人做错了(译注:这容易引起对方反感)。如果在他们最愿意接受建议的时候,我们给出让他们不感觉疏远的建议是否会更好些?

谚语(Proverbs)

摆脱有问题的惯用法,Gopher们还有哪些其他的文化手工艺品吗?也许我们可以转向Rob Pike精彩的Go 谚语。这些谚语是合适的教学工具吗?它们会告诉Go新手如何编写好的Go代码吗?

总的来说,我不这么认为。这并不是要驳斥Rob Pike的作品。只是像濑越宪作(Segoe Kensaku)的原著一样,Go谚语只是观察,而不是价值观的陈述。我们再次搬出字典:

proverb (noun): a short, well-known pithy saying, stating a general truth or piece of advice.
谚语(名词):简短而众所周知的俗语,陈述一般的真理或一段忠告。

Go Proverbs的目的是揭示有关语言设计的更深层次的真理,但是像empty interface says nothing这样的建议对于一个来自商没有结构化类型的语言的新手来说有什么用呢?

重要的是要认识到,在一个不断发展的社区中,任何时候学习Go语言的人的数量都远超过那些声称掌握了该语言的人的数量。因此,在这种情况下,谚语可能也不是最佳的教学工具。

工程价值观

丹·卢(Dan Luu)找到了马克·卢科夫斯基(Mark Lucovsky)关于Windows团队在Windows NT-Windows 2000开发阶段时的工程文化的演讲。我之所以提到它,是因为卢科夫斯基将一种文化描述为一种评估设计和权衡取舍的常用方法。

img{512x368}

讨论文化的方法有很多,但是就工程文化而言,Lucovsky的描述是恰当的。其中心思想是在未知的设计空间中用价值观指导决策。Windows NT团队的价值观是:可移植性,可靠性,安全性和可扩展性。粗略地说工程价值观就是在这里完成工作的方式。

Go的价值观

Go的显式价值观是什么呢?定义Go程序员解释世界方式的核心信念或哲学又是什么?他们如何发布宣传?他们怎么传授?如何执行?它们又是如何随着时间变化的?

作为新Go程序员,您将如何被灌输Go的工程价值观?或者,你是一位经验丰富的Go专家,你如何将你的价值观传播给“下一代”?就像我们知道的那样,知识传递的过程不是一个可选项。没有新的血液和新的观念,我们的社区将变得短视和枯萎。

其他语言的价值观

为了给我所要了解的场景做铺垫,我们可以先看看其他语言,我们看看它们的工程价值观。

例如,C++(包括其扩展:Rust)认为程序员不必为自己不使用的特性付费。如果程序未使用该语言的某些计算成本昂贵的特性,则不应强迫该程序承担该特性的成本。该价值观从语言扩展到其标准库,并用作判断所有用C++编写的代码设计的标准。

在Java,Ruby和Smalltalk中,一切都是对象的核心价值观驱动着围绕着消息传递,信息隐藏和多态的程序设计风格。在程序中采用过程式或函数式设计风格会被认为是错误的,或者按照Gophers的说法,是不符合惯用法的。

回到我们自己的Go社区,烙印在Go程序员心中的工程价值观是什么呢?在我们社区中的讨论是很容易引战的,因此要从第一条原则衍生出一套价值观念将是一个巨大的挑战。共识很关键,但随着讨论贡献者数量的增加,难度就成倍增加。但是,如果有人已经为我们完成了这些艰苦的工作了呢?

~~Python~~ Go之禅

几十年前,蒂姆·彼得斯(Tim Peters)坐下来写下了PEN-20(Python之禅)。Peters试图记录他认为Guido van Rossum(Python之父)在Python社区扮演的BDFL(仁慈的独裁者)角色时所应用的工程价值观。

在本文的剩余部分中,我将着眼于Python之禅,并问问大家:是否有什么可以用来揭秘Go程序员的工程价值观的?

一个好的package始于一个好名字

让我们从香辛的东西开始

“Namespaces are one honking great idea–let’s do more of those!” The Zen of Python, Item 19
“命名空间是一个很棒的主意-让我们多做些吧!” Python之禅,条款19

这是相当明确的,Python程序员应该使用命名空间,多多益善。

package就是Go语言的命名空间。我怀疑是否有人质疑将组件分组到程序包中利好设计和潜在重用。但关于这么做的正确方法的困惑肯定会有的,尤其是你拥有另一门语言10年的使用经验。

在Go中,每个程序包都应有一个目的/用途,而了解程序包目的/用途的最佳方法是通过其名字-一个名词。包的名字描述了它提供的内容。因此,这里重新解释一下Peters的话:每个Go软件包(package)都应该仅有一个单一的目的/用途。

这不是一个新主意,我已经说了一段时间了,但是为什么要这样做而不是使用将软件包用于细粒度分类的方法呢?为什么,因为变化(change)。

“Design is the art of arranging code to work today, and be changeable forever.” - Sandi Metz
“设计是安排代码以使其至今天仍然可以工作并且永远可以更改的艺术。” - 桑迪·梅斯

变化是我们所从事的游戏的名称(译注:这里的游戏指代程序开发工作)。作为程序员,我们要做的就是管理变变化。当我们做得很好时,我们称之为设计或架构。当我们做得不好时,我们称其为技术债务或遗留代码。

如果你编写的程序对于一组固定的输入可以一次性地完美地工作,那么没人会在乎代码的好坏,因为最终程序的输出才是企业和业务所关心的。

但这是不正确的。软件具有缺陷(bug),需求变更,输入变更,并且很少有程序被编写为仅执行一次,因此您的程序会随着时间而变化。可能是您要为此承担任务,更有可能是其他人,但是必须更改该代码。有人必须维护该代码。

那么,如何使程序更改变得容易呢?无所不在的接口?使一切变得易于mock?邪恶的依赖注入(译注:作者对DI似乎很排斥,用了带有感情色彩的词汇)?好吧,也许,对于某类程序,但不是很多,这些技术将很有用。但是,对于大多数程序而言,预先设计一些灵活的方法要比工程设计更为重要。

相反,如果我们采取的立场是取代组件而不是增强组件,该怎么办?知道何时需要更换某些物品的最佳方法是什么时候该物品没有按照锡盒/罐头盒上的说明进行操作。

一个好的包始于选择一个好的名字。把你的包名字想象成电梯游说(Elevator pitch,即用极具吸引力的方式简明扼要地阐述自己的观点), 仅用一个词就可以描述包的内容。当名字不再符合要求时,请查找替代名字。

简单性很重要

“Simple is better than complex.” - The Zen of Python, Item 3
“简单胜于复杂。” - Python之禅,条款3

PEP-20说:简单胜于复杂,我完全同意。几年前,我发布了这条推文:

大多数编程语言开始都是为了简单,但最终只是为了功能强大而努力。— Dave Cheney(@davecheney)2014年12月2日

至少在当时,我的观察是,我想不出一生中使用的哪门语言不标榜着简单。每种新语言都为其固有的简单性提供了理由和诱因。但是,当我研究时,我发现简单性并不是与Go语言同时代的许多现代语言的核心价值观。也许这只是一个便宜的镜头1,但是可能是这些语言不是很简单,或者它们不认为自己很简单。他们不认为简单是其核心价值观。

但是什么时候简单变得过时了?为什么商业软件开发行业会忘记这个基本原则?

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” - C. A. R. Hoare, The Emperor’s Old Clothes, 1980 Turing Award Lecture

“构建软件设计的方式有两种:一种方式是使其变得如此简单,以至于显然没有缺陷,另一种方式是使得它变得如此复杂以至于没有明显的缺陷。第一种方法要困难得多。” - CAR Hoare,皇帝的旧衣,1980年图灵奖演讲

我们知道:简单并不意味着容易。通常,使某些东西易于使用而不是易于构建需要更多的工作。

“Simplicity is prerequisite for reliability.” - Edsger W Dijkstra, EWD498, 18 June 1975
“简单性是可靠性的前提。”-  埃兹格·迪克斯特拉(Essger W Dijkstra),EWD498,1975年6月18日

我们为什么要追求简单?为什么Go程序简单很重要?简单并不意味着粗糙,它意味着可读性和可维护性。简单并不意味着“不复杂”,它意味着可靠,有共鸣且易于理解。

“Controlling complexity is the essence of computer programming.” - Brian W. Kernighan, Software Tools (1976)
“控制复杂性是计算机编程的本质。” - Brian W. Kernighan,软件工具  (1976)

Python是否遵守其简单性的说法尚有争议,但Go坚持将简单性作为核心价值观。我认为我们都可以认同,就Go而言,简单代码比聪明代码更可取

避免包级别状态

“Explicit is better than implicit.” - The Zen of Python, Item 2
“显式胜于隐式。” - Python的禅宗,第2项

我认为彼得斯在这个地方的抱负胜于实际。Python中的许多内容并不明确;装饰器,dunder方法(译注:不知此为何物)等。毫无疑问,这些特性的功能强大,存在这些特性是有原因的。每个特性都是因某人非常关心的事情,尤其是复杂的特性。但是大量使用这些特性使读者很难预测操作的成本。

好消息是,像Go程序员一样,我们可以选择显式代码。显式可能意味着很多事情,也许您可能认为显式只是一种表达官僚主义和漫长风气的好方法,但这只是肤浅的解释。只关注页面的语法、烦恼行长和自制表达式是一种错误的说法。在我看来,更有价值的地方是与耦合和状态有关。

耦合(coupling)是衡量一件东西依赖另一件东西的数量的方法。如果两件事紧密结合,它们就会一起运动。影响其中一个事物的行为会直接反映在另一个事物中。想象一下,一列火车,每个车厢连在一起;发动机行驶到哪里,车厢就跟随到哪里。

描述耦合的另一种方法是内聚(cohesion)一词。内聚衡量两件事自然地在一起的程度。当我们进行一个内聚的争论,或者一个内聚的团队,它们的所有零件都可以自然装配在一起,就像设计的一样。

为什么耦合很重要?因为就像火车一样,当您需要更改一段代码时,与之紧密相关的所有代码都必须更改。一个再适合不过的例子:有人发布了他们的API的新版本,现在您的代码无法通过编译了。

API是不可避免的耦合源,但是存在更多隐蔽的耦合形式。显然,每个人都知道,如果API的原型发生更改,则该调用的传入和返回数据都会发生变化。就在函数原型中;我采用这些类型的值,并返回其他类型的值。但是,如果API以其他方式传递数据怎么办?如果每次调用此API的结果都是基于上次调用该API的结果,即使您没有更改参数该怎么办?

这是状态,状态管理是计算机科学中的问题。

package counter

var count int

func Increment(n int) int {
        count += n
        return count
}

假设我们有这个简单的counter包。您可以调用Increment以增加计数器,即便传入0,你也可以得到返回值。

假设您必须测试此代码,那么每次测试后如何重置计数器?假设您想并行运行这些测试,可以吗?现在,假设您要为每个程序进行不止一个计数,您可以这样做吗?

不,当然不行。显然,答案是将count变量封装为类型。

package counter

type Counter struct {
        count int
}

func (c *Counter) Increment(n int) int {
        c.count += n
        return c.count
}

现在想象一下,这个问题不局限于计数器,还包括应用程序的主要业务逻辑。您可以单独测试吗?您可以并行测试吗?您一次可以使用多个实例吗?如果回答那些问题为否,则原因是软件的包级别状态。

避免包级别状态。通过提供一种类型需要的依赖项作为该类型上的字段,而不是使用包变量,来减少耦合和怪异的行为。

为失败而计划,而不是成功而计划

“Errors should never pass silently.” - The Zen of Python, Item 10
“错误绝不能默默传递。” - Python之禅,条款10

有人说过,支持异常处理的语言遵循武士原则(Samurai principle)。要么全胜归来,要么(失败)全不回来。在基于异常的语言中,函数仅返回有效结果。如果他们没有成功,那么控制流程将采纳完全不同的路径。

未检查的异常显然是不安全的编程模型。当您不知道哪些语句可能引发异常时,如何在存在错误的情况下编写健壮的代码?Java尝试通过引入checked exception的概念来使异常更安全,据我所知,这种checked exception在另一种主流语言中没有被引入。有很多使用异常的语言,但是除了Java,所有语言都使用未经检查的各种异常(unchecked exception)。

显然,Go选择了不同的路径。Go程序员认为,健壮的程序是由处理失败情况的片段组成的,然后再处理happy path。在Go设计的空间中:服务器程序,多线程程序,处理网络输入的程序,如果要构建可靠的程序,那么处理意外数据、超时、连接失败和损坏的数据必须是程序员的首要任务。

“I think that error handling should be explicit, this should be a core value of the language.” - Peter Bourgon, GoTime #91
“我认为错误处理应该是显式的,这应该是语言的一个核心价值观。” - 彼得·布尔贡(Peter Bourgon),GoTime#91

我想回应彼得的主张,因为这是本文的动力。我认为Go的成功很大程度上归功于显式的处理错误的方式。Go程序员首先考虑失败情况。我们首先解决如果...怎么办的情况。这导致程序在编写时处理故障,而不是在生产中处理故障。

反复出现的下面代码片段:

if err != nil {
    return err
}

所付出的成本已基本被在故障发生时刻意处理每个故障情况的价值超过了(译者注:上面的重复代码段也是利大于弊)。关键还在于显式处理每个错误的文化价值观。

早点返回,而不是深层嵌套

“Flat is better than nested.” - The Zen of Python, Item 5
“扁平比嵌套更好。” - Python的禅宗,条款5

这是一个明智的建议,而且它来自以缩进作为控制流主要形式的语言。我们如何用Go来解释这个建议呢?gofmt控制Go程序的整体风格(空白与缩进),因此无需执行任何额外操作。

我之前写过关于package名字的文章,这里可能有一些建议:避免复杂的软件包层次结构。以我的经验,程序员越努力细分和分类Go代码库,他们越有可能陷入包导入循环的死角。

我认为第5项条款建议的最佳应用是函数内的控制流。简而言之,避免需要控制流缩进过深。

“Line of sight is a straight line along which an observer has unobstructed vision.” - May Ryer, "Code: Align the happy path to the left edge" https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88

“代码行展现给观察者的视觉效果应该是一条畅通的直线。- May Ryer, “代码:将快乐路径对齐到左边缘”

Mat Ryer将这种想法描述为视线编码(line of sight coding )。视线编码意味着:

  • 如果不满足前提条件,则使用保护子句尽早返回。
  • 将成功的return语句放在函数的末尾,而不是放在条件代码块中。
  • 通过提取函数和方法来降低函数的整体缩进级别。

该建议的关键是您所关心的事情,功能所要做的事情永远不会有在屏幕右侧滑出视线的危险。这种风格有一个额外的副作用,您可以避免团队中对行长度的毫无意义的争论。

每次缩进时,都会向程序员堆栈添加另一个先决条件,从而消耗他们的7±2个短期内存插槽之一(译注:7±2指的是人类能短期记忆的事件数量大约是7,±2是个体差异)。将函数的成功执行路径贴近屏幕左手侧,不要深入嵌套。

如果你认为它性能差,请通过基准测试证明

“In the face of ambiguity, refuse the temptation to guess.” - The Zen of Python, Item 12
“面对模棱两可,拒绝猜测的诱惑。” - Python之禅,条款12

编程基于数学和逻辑,这两个概念很少涉及机会元素。但是,作为程序员,我们每天都在猜测许多事情。这个变量有什么作用?此参数有什么作用?如果我在这类传入nil会怎样?如果我调用Register两次会怎样?实际上,现代编程中存在很多猜测,尤其是在使用不是你编写的库时。

“APIs should be easy to use and hard to misuse.”  - Josh Bloch
“API应该易于使用并且不容易被滥用。” - 乔什·布洛赫(Josh Bloch)

我知道的帮助程序员避免猜测的最好方法之一是在构建API时,应专注于默认用例。使调用者尽可能轻松地执行最常见的事情。但是,我过去写过很多关于API设计的文章,所以我对第12项的解释是:不要猜测性能

尽管您可能考虑到Knuth的建议,但Go语言成功的推动力之一是其高性能的执行。您可以在Go中编写高性能的程序,因此人们会因此选择Go。关于性能有很多误解,所以我的要求是,当您希望对代码进行性能调优时,或者遇到一些教条式的建议时,例如defer缓慢,CGO昂贵,或者始终使用原子操作而不是互斥锁时,请不要猜。

不要因为过时的教条而使您的代码复杂化,并且,如果您认为某些事情很慢,请首先使用基准测试进行证明。Go提供了出色的基准测试和性能分析工具,这些工具均可免费获得。使用它们来找出您程序中的性能瓶颈。

在启动goroutine之前,请知道它何时会停止

在这一点上,我认为我已经从PEP-20中挖掘了有价值的要点,并且可能扩展其重新解释的范围。我认为很好,因为尽管这是一种有用的修辞手法,但最终我们还是在谈论两种不同的语言。

“You type go, a space, and then a function call. Three keystrokes, you can’t make it much shorter than that. Three keystrokes and you’ve just started a sub process.” - Rob Pike, Simplicity is Complicated, dotGo 2015

“您键入go,一个空格和一个函数调用。三次按键,您不能做到比这还短了。三次按键,您就启动了一个子过程。” - 罗伯·派克(Rob Pike),Simplicity is Complicated,dotGo,2015年

接下来的两个建议,我将专注于goroutines。Goroutines是语言的标志性功能,这是我们给出的关于一等公民(first class)并发的答案。它们非常易于使用,只需将单词go放在语句前面,即可异步启动该函数。非常简单,没有线程,没有堆栈大小,没有线程池执行程序(thread pool executor),没有ID,没有跟踪完成状态。

Goroutines代价很低。由于运行时(runtime)能够将goroutine多路复用到一个小的线程池中(您不必管理),因此可以轻松容纳数十万,数百万个goroutine。这开创了在竞争性并发模型(例如线程或事件回调)下不可行的设计。

但是,即便如goroutine一样便宜,但它们也不是免费的。至少它们的堆栈有几千字节,当您启动10^6个goroutine时,它们的确开始累加。这并不是说就不应该使用数百万个goroutine,如果你的设计需要,可以做。但是当您这样做时,请务必对其进行跟踪,因为10^6数量级的任何东西累计可能消耗的资源都不是少量的。

Goroutines是Go中资源所有权的关键。为了程序有用,goroutine必须做一些事情,这意味着它几乎总是持有对资源的引用或所有权:锁、网络连接、带有数据的缓冲区、channel的发送端。当该goroutine处于活动状态时,将持有锁,保持网络连接打开,保留缓冲区,并且channel的接收器将继续等待更多数据。

释放这些资源的最简单方法是将它们与goroutine的生命周期相关联-当goroutine退出时,资源释放。因此,尽管开始执行goroutine几乎是微不足道的,但在进行三次按键(go+空格)前,请确保您对以下问题有答案:

  • goroutine在什么情况下会停止? Go没有办法告诉goroutine退出。没有停止或终止功能,这是有充分的理由的。如果我们无法命令goroutine停止,则必须礼貌地对其提出要求。这几乎总是归结于channel操作。当channel关闭时,针对一个channel的range loop将退出循环。如果一个channel关闭,它将变为可选(selectable)。从一个goroutine到另一个goroutine的信号最好表示为一个关闭的channel。

  • 出现这种情况需要什么? 如果channel既是在goroutines之间进行通讯的工具,又是它们传达完成信号的机制,那么程序员面临的下一个问题就是,谁将关闭channel,何时会发生?

  • 您将使用什么信号知道goroutine已停止? 当您发出信号告知goroutine要停止时,在将来的某个时间gouroutine停止动作会发生。就人类的感知而言,它可能很快发生,但是计算机每秒执行数十亿条指令,并且从每个goroutine的角度来看,它们的指令执行是不同步的。解决方案通常是使用channel发应答信号或fan-in方法需要的waitgroup。

将并发留给调用者

在您编写的任何严肃的Go程序中,都可能涉及并发。这就提出了一个问题,我们编写的许多库和代码都采用每个连接一个goroutine或采用工作者(worker)模式。您将如何管理这些goroutine的生命周期?

net/http是一个很好的例子。关闭拥有监听套接字的server相对来说是直截了当的,但是从该接受套接字产生的goroutines呢?net/http确实在请求对象中提供了一个上下文(context)对象,该上下文对象可用于向正在监听的代码发出信号,表明应该取消请求(cancel),从而终止goroutine,但是尚不清楚如何知道何时完成所有这些操作。一种方法是调用context.Cancel,知道取消已经完成是另一回事。2

我想说明的一点net/http是,它是良好实践的反例。由于每个连接都是由net/http.Server类型内部产生的goroutine处理的,因此驻留在程序net/http包外部的程序无法控制接受套接字产生的goroutine。

这是一个仍在不断发展的设计领域,例如go-kitrun.Group和Go团队等努力ErrGroup提供了执行,取消和等待异步运行功能的框架。

这里更大的设计准则是针对库编写者的,或者是任何编写可以异步运行的代码的人,将使用goroutine的责任留给调用者。让调用者选择他们希望如何启动,跟踪和等待函数执行。

编写测试以锁定包API的行为

也许您希望从我这里读到一篇我不咆哮测试的文章。可悲的是,今天不是那天。

测试是关于您的软件做什么和不做什么的契约。程序包级别的单元测试应锁定程序包API的行为。他们用代码描述了程序包承诺要做的事情。如果针对每个输入排列组合都有一个单元测试,那么您已经定义了代码将在代码(而不是文档)中执行的约定 。

通过简单的输入go test,您就可以断言代码是否遵守契约。在任何阶段,您都可以高度自信地知道人们在更改之前所依赖的行为在更改之后将继续有效。

测试会锁定api行为。添加,修改或删除公共api的任何更改都必须包括对其测试的更改。

适度是一种美德

Go是一种简单的语言,只有25个关键字。在某些方面,这使该语言内置的功能脱颖而出。同样,这些是语言销售的功能,轻量级并发,结构化类型。

我想我们所有人都经历过尝试立即使用Go的所有功能所带来的困惑。谁对使用channel如此兴奋以至于他们尽可能多地,尽可能多地使用它们?就我个人而言,我发现结果很难测试,脆弱且最终过于复杂。只有我一个人吗?

我在goroutines上经历了相同的经历,试图将工作分解成很小的单元,我创建了一群难以管理的goroutines,最终观察到我的大多数goroutines总是阻塞等待–代码最终是顺序的,我增加了很多复杂性,几乎没有给现实世界带来任何好处。谁经历过这样的事情?

我在嵌入机制方面(embedding)也有同样的经历。最初,我将其误认为是继承。然后,我通过将已经承担多个职责的复杂类型组合成更复杂的巨大类型重现了创建脆弱的基类问题。

这可能是最不可行的建议,但我认为这一点很重要。建议始终是相同的,所有事情都要适度,Go的特性也不例外。如果可以的话,请不要寻求goroutine或channel,也不要嵌入结构,匿名函数,过渡用package,为每样东西建立接口(interface),要用简单方法而不是聪明的方法。

可维护性很重要

我想谈谈关于PEP-20的最后一项,

“可读性很重要。” - Python之禅,条款7
“Readability Counts.” - The Zen of Python, Item 7

关于可读性的重要性已经被谈论了很多,不仅在Go语言中,而且在所有编程语言中。像我这样的人,倡导在Go的舞台上使用简单,可读性,清晰度,生产力等词,但最终它们都是一个词的同义词- 可维护性

真正的目标是编写可维护的代码。原始作者之后的代码可以存活下了。存在的代码不仅可以作为时间点投资,而且可以作为未来价值的基础。不是可读性并不重要,而是可维护性更重要。

Go并不是为聪明人而优化的语言。Go不是一种为了在程序中编写最少行数而进行优化的语言。我们没有针对磁盘上源代码的大小进行优化,也没有针对将程序键入编辑器花费的时间进行优化。而是,我们希望优化我们的代码以使读者清晰(clear)。因为需要维护此代码的人正是读者。

如果您是为自己编写程序,则也许只需要运行一次,或者您是唯一会看到该程序的人,然后程序为您工作。但是,如果这是一个将由多个人贡献的软件,或者将由人们使用足够长的时间以致其需求,功能或运行环境可能发生变化,那么您的目标必须是针对程序的可维护性。如果无法维护软件,则它将被重写;那可能是您的公司最后一次投资Go。

你离开后,您努力实现东西可以维护吗?您今天该如何做才能使某人明天更容易维护您的代码?



我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。


  1. 演讲的这一部分具有Ruby,Swift,Elm,Go,NodeJS,Python,Rust的网站登录页面的几个屏幕截图,展示了该语言如何描述自己。 

  2. 我倾向于选择net/http很多东西,但这并不是因为它很糟糕,实际上是相反的,它是Go代码库中最成功,最古老,最常用的API。因此,它的设计,发展和缺点已被彻底地接受。你可以认为这是奉承,而不是批评。 

© 2020, bigwhite. 版权所有.

Go 1.14中值得关注的几个变化

$
0
0

可能是得益于2020年2月26日Go 1.14的发布,在2020年3月份的TIOBE编程语言排行榜上,Go重新进入TOP 10,而去年同期Go仅排行在第18位。虽然Go语言以及其他主流语言在榜单上的“上蹿下跳”让这个榜单的权威性饱受质疑:),但Go在这样的一个时间节点能进入TOP 10,对于Gopher和Go社区来说,总还是一个不错的结果。并且在一定层度上说明:Go在努力耕耘十年后,已经在世界主流编程语言之林中牢牢占据了自己的一个位置。

img{512x368}

图:TIOBE编程语言排行榜2020.3月榜单,Go语言重入TOP10

Go自从宣布Go1 Compatible后,直到这次的Go 1.14发布,Go的语法和核心库都没有做出不兼容的变化。这让很多其他主流语言的拥趸们觉得Go很“无趣”。但这种承诺恰恰是Go团队背后努力付出的结果,因此Go的每个发布版本都值得广大gopher尊重,每个发布版本都是Go团队能拿出的最好版本

下面我们就来解读一下Go 1.14的变化,看看这个新版本中有哪些值得我们重点关注的变化。

一. 语言规范

和其他主流语言相比,Go语言的语法规范的变化那是极其少的(广大Gopher们已经习惯了这个节奏:)),偶尔发布一个变化,那自然是要引起广大Gopher严重关注的:)。不过事先说明:只要Go版本依然是1.x,那么这个规范变化也是backward-compitable的

Go 1.14新增的语法变化是:嵌入接口的方法集可重叠。这个变化背后的朴素思想是这样的。看下面代码(来自这里):

type I interface { f(); String() string }
type J interface { g(); String() string }

type IJ interface { I; J }  ----- (1)
type IJ interface { f(); g(); String() string }  ---- (2)

代码中已知定义的I和J两个接口的方法集中都包含有String() string这个方法。在这样的情况下,我们如果想定义一个方法集合为Union(I, J)的新接口IJ,我们在Go 1.13及之前的版本中只能使用第(2)种方式,即只能在新接口IJ中重新书写一遍所有的方法原型,而无法像第(1)种方式那样使用嵌入接口的简洁方式进行。

Go 1.14通过支持嵌入接口的方法集可重叠解决了这个问题:

// go1.14-examples/overlapping_interface.go
package foo

type I interface {
    f()
    String() string
}
type J interface {
    g()
    String() string
}

type IJ interface {
    I
    J
}

在go 1.13.6上运行:

$go build overlapping_interface.go
# command-line-arguments
./overlapping_interface.go:14:2: duplicate method String

但在go 1.14上运行:

$go build overlapping_interface.go

// 一切ok,无报错

不过对overlapping interface的支持仅限于接口定义中,如果你要在struct定义中嵌入interface,比如像下面这样:

// go1.14-examples/overlapping_interface1.go
package main

type I interface {
    f()
    String() string
}

type implOfI struct{}

func (implOfI) f() {}
func (implOfI) String() string {
    return "implOfI"
}

type J interface {
    g()
    String() string
}

type implOfJ struct{}

func (implOfJ) g() {}
func (implOfJ) String() string {
    return "implOfJ"
}

type Foo struct {
    I
    J
}

func main() {
    f := Foo{
        I: implOfI{},
        J: implOfJ{},
    }
    println(f.String())
}

虽然Go编译器没有直接指出结构体Foo中嵌入的两个接口I和J存在方法的重叠,但在使用Foo结构体时,下面的编译器错误肯定还是会给出的:

$ go run overlapping_interface1.go
# command-line-arguments
./overlapping_interface1.go:37:11: ambiguous selector f.String

对于结构体中嵌入的接口的方法集是否存在overlap,go编译器似乎并没有严格做“实时”检查,这个检查被延迟到为结构体实例选择method的执行者环节了,就像上面例子那样。如果我们此时让Foo结构体 override一个String方法,那么即便I和J的方法集存在overlap也是无关紧要的,因为编译器不会再模棱两可,可以正确的为Foo实例选出究竟执行哪个String方法:

// go1.14-examples/overlapping_interface2.go

.... ....

func (Foo) String() string {
        return "Foo"
}

func main() {
        f := Foo{
                I: implOfI{},
                J: implOfJ{},
        }
        println(f.String())
}

运行该代码:

$go run overlapping_interface2.go
Foo

二. Go运行时

1. 支持异步抢占式调度

《Goroutine调度实例简要分析》一文中,我曾提到过这样一个例子:

// go1.14-examples/preemption_scheduler.go
package main

import (
    "fmt"
    "runtime"
    "time"
)

func deadloop() {
    for {
    }
}

func main() {
    runtime.GOMAXPROCS(1)
    go deadloop()
    for {
        time.Sleep(time.Second * 1)
        fmt.Println("I got scheduled!")
    }
}

在只有一个P的情况下,上面的代码中deadloop所在goroutine将持续占据该P,使得main goroutine中的代码得不到调度(GOMAXPROCS=1的情况下),因此我们无法看到I got scheduled!字样输出。这是因为Go 1.13及以前的版本的抢占是”协作式“的,只在有函数调用的地方才能插入“抢占”代码(埋点),而deadloop没有给编译器插入抢占代码的机会。这会导致GC在等待所有goroutine停止时等待时间过长,从而导致GC延迟;甚至在一些特殊情况下,导致在STW(stop the world)时死锁。

Go 1.14采用了基于系统信号的异步抢占调度,这样上面的deadloop所在的goroutine也可以被抢占了:

// 使用Go 1.14版本编译器运行上述代码

$go run preemption_scheduler.go
I got scheduled!
I got scheduled!
I got scheduled!

不过由于系统信号可能在代码执行到任意地方发生,在Go runtime能cover到的地方,Go runtime自然会处理好这些系统信号。但是如果你是通过syscall包或golang.org/x/sys/unix在Unix/Linux/Mac上直接进行系统调用,那么一旦在系统调用执行过程中进程收到系统中断信号,这些系统调用就会失败,并以EINTR错误返回,尤其是低速系统调用,包括:读写特定类型文件(管道、终端设备、网络设备)、进程间通信等。在这样的情况下,我们就需要自己处理EINTR错误。一个最常见的错误处理方式就是重试。对于可重入的系统调用来说,在收到EINTR信号后的重试是安全的。如果你没有自己调用syscall包,那么异步抢占调度对你已有的代码几乎无影响。

Go 1.14的异步抢占调度在windows/arm, darwin/arm, js/wasm, and plan9/*上依然尚未支持,Go团队计划在Go 1.15中解决掉这些问题

2. defer性能得以继续优化

Go 1.13中,defer性能得到理论上30%的提升。我们还用那个例子来看看go 1.14与go 1.13版本相比defer性能又有多少提升,同时再看看使用defer和不使用defer的对比:

// go1.14-examples/defer_benchmark_test.go
package defer_test

import "testing"

func sum(max int) int {
    total := 0
    for i := 0; i < max; i++ {
        total += i
    }

    return total
}

func foo() {
    defer func() {
        sum(10)
    }()

    sum(100)
}

func Bar() {
    sum(100)
    sum(10)
}

func BenchmarkDefer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        foo()
    }
}
func BenchmarkWithoutDefer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Bar()
    }
}

我们分别用Go 1.13和Go 1.14运行上面的基准测试代码:

Go 1.13:

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8              17873574            66.7 ns/op
BenchmarkWithoutDefer-8       26935401            43.7 ns/op
PASS
ok      command-line-arguments    2.491s

Go 1.14:

$go test -bench . defer_benchmark_test.go
goos: darwin
goarch: amd64
BenchmarkDefer-8              26179819            45.1 ns/op
BenchmarkWithoutDefer-8       26116602            43.5 ns/op
PASS
ok      command-line-arguments    2.418s

我们看到,Go 1.14的defer性能照比Go 1.13还有大幅提升,并且已经与不使用defer的性能相差无几了,这也是Go官方鼓励大家在性能敏感的代码执行路径上也大胆使用defer的原因。

img{512x368}

图:各个Go版本defer性能对比(图来自于https://twitter.com/janiszt/status/1215601972281253888)

3. internal timer的重新实现

鉴于go timer长期以来性能不能令人满意,Go 1.14几乎重新实现了runtime层的timer。其实现思路遵循了Dmitry Vyukov几年前提出的实现逻辑:将timer分配到每个P上,降低锁竞争;去掉timer thread,减少上下文切换开销;使用netpoll的timeout实现timer机制。

// $GOROOT/src/runtime/time.go

type timer struct {
        // If this timer is on a heap, which P's heap it is on.
        // puintptr rather than *p to match uintptr in the versions
        // of this struct defined in other packages.
        pp puintptr

}

// addtimer adds a timer to the current P.
// This should only be called with a newly created timer.
// That avoids the risk of changing the when field of a timer in some P's heap,
// which could cause the heap to become unsorted.

func addtimer(t *timer) {
        // when must never be negative; otherwise runtimer will overflow
        // during its delta calculation and never expire other runtime timers.
        if t.when < 0 {
                t.when = maxWhen
        }
        if t.status != timerNoStatus {
                badTimer()
        }
        t.status = timerWaiting

        addInitializedTimer(t)
}

// addInitializedTimer adds an initialized timer to the current P.
func addInitializedTimer(t *timer) {
        when := t.when

        pp := getg().m.p.ptr()
        lock(&pp.timersLock)
        ok := cleantimers(pp) && doaddtimer(pp, t)
        unlock(&pp.timersLock)
        if !ok {
                badTimer()
        }

        wakeNetPoller(when)
}
... ...

这样你的程序中如果大量使用time.After、time.Tick或者在处理网络连接时大量使用SetDeadline,使用Go 1.14编译后,你的应用将得到timer性能的自然提升

img{512x368}

图:切换到新timer实现后的各Benchmark数据

三. Go module已经production ready了

Go 1.14中带来的关于go module的最大惊喜就是Go module已经production ready了,这意味着关于go module的运作机制,go tool的各种命令和其参数形式、行为特征已趋稳定了。笔者从Go 1.11引入go module以来就一直关注和使用Go module,尤其是Go 1.13中增加go module proxy的支持,使得中国大陆的gopher再也不用为获取类似golang.org/x/xxx路径下的module而苦恼了。

Go 1.14中go module的主要变动如下:

a) module-aware模式下对vendor的处理:如果go.mod中go version是go 1.14及以上,且当前repo顶层目录下有vendor目录,那么go工具链将默认使用vendor(即-mod=vendor)中的package,而不是module cache中的($GOPATH/pkg/mod下)。同时在这种模式下,go 工具会校验vendor/modules.txt与go.mod文件,它们需要保持同步,否则报错。

在上述前提下,如要非要使用module cache构建,则需要为go工具链显式传入-mod=mod ,比如:go build -mod=mod ./...

b) 增加GOINSECURE,可以不再要求非得以https获取module,或者即便使用https,也不再对server证书进行校验。

c) 在module-aware模式下,如果没有建立go.mod或go工具链无法找到go.mod,那么你必须显式传入要处理的go源文件列表,否则go tools将需要你明确go.mod。比如:在一个没有go.mod的目录下,要编译一个hello.go,我们需要使用go build hello.go(hello.go需要显式放在命令后面),如果你执行go build .就会得到类似如下错误信息:

$go build .
go: cannot find main module, but found .git/config in /Users/tonybai
    to create a module there, run:
    cd .. && go mod init

也就是说在没有go.mod的情况下,go工具链的功能是受限的。

d) go module支持subversion仓库了,不过subversion使用应该很“小众”了。

要系统全面的了解go module的当前行为机制,建议还是通读一遍Go command手册中关于module的说明以及官方go module wiki

四. 编译器

Go 1.14 go编译器在-race和-msan的情况下,默认会执行-d=checkptr,即对unsafe.Pointer的使用进行合法性检查,主要检查两项内容:

  • 当将unsafe.Pointer转型为*T时,T的内存对齐系数不能高于原地址的

比如下面代码:

// go1.14-examples/compiler_checkptr1.go
package main

import (
    "fmt"
    "unsafe"
)

func main() {
    var byteArray = [10]byte{'a', 'b', 'c'}
    var p *int64 = (*int64)(unsafe.Pointer(&byteArray[1]))
    fmt.Println(*p)
}

以-race运行上述代码:

$go run -race compiler_checkptr1.go
fatal error: checkptr: unsafe pointer conversion

goroutine 1 [running]:
runtime.throw(0x11646fd, 0x23)
    /Users/tonybai/.bin/go1.14/src/runtime/panic.go:1112 +0x72 fp=0xc00004cee8 sp=0xc00004ceb8 pc=0x106d152
runtime.checkptrAlignment(0xc00004cf5f, 0x1136880, 0x1)
    /Users/tonybai/.bin/go1.14/src/runtime/checkptr.go:13 +0xd0 fp=0xc00004cf18 sp=0xc00004cee8 pc=0x1043b70
main.main()
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.14-examples/compiler_checkptr1.go:10 +0x70 fp=0xc00004cf88 sp=0xc00004cf18 pc=0x11283b0
runtime.main()
    /Users/tonybai/.bin/go1.14/src/runtime/proc.go:203 +0x212 fp=0xc00004cfe0 sp=0xc00004cf88 pc=0x106f7a2
runtime.goexit()
    /Users/tonybai/.bin/go1.14/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00004cfe8 sp=0xc00004cfe0 pc=0x109b801
exit status 2

checkptr检测到:转换后的int64类型的内存对齐系数严格程度要高于转化前的原地址(一个byte变量的地址)。int64对齐系数为8,而一个byte变量地址对齐系数仅为1。

  • 做完指针算术后,转换后的unsafe.Pointer仍应指向原先Go堆对象
compiler_checkptr2.go
package main

import (
    "unsafe"
)

func main() {
    var n = 5
    b := make([]byte, n)
    end := unsafe.Pointer(uintptr(unsafe.Pointer(&b[0])) + uintptr(n+10))
    _ = end
}

运行上述代码:

$go run  -race compiler_checkptr2.go
fatal error: checkptr: unsafe pointer arithmetic

goroutine 1 [running]:
runtime.throw(0x10b618b, 0x23)
    /Users/tonybai/.bin/go1.14/src/runtime/panic.go:1112 +0x72 fp=0xc00003e720 sp=0xc00003e6f0 pc=0x1067192
runtime.checkptrArithmetic(0xc0000180b7, 0xc00003e770, 0x1, 0x1)
    /Users/tonybai/.bin/go1.14/src/runtime/checkptr.go:41 +0xb5 fp=0xc00003e750 sp=0xc00003e720 pc=0x1043055
main.main()
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.14-examples/compiler_checkptr2.go:10 +0x8d fp=0xc00003e788 sp=0xc00003e750 pc=0x1096ced
runtime.main()
    /Users/tonybai/.bin/go1.14/src/runtime/proc.go:203 +0x212 fp=0xc00003e7e0 sp=0xc00003e788 pc=0x10697e2
runtime.goexit()
    /Users/tonybai/.bin/go1.14/src/runtime/asm_amd64.s:1373 +0x1 fp=0xc00003e7e8 sp=0xc00003e7e0 pc=0x1092581
exit status 2

checkptr检测到转换后的unsafe.Pointer已经超出原先heap object: b的范围了,于是报错。

不过目前Go标准库依然尚未能完全通过checkptr的检查,因为有些库代码显然违反了unsafe.Pointer的使用规则

Go 1.13引入了新的Escape Analysis,Go 1.14中我们可以通过-m=2查看详细的逃逸分析过程日志,比如:

$go run  -gcflags '-m=2' compiler_checkptr2.go
# command-line-arguments
./compiler_checkptr2.go:7:6: can inline main as: func() { var n int; n = 5; b := make([]byte, n); end := unsafe.Pointer(uintptr(unsafe.Pointer(&b[0])) + uintptr(n + 100)); _ = end }
./compiler_checkptr2.go:9:11: make([]byte, n) escapes to heap:
./compiler_checkptr2.go:9:11:   flow: {heap} = &{storage for make([]byte, n)}:
./compiler_checkptr2.go:9:11:     from make([]byte, n) (non-constant size) at ./compiler_checkptr2.go:9:11
./compiler_checkptr2.go:9:11: make([]byte, n) escapes to heap

五. 标准库

每个Go版本,变化最多的就是标准库,这里我们挑一个可能影响后续我们编写单元测试行为方式的变化说说,那就是testing包的T和B类型都增加了自己的Cleanup方法。我们通过代码来看一下Cleanup方法的作用:

// go1.14-examples/testing_cleanup_test.go
package main

import "testing"

func TestCase1(t *testing.T) {

    t.Run("A=1", func(t *testing.T) {
        t.Logf("subtest1 in testcase1")

    })
    t.Run("A=2", func(t *testing.T) {
        t.Logf("subtest2 in testcase1")
    })
    t.Cleanup(func() {
        t.Logf("cleanup1 in testcase1")
    })
    t.Cleanup(func() {
        t.Logf("cleanup2 in testcase1")
    })
}

func TestCase2(t *testing.T) {
    t.Cleanup(func() {
        t.Logf("cleanup1 in testcase2")
    })
    t.Cleanup(func() {
        t.Logf("cleanup2 in testcase2")
    })
}

运行上面测试:

$go test -v testing_cleanup_test.go
=== RUN   TestCase1
=== RUN   TestCase1/A=1
    TestCase1/A=1: testing_cleanup_test.go:8: subtest1 in testcase1
=== RUN   TestCase1/A=2
    TestCase1/A=2: testing_cleanup_test.go:12: subtest2 in testcase1
    TestCase1: testing_cleanup_test.go:18: cleanup2 in testcase1
    TestCase1: testing_cleanup_test.go:15: cleanup1 in testcase1
--- PASS: TestCase1 (0.00s)
    --- PASS: TestCase1/A=1 (0.00s)
    --- PASS: TestCase1/A=2 (0.00s)
=== RUN   TestCase2
    TestCase2: testing_cleanup_test.go:27: cleanup2 in testcase2
    TestCase2: testing_cleanup_test.go:24: cleanup1 in testcase2
--- PASS: TestCase2 (0.00s)
PASS
ok      command-line-arguments    0.005s

我们看到:

  • Cleanup方法运行于所有测试以及其子测试完成之后。

  • Cleanup方法类似于defer,先注册的cleanup函数后执行(比如上面例子中各个case的cleanup1和cleanup2)。

在拥有Cleanup方法前,我们经常像下面这样做:

// go1.14-examples/old_testing_cleanup_test.go
package main

import "testing"

func setup(t *testing.T) func() {
    t.Logf("setup before test")
    return func() {
        t.Logf("teardown/cleanup after test")
    }
}

func TestCase1(t *testing.T) {
    f := setup(t)
    defer f()
    t.Logf("test the testcase")
}

运行上面测试:

$go test -v old_testing_cleanup_test.go
=== RUN   TestCase1
    TestCase1: old_testing_cleanup_test.go:6: setup before test
    TestCase1: old_testing_cleanup_test.go:15: test the testcase
    TestCase1: old_testing_cleanup_test.go:8: teardown/cleanup after test
--- PASS: TestCase1 (0.00s)
PASS
ok      command-line-arguments    0.005s

有了Cleanup方法后,我们就不需要再像上面那样单独编写一个返回cleanup函数的setup函数了。

此次Go 1.14还将对unicode标准的支持从unicode 11 升级到 unicode 12 ,共增加了554个新字符。

六. 其他

超强的可移植性是Go的一个知名标签,在新平台支持方面,Go向来是“急先锋”。Go 1.14为64bit RISC-V提供了在linux上的实验性支持(GOOS=linux, GOARCH=riscv64)。

rust语言已经通过cargo-fuzz从工具层面为fuzz test提供了基础支持。Go 1.14也在这方面做出了努力,并且Go已经在向将fuzz test变成Go test的一等公民而努力。

七. 小结

Go 1.14的详细变更说明在这里可以查看。整个版本的milestone对应的issue集合在这里

不过目前Go 1.14在特定版本linux内核上会出现crash的问题,当然这个问题源于这些内核的一个已知bug。在这个issue中有关于这个问题的详细说明,涉及到的Linux内核版本包括:5.2.x, 5.3.0-5.3.14, 5.4.0-5.4.1。
本篇博客涉及的代码在这里可以下载。


我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/
smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

微博:https://weibo.com/bigwhite20xx
微信公众号:iamtonybai
博客:tonybai.com
github: https://github.com/bigwhite

微信赞赏:
img{512x368}

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

© 2020, bigwhite. 版权所有.

Viewing all 560 articles
Browse latest View live