标签 Unittest 下的文章

Go 1.13中值得关注的几个变化

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}

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

写Go代码时遇到的那些问题[第2期]

第1期的“写Go代码时遇到的那些问题”一经发布后得到了很多Gopher的支持和赞赏,这也是我继续写下去的动力!不过这里依然要强调的是这一系列文章反映的是笔者在实践中对代码编写的认知以及代码的演化过程。这里的代码也许只是“中间阶段”,并不是什么最优的结果,我记录的只是对问题、对代码的一个思考历程。不过,十分欢迎交流与批评指正。

一、dep的日常操作

虽然dep在国内使用依然有init失败率较高(因为一些qiang外的第三方package)的坎儿,但我和主流Gopher社区和项目一样,义无反顾地选择在代码库中使用dep。本周dep刚刚发布了0.4.1版本,与之前版本最大的不同在于dep发布了其官网以及相对完整的文档(以替代原先在github项目主页上的简陋的、格式较low的FAQ),这也是dep继续走向成熟的一个标志。不过关于dep何时能merge到go tools链当中,目前还是未知数。不过dep会在相当长的一段时期继续以独立工具的形式存在,直到merge到Go tools中并被广泛接受。

包依赖管理工具在日常开发中并不需要太多的存在感,我们需要的这类工具特征是功能强大但接口“小”,对开发者体验好,不太需要太关心其运行原理,dep基本符合。dep日常操作最主要的三个命令:dep init、dep ensure和dep status。在《初窥dep》一文中,我曾重点说过dep init原理,这里就不重点说了,我们用一个例子来说说使用dep的日常workflow。

1、dep init empty project

我们可以对一个empty project或一个初具框架雏形的project进行init,这里init一个empty project,作为后续的示例基础:

➜  $GOPATH/src/depdemo $dep init -v
Getting direct dependencies...
Checked 1 directories for packages.
Found 0 direct dependencies.
Root project is "depdemo"
 0 transitively valid internal packages
 0 external packages imported from 0 projects
(0)   ✓ select (root)
  ✓ found solution with 0 packages from 0 projects

Solver wall times by segment:
  select-root: 68.406µs
        other:  9.806µs

  TOTAL: 78.212µs

➜  $GOPATH/src/depdemo $ls
Gopkg.lock    Gopkg.toml    vendor/

➜  $GOPATH/src/depdemo $dep status
PROJECT  CONSTRAINT  VERSION  REVISION  LATEST  PKGS USED

dep init有三个输出:Gopkg.lock、Gopkg.toml和vendor目录,其中Gopkg.toml(包含example,但注释掉了)和vendor都是空的,Gopkg.lock中仅包含了一些给gps使用的metadata:

➜  $GOPATH/src/depdemo git:(a337d5b) $cat Gopkg.lock
# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "ab4fef131ee828e96ba67d31a7d690bd5f2f42040c6766b1b12fe856f87e0ff7"
  solver-name = "gps-cdcl"
  solver-version = 1

2、常规操作循环:for { 填代码 -> dep ensure }

接下来的常规操作就是我们要为project添加代码了。我们先来为工程添加一个main.go文件,源码如下:

// main.go
package main

import "fmt"

func main() {
    fmt.Println("depdemo")
}

这份代码的依赖只是std库的fmt,并没有使用第三方的依赖,因此当我们通过dep status查看当前状态、使用ensure去做同步时,发现dep并没有什么要做的:

➜  $GOPATH/src/depdemo $dep status
PROJECT  CONSTRAINT  VERSION  REVISION  LATEST  PKGS USED
➜  $GOPATH/src/depdemo $dep ensure -v
Gopkg.lock was already in sync with imports and Gopkg.toml

好吧。我们再来为main.go添点“有用”的内容:一段读取toml配置文件的代码。

//data.toml
id = "12345678abcdefgh"
name = "tonybai"
city = "shenyang"

// main.go
package main

import (
    "fmt"
    "log"

    "github.com/BurntSushi/toml"
)

type Person struct {
    ID   string
    Name string
    City string
}

func main() {
    p := Person{}
    if _, err := toml.DecodeFile("./data.toml", &p); err != nil {
        log.Fatal(err)
    }

    fmt.Println(p)
}

之后,再来执行dep status:

➜  $GOPATH/src/depdemo $dep status
Lock inputs-digest mismatch due to the following packages missing from the lock:

PROJECT                     MISSING PACKAGES
github.com/BurntSushi/toml  [github.com/BurntSushi/toml]

This happens when a new import is added. Run `dep ensure` to install the missing packages.
input-digest mismatch

我们看到dep status检测到项目出现”不同步”的情况(代码中引用的toml包在Gopkg.lock中没有),并建议使用dep ensure命令去做一次sync。

img{512x368}

我们来ensure一下(ensure的输入输出见上图):

$GOPATH/src/depdemo git:(master) $dep ensure -v
Root project is "depdemo"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)

(1)    ? attempt github.com/BurntSushi/toml with 1 pkgs; 7 versions to try
(1)        try github.com/BurntSushi/toml@v0.3.0
(1)    ✓ select github.com/BurntSushi/toml@v0.3.0 w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
     b-source-exists: 15.821158205s
... ...
  b-deduce-proj-root:       5.453µs

  TOTAL: 16.176846089s

(1/1) Wrote github.com/BurntSushi/toml@v0.3.0

我们来看看项目中的文件都发生了哪些变化:

$git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Gopkg.lock

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    vendor/

可以看到Gopkg.lock文件和vendor目录下发生了变化:

$git diff

diff --git a/Gopkg.lock b/Gopkg.lock
index bef2d00..c5ae854 100644
--- a/Gopkg.lock
+++ b/Gopkg.lock
@@ -1,9 +1,15 @@
 # This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.

+[[projects]]
+  name = "github.com/BurntSushi/toml"
+  packages = ["."]
+  revision = "b26d9c308763d68093482582cea63d69be07a0f0"
+  version = "v0.3.0"
+
 [solve-meta]
   analyzer-name = "dep"
   analyzer-version = 1
-  inputs-digest = "ab4fef131ee828e96ba67d31a7d690bd5f2f42040c6766b1b12fe856f87e0ff7"
+  inputs-digest = "25c744eb70aefb94032db749509fd34b2fb6e7c6041e8b8c405f7e97d10bdb8d"
   solver-name = "gps-cdcl"
   solver-version = 1

$tree -L 2 vendor
vendor
└── github.com
    └── BurntSushi

可以看到Gopkg.lock中增加了toml包的依赖条目(版本v0.3.0),input-digest这个元数据字段的值也发生了变更;并且vendor目录下多了toml包的源码,至此项目又到达了“同步”状态。

3、添加约束

大多数情况下,我们到这里就算完成了dep work flow的一次cycle,但如果你需要为第三方包的版本加上一些约束条件,那么dep ensure -add就会派上用场,比如说:我们要使用toml包的v0.2.x版本,而不是v0.3.0版本,我们需要为github.com/BurntSushi/toml添加一条约束:

$dep ensure -v -add github.com/BurntSushi/toml@v0.2.0
Fetching sources...
(1/1) github.com/BurntSushi/toml@v0.2.0

Root project is "depdemo"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)    ? attempt github.com/BurntSushi/toml with 1 pkgs; at least 1 versions to try
(1)        try github.com/BurntSushi/toml@v0.3.0
(2)    ✗   github.com/BurntSushi/toml@v0.3.0 not allowed by constraint ^0.2.0:
(2)        ^0.2.0 from (root)
(1)        try github.com/BurntSushi/toml@v0.2.0
(1)    ✓ select github.com/BurntSushi/toml@v0.2.0 w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
... ...

  TOTAL: 599.252392ms

(1/1) Wrote github.com/BurntSushi/toml@v0.2.0

add约束后,Gopkg.toml中增加了一条记录:

// Gopkg.toml
[[constraint]]
  name = "github.com/BurntSushi/toml"
  version = "0.2.0"

Gopkg.lock中的toml条目的版本回退为v0.2.0:

diff --git a/Gopkg.lock b/Gopkg.lock
index c5ae854..a557251 100644
--- a/Gopkg.lock
+++ b/Gopkg.lock
@@ -4,12 +4,12 @@
 [[projects]]
   name = "github.com/BurntSushi/toml"
   packages = ["."]
-  revision = "b26d9c308763d68093482582cea63d69be07a0f0"
-  version = "v0.3.0"
+  revision = "bbd5bb678321a0d6e58f1099321dfa73391c1b6f"
+  version = "v0.2.0"

 [solve-meta]
   analyzer-name = "dep"
   analyzer-version = 1
-  inputs-digest = "25c744eb70aefb94032db749509fd34b2fb6e7c6041e8b8c405f7e97d10bdb8d"
+  inputs-digest = "9fd144de0cc448be93418c927b5ce2a70e03ec7f260fa7e0867f970ff121c7d7"
   solver-name = "gps-cdcl"
   solver-version = 1

$dep status
PROJECT                     CONSTRAINT  VERSION  REVISION  LATEST  PKGS USED
github.com/BurntSushi/toml  ^0.2.0      v0.2.0   bbd5bb6   v0.2.0  1

vendor目录下的toml包源码也回退到v0.2.0的源码。关于约束规则的构成语法,可以参考dep文档

4、revendor/update vendor

使用vendor机制后,由于第三方依赖包修正bug或引入你需要的功能,revendor第三方依赖包版本或者叫update vendor会成为一个周期性的工作。比如:toml包做了一些bugfix,并发布了v0.2.1版本。在我的depdemo中,为了一并fix掉这些bug,我需要重新vendor toml包。之前我们加的constraint是满足升级到v0.2.1版本的,因此我们不需要重新设置constraints,我们只需要单独revendor toml即可,可以使用dep ensure -update 命令:

$dep ensure -v -update github.com/BurntSushi/toml
Root project is "depdemo"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)    ? attempt github.com/BurntSushi/toml with 1 pkgs; 7 versions to try
(1)        try github.com/BurntSushi/toml@v0.3.0
(2)    ✗   github.com/BurntSushi/toml@v0.3.0 not allowed by constraint ^0.2.0:
(2)        ^0.2.0 from (root)
(1)        try github.com/BurntSushi/toml@v0.2.0
(1)    ✓ select github.com/BurntSushi/toml@v0.2.0 w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
  b-list-versions: 1m18.267880815s
  .... ...
  TOTAL: 1m57.118656393s

由于真实的toml并没有v0.2.1版本且没有v0.2.x版本,因此我们的dep ensure -update并没有真正获取到数据。vendor和Gopkg.lock都没有变化。

5、dep日常操作小结

下面这幅图包含了上述三个dep日常操作,可以直观地看出不同操作后,对项目带来的改变:

img{512x368}

“工欲善其事,必先利其器”,熟练的掌握dep的日常操作流程对提升开发效率大有裨益。

二、“超时等待退出”框架的一种实现

很多时候,我们在程序中都要启动多个goroutine协作完成应用的业务逻辑,比如:

func main() {
    go producer.Start()
    go consumer.Start()
    go watcher.Start()
    ... ...
}

启动容易停止难!当程序要退出时,最粗暴的方法就是不管三七二十一,main goroutine直接退出;优雅些的方式,也是*nix系统通常的作法是:通知一下各个Goroutine要退出了,然后等待一段时间后再真正退出。粗暴地直接退出的方式可能会导致业务数据的损坏、不完整或丢失。等待超时的方式虽然不能完全避免“损失”,但是它给了各个goroutine一个“挽救数据”的机会,可以尽可能地减少损失的程度。

但这些goroutine形态很可能不同,有些是server,有些可能是client worker或其manager,因此似乎很难用一种统一的框架全面管理他们的启动、运行和退出,于是我们缩窄“交互面”,我们只做“超时等待退出”。我们定义一个interface:

type GracefullyShutdowner interface {
    Shutdown(waitTimeout time.Duration) error
}

这样,凡是实现了该interface的类型均可在程序退出时得到退出的通知,并有机会做退出前的最后清理工作。这里还提供了一个类似http.HandlerFunc的类型ShutdownerFunc ,用于将普通function转化为实现了GracefullyShutdowner interface的类型实例:

type ShutdownerFunc func(time.Duration) error

func (f ShutdownerFunc) Shutdown(waitTimeout time.Duration) error {
    return f(waitTimeout)
}

1、并发退出

退出也至少有两种类型,一种是并发退出,这种退出方式下各个goroutine的退出先后次序对数据处理无影响;另外一种则是顺序退出,即各个goroutine之间的退出是必须按照一定次序进行的。我们先来说并发退出。上代码!

// shutdown.go
func ConcurrencyShutdown(waitTimeout time.Duration, shutdowners ...GracefullyShutdowner) error {
    c := make(chan struct{})

    go func() {
        var wg sync.WaitGroup
        for _, g := range shutdowners {
            wg.Add(1)
            go func(shutdowner GracefullyShutdowner) {
                shutdowner.Shutdown(waitTimeout)
                wg.Done()
            }(g)
        }
        wg.Wait()
        c <- struct{}{}
    }()

    select {
    case <-c:
        return nil
    case <-time.After(waitTimeout):
        return errors.New("wait timeout")
    }
}

我们将各个GracefullyShutdowner接口的实现以一个变长参数的形式传入ConcurrencyShutdown函数。ConcurrencyShutdown函数实现也很简单,通过:

  • 为每个shutdowner启动一个goroutine实现并发退出,并将timeout参数传入shutdowner的Shutdown方法中;
  • sync.WaitGroup在外层等待每个goroutine的退出;
  • 通过select一个退出指示channel和time.After返回的timer channel来决定到底是正常退出还是超时退出。

该函数的具体使用方法可以参考:shutdown_test.go。

//shutdown_test.go
func shutdownMaker(processTm int) func(time.Duration) error {
    return func(time.Duration) error {
        time.Sleep(time.Second * time.Duration(processTm))
        return nil
    }
}

func TestConcurrencyShutdown(t *testing.T) {
    f1 := shutdownMaker(2)
    f2 := shutdownMaker(6)

    err := ConcurrencyShutdown(time.Duration(10)*time.Second, ShutdownerFunc(f1), ShutdownerFunc(f2))
    if err != nil {
        t.Errorf("want nil, actual: %s", err)
        return
    }

    err = ConcurrencyShutdown(time.Duration(4)*time.Second, ShutdownerFunc(f1), ShutdownerFunc(f2))
    if err == nil {
        t.Error("want timeout, actual nil")
        return
    }
}

2、串行退出

有了并发退出作为基础,串行退出也很简单了!

//shutdown.go
func SequentialShutdown(waitTimeout time.Duration, shutdowners ...GracefullyShutdowner) error {
    start := time.Now()
    var left time.Duration

    for _, g := range shutdowners {
        elapsed := time.Since(start)
        left = waitTimeout - elapsed

        c := make(chan struct{})
        go func(shutdowner GracefullyShutdowner) {
            shutdowner.Shutdown(left)
            c <- struct{}{}
        }(g)

        select {
        case <-c:
            //continue
        case <-time.After(left):
            return errors.New("wait timeout")
        }
    }

    return nil
}

串行退出的一个问题是waitTimeout的确定,因为这个超时时间是所有goroutine的退出时间之和。在上述代码里,我把每次的lefttime传入下一个要执行的goroutine的Shutdown方法中,外部select也同样使用这个left作为timeout的值。对照ConcurrencyShutdown,SequentialShutdown更简单,这里就不详细说了。

3、小结

这是一个可用的、抛砖引玉式的实现,但还有很多改进空间,比如:可以考虑一下获取每个shutdowner.Shutdown后的返回值(error),留给大家自行考量吧。

三、Testcase的setUp和tearDown

Go语言自带testing框架,事实证明这是Go语言的一个巨大优势之一,Gopher们也非常喜欢这个testing包。但Testing这个事情比较复杂,有些场景还需要我们自己动脑筋在标准testing框架下实现需要的功能,比如:当测试代码需要访问外部数据库、Redis或连接远端server时。遇到这种情况,很多人想到了Mock,没错。Mock技术在一定程度上可以解决这些问题,但如果使用mock技术,业务代码就得为了test而去做一层抽象,提升了代码理解的难度,在有些时候这还真不如直接访问真实的外部环境。

这里先不讨论这两种方式的好坏优劣,这里仅讨论如果在testing中访问真实环境我们该如何测试。在经典单元测试框架中,我们经常能看到setUp和tearDown两个方法,它们分别用于在testcase执行之前初始化testcase的执行环境以及在testcase执行后清理执行环境,以保证每两个testcase之间都是独立的、互不干扰的。在真实环境下进行测试,我们也可以利用setUp和tearDown来为每个testcase初始化和清理case依赖的真实环境。

setUp和tearDown也是有级别的,有全局级、testsuite级以及testcase级。在Go中,在标准testing框架下,我们接触到的是全局级和testcase级别。Go中对全局级的setUp和tearDown的支持还要追溯到Go 1.4Go 1.4引入了TestMain方法,支持在诸多testcase执行之前为测试代码添加自定义setUp,以及在testing执行之后进行tearDown操作,例如:

func TestMain(m *testing.M) {
    err := setup()
    if err != nil {
        fmt.Println(err)
        os.Exit(-1)
    }

    r := m.Run()
    teardown()

    os.Exit(r)
}

但在testcase级别,Go testing包并没有提供方法上的支持。在2017年的GopherCon大会上,Hashicorp的创始人Mitchell Hashimoto做了题为:“Advanced Testing in Go”的主题演讲,这份资料里提出了一种较为优雅的为testcase进行setUp和teawDown的方法:

//setup-teardown-demo/foo_test.go
package foo_test

import (
    "fmt"
    "testing"
)

func setUp(t *testing.T, args ...interface{}) func() {
    fmt.Println("testcase setUp")
    // use t and args

    return func() {
        // use t
        // use args
        fmt.Println("testcase tearDown")
    }
}

func TestXXX(t *testing.T) {
    defer setUp(t)()
    fmt.Println("invoke testXXX")
}

这个方案充分利用了函数这个first-class type以及闭包的作用,每个Testcase可以定制自己的setUp和tearDown,也可以使用通用的setUp和tearDown,执行的效果如下:

$go test -v .
=== RUN   TestXXX
testcase setUp
invoke testXXX
testcase tearDown
--- PASS: TestXXX (0.00s)
PASS
ok      github.com/bigwhite/experiments/writing-go-code-issues/2nd-issue/setup-teardown-demo    0.010s

四、错误处理

本来想码一些关于Go错误处理的文字,但发现自己在2015年就写过一篇旧文《Go语言错误处理》,对Go错误处理的方方面面总结的很全面了。即便到今天也不过时,这当然也得益于Go1兼容规范的存在。因此有兴趣于此的朋友们,请移步到《Go语言错误处理》这篇文章吧。

注:本文所涉及的示例代码,请到这里下载。


微博:@tonybai_cn
微信公众号:iamtonybai
github.com: https://github.com/bigwhite

微信赞赏:
img{512x368}

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats