标签 gomodule 下的文章

小厂内部私有Go module拉取方案

本文永久链接 – https://tonybai.com/2021/09/03/the-approach-to-go-get-private-go-module-in-house

1. 问题来由

Go 1.11版本引入Go module后,Go命令拉取依赖的公共go module不再是“痛点”。如下图所示:


图:从公司内部经由公共GOPROXY服务拉取公共go module

我们在公司/组织内部仅需要为环境变量GOPROXY配置一个公共GOPROXY服务即可轻松拉取所有公共go module(公共module即开源module)。

但随着公司内Go使用者增多以及Go项目的增多,“代码重复”问题就出现了。抽取公共代码放入一个独立的、可被复用的内部私有仓库成为必然。这样我们便有了拉取私有go module的需求!

一些公司或组织的所有代码都放在公共vcs托管服务商那里(比如github.com),私有go module则直接放在对应的公共vcs服务的private repository(私有仓库)中。如果你的公司也是如此,那么拉取托管在公共vcs私有仓库中的私有go module也很容易,见下图:


图:从公司内部直接拉取托管在公共vcs服务上的私有go module

当然这个方案的一个前提是:每个开发人员都需要具有访问公共vcs服务上的私有go module仓库的权限,凭证的形式不限,可以是basic auth的user和password,也可以是personal access token(类似github那种),只要按照公共vcs的身份认证要求提供即可。

但是如果私有go module放在公司内部的vcs服务器上,就像下面图中所示:


图:私有go module放在组织/公司内部的vcs服务器上

那么我们该如何让Go命令自动拉取内部服务器上的私有go module呢?

一些gopher会说:“这很简单啊! 这和拉取托管在公共vcs服务上的私有go module没有什么分别啊”。持这种观点的gopher多半来自大厂。大厂内部有完备的IT基础设施供开发使用,大厂内部的vcs服务器都可以通过域名访问(比如git.bat.com/user/repo),因此大厂内部员工可以像访问公共vcs服务那样访问内部vcs服务器上的私有go module,就像下面图中所示:


图:大厂方案:直接拉取内部vcs仓库上的私有go module

我们看到:在上面这个方案中,公司搭建了一个内部goproxy服务(即上图中的in-house goproxy),这样的目的一来是为那些无法直接访问外网的开发机器以及ci机器提供拉取外部go module的途径,二来由于in-house goproxy的cache的存在,还可以加速公共go module的拉取效率。对于私有go module,开发机将其配置到GOPRIVATE环境变量中,这样Go命令在拉取私有go module时不会再走GOPROXY,而会采用直接访问vcs(如上图中的git.bat.com)的方式拉取私有go module。

当然大厂还可能采用下图所示方案将外部go module与私有go module都交给内部统一的Goproxy服务去处理:


图:大厂方案: 统一代理方案

在这种方案中,开发者仅需要将GOPROXY配置为in-house goproxy便可以统一拉取外部go module与私有go module。但由于go命令默认会对所有通过goproxy拉取的go module进行sum校验(到sum.golang.org),而我们的私有go module在公共sum验证server中没有数据记录,因此,开发者需要将私有go module填到GONOSUMDB环境变量中,这样go命令就不会对其进行sum校验了。不过这种方案有一处要注意:那就是in-house goproxy需要拥有对所有private module所在repo的访问权限,这样才能保证每个私有go module的拉取成功!

好了,问题来了!对于那些没有完备内部IT基础设施,还想将私有go module放在公司内部的vcs服务器上的小厂应该如何实现私有go module的拉取方案呢?

2. 可供小厂参考的一个解决方案

小厂虽小,但目标不能低。小厂虽然IT基础设施薄弱或不够灵活,但也不能因此给开发人员带去太多额外的“负担”。因此,对比了上面的两个大厂可能采用的方案,我们更倾向于后者。这样,我们就可以将所有复杂性都交给in-house goproxy这个节点,开发人员就可以做的足够简单。但小厂没有DNS,无法用域名…,我们该怎么实现这个方案呢?在这一节中,我们就实现这个方案。

0. 方案示例环境拓扑

我们先为后续的方案实现准备一个示例环境,其拓扑如下图:

1. 选择一个goproxy实现

Go module proxy协议规范发布后,Go社区出现了很多成熟的Goproxy开源实现。从最初的athens,再到国内的两个优秀的开源实现:goproxy.cngoproxy.io。其中,goproxy.io在官方站点给出了企业内部部署的方法,基于这一点,我们就基于goproxy.io来实现我们的方案(其余的goproxy实现应该也都可以实现)。

我们在上图中的in-house goproxy节点上执行下面步骤安装goproxy:

$mkdir ~/.bin/goproxy
$cd ~/.bin/goproxy
$git clone https://github.com/goproxyio/goproxy.git
$cd goproxy
$make

编译后,会在当前的bin目录(~/.bin/goproxy/goproxy/bin)下看到名为goproxy的可执行文件。

建立goproxy cache目录:

$mkdir /root/.bin/goproxy/goproxy/bin/cache

启动goproxy:

$./goproxy -listen=0.0.0.0:8081 -cacheDir=/root/.bin/goproxy/goproxy/bin/cache -proxy https://goproxy.io
goproxy.io: ProxyHost https://goproxy.io

启动后goproxy在8081端口监听(即便不指定,goproxy的默认端口也是8081),指定的上游goproxy服务为goproxy.io。

注意:goproxy的这个启动参数并不是最终版本的,这里仅仅想验证一下goproxy是否能按预期工作。

接下来,我们来验证一下goproxy的工作是否如我们预期。

我们在开发机上配置GOPROXY环境变量指向10.10.20.20:8081:

// .bashrc
export GOPROXY=http://10.10.20.20:8081

生效环境变量后,执行下面命令:

$go get github.com/pkg/errors

结果如预期,开发机顺利下载了github.com/pkg/errors包。

在goproxy侧,我们看到了下面日志:

goproxy.io: ------ --- /github.com/pkg/@v/list [proxy]
goproxy.io: ------ --- /github.com/pkg/errors/@v/list [proxy]
goproxy.io: ------ --- /github.com/@v/list [proxy]
goproxy.io: 0.146s 404 /github.com/@v/list
goproxy.io: 0.156s 404 /github.com/pkg/@v/list
goproxy.io: 0.157s 200 /github.com/pkg/errors/@v/list

并且在goproxy的cache目录下,我们也看到了下载并缓存的github.com/pkg/errors包:

$cd /root/.bin/goproxy/goproxy/bin/cache
$tree
.
└── pkg
    └── mod
        └── cache
            └── download
                └── github.com
                    └── pkg
                        └── errors
                            └── @v
                                └── list

8 directories, 1 file

2. 自定义包导入路径并将其映射到内部的vcs仓库

小厂可能没有为vcs服务器分配域名,我们也不能在Go私有包的导入路径中放入ip地址,因此我们需要给我们的私有go module自定义一个路径,比如:mycompany.com/go/module1。我们统一将私有go module放在mycompany.com/go下面的代码仓库中。

接下来的问题是,当goproxy去拉取mycompany.com/go/module1时,应该得到mycompany.com/go/module1对应的内部vcs上module1 仓库的地址,这样goproxy才能从内部vcs代码服务器上下载到module1对应的代码。


图:goproxy如何得到mycompany.com/go/module1所对应的vcs仓库地址呢?

其实方案不止一种。这里我们使用一个名为govanityurls的工具,这个工具在我以前的文章中曾提到过。

结合govanityurls和nginx,我们就可以将私有go module的导入路径映射为其在vcs上的代码仓库的真实地址。下面的图解释了具体原理:

首先,goproxy要想将收到的拉取私有go module(mycompany.com/go/module1)的请求不转发给公共代理,需要在其启动参数上做一些手脚,如下面修改后的goproxy启动命令:

$./goproxy -listen=0.0.0.0:8081 -cacheDir=/root/.bin/goproxy/goproxy/bin/cache -proxy https://goproxy.io -exclude "mycompany.com/go"

这样凡是与-exclude后面的值匹配的go module拉取请求,goproxy都不会转给goproxy.io,而是直接请求go module的“源站”。而上面图中要做的就是将这个“源站”的地址转换为企业内部vcs服务中的一个仓库地址。由于mycompany.com这个域名并不存在,从图中我们看到:我们在goproxy所在节点的/etc/hosts中加了这样一条记录:

127.0.0.1 mycompany.com

这样goproxy发出的到mycompany.com的请求实则是发向了本机。而上图中所示,监听本机80端口的正是nginx,nginx关于mycompany.com这一主机的配置如下:

// /etc/nginx/conf.d/gomodule.conf

server {
        listen 80;
        server_name mycompany.com;

        location /go {
                proxy_pass http://127.0.0.1:8080;
                proxy_redirect off;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}

我们看到对于路径为mycompany.com/go/xxx的请求,nginx将请求转发给了127.0.0.1:8080,而这个服务地址恰是govanityurls工具监听的地址。

govanityurls这个工具是前Go核心开发团队成员Jaana B.Dogan开源的一个工具,这个工具可以帮助gopher快速实现自定义Go包的go get导入路径

govanityurls本身就好比一个“导航”服务器。当go命令向自定义包地址发起请求时,实则是将请求发送给了govanityurls服务,之后govanityurls将请求中的包所在仓库的真实地址(从vanity.yaml配置文件中读取)返回给go命令,后续go命令再从真实的仓库地址获取包数据。

注:govanityurls的安装方法很简单,直接go install/go get github.com/GoogleCloudPlatform/govanityurls即可。

在我们的示例中,vanity.yaml的配置如下:

host: mycompany.com

paths:
  /go/module1:
      repo: ssh://admin@10.10.30.30/module1
      vcs: git

也就是说当govanityurls收到nginx转发的请求后,会将请求与vanity.yaml中配置的module路径相匹配,如果匹配ok,则会将该module的真实repo地址通过go命令期望的应答格式予以返回。在这里我们看到,module1对应的真实vcs上的仓库地址为:ssh://admin@10.10.30.30/module1。

于是goproxy会收到这个地址,并再次向这个真实地址发起请求,并最终将module1缓存到本地cache并返回给客户端。

注意:由于这个方案与大厂的第二个方案是一样的,因此goproxy需要有访问mycompany.com/go下面所有go module对应的真实vcs仓库的权限。

3. 开发机(客户端)的设置

前面示例中,我们已经将开发机的GOPROXY环境变量设置为goproxy的服务地址。但我们说过凡是通过GOPROXY拉取的go module,go命令默认都会将其sum值到公共GOSUM服务器上去校验。但我们实质上拉取的是私有go module,GOSUM服务器上并没有我们的go module的sum数据。这样会导致go build命令报错,无法继续构建过程。

因此,开发机客户端还需将mycompany.com/go作为一个值设置到GONOSUMDB环境变量中,这就告诉go命令,凡是与mycompany.com/go匹配的go module,都无需做sum校验了。

4. 方案的“不足”

当然上述方案也不是完美的,它也有自己的不足的地方:

  • 开发者还是需要额外配置GONOSUMDB变量

由于Go命令默认会对从GOPROXY拉取的go module进行sum校验,因此我们需要将私有go module配置到GONOSUMDB环境变量中,这给开发者带来了一个小小的“负担”。

缓解措施:小厂可以将私有go项目都放在一个特定域名下,这样就无需为每个go私有项目单独增加GONOSUMDB配置了,只需要配置一次即可。

  • 新增私有go module,vanity.yaml需要手工同步更新

这个是这个方案最不灵活的地方了,由于目前govanityurls功能有限,我们针对每个私有go module可能都需要单独配置其对应的vcs仓库地址以及获取方式(git, svn or hg)。

缓解方案:在一个vcs仓库中管理多个私有go module,就像etcd那样。相比于最初go官方建议的一个repo只管理一个module,新版本的go在一个repo管理多个go module方面已经有了长足的进步。

不过对于小厂来说,这点额外工作与得到的收益相比,应该也不算什么!^_^

  • 无法划分权限

在上面的方案说明时也提到过,goproxy所在节点需要具备访问所有私有go module所在vcs repo的权限,但又无法对go开发者端做出有差别授权,这样只要是goproxy能拉取到的私有go module,go开发者都能拉取到。

不过对于多数小厂而言,内部所有源码原则上都是企业内部公开的,这个问题似乎也不大。如果觉得这是个问题,那么只能使用上面的大厂的第一个方案了。

3. 小结

无论大厂小厂,当对Go的使用逐渐深入后,接纳的人增多,开发的项目增多且越来越复杂后,拉取私有go module这样的问题肯定会摆到桌面上来。

对于大厂的gopher来说,这可能不是问题,甚至对他们都是透明的。但对于小厂等内部IT基础设施不完备的组织而言,的确需要自己动手解决。

这篇文章为小厂搭建Go私有库以及从私有库拉取私有go module提供了一个思路以及一个参考实现。

如果觉得上面的安装配置步骤有些繁琐,有兴趣深入的朋友可以将上述几个程序(goproxy, nginx, govanityurls)打到一个容器镜像中,实现一键安装设置。


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订
阅!

img{512x368}

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商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
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
img{512x368}

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

Go 1.17新特性详解:使用基于寄存器的调用惯例

本文永久链接 – https://tonybai.com/2021/08/20/using-register-based-calling-convention-in-go-1-17

除了Go语言特性go module有重要变化之外,Go编译器与Go运行时也都有着优化与改进,这两方面的变化对Go程序的构建与运行影响巨大。在这个系列的最后一篇中,我们来看看编译器与运行时中那些值得关注的变化。

1. 使用基于寄存器的调用惯例替代基于堆栈的调用惯例

所谓“调用惯例(calling convention)”是调用方和被调用方对于函数调用的一个明确的约定,包括:函数参数与返回值的传递方式、传递顺序。只有双方都遵守同样的约定,函数才能被正确地调用和执行。如果不遵守这个约定,函数将无法正确执行。

Go 1.17版本之前,Go采用基于栈的调用约定,即函数的参数与返回值都通过栈来传递,这种方式的优点是实现简单,不用担心底层cpu架构寄存器的差异,适合跨平台;但缺点就是牺牲了一些性能,我们都知道寄存器的访问速度要远高于内存。

大多数平台上的大多数语言实现都使用基于寄存器的调用约定,通过寄存器而不是内存传递函数参数和返回结果,并指定一些寄存器为调用保存寄存器,允许函数在不同的调用中保持状态。

于是Go在1.17版本决定向这些语言看齐,在amd64架构下率先实现了从基于堆栈的调用惯例到基于寄存器的调用惯例切换

在Go 1.17的版本发布说明文档中有提到:切换到基于寄存器的调用惯例后,一组有代表性的Go包和程序的基准测试显示,Go程序的运行性能提高了约5%,二进制文件大小典型减少约2%。

我们来实测一下,下面采用的是之前进阶专栏中的一个多种方法进行字符串连接的benchmark测试,在Go 1.16.5和Go 1.17下面分别运行Benchmark结果如下:

Go 1.16.5:

$go test -bench .
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkConcatStringByOperator-8                       12132355            91.51 ns/op
BenchmarkConcatStringBySprintf-8                         2707862           445.1 ns/op
BenchmarkConcatStringByJoin-8                           24101215            50.84 ns/op
BenchmarkConcatStringByStringsBuilder-8                 11104750           124.4 ns/op
BenchmarkConcatStringByStringsBuilderWithInitSize-8     24542085            48.24 ns/op
BenchmarkConcatStringByBytesBuffer-8                    14425054            77.73 ns/op
BenchmarkConcatStringByBytesBufferWithInitSize-8        20863174            49.07 ns/op
PASS
ok      github.com/bigwhite/demo    9.166s

Go 1.17:

$go test -bench .
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkConcatStringByOperator-8                       13058850            89.47 ns/op
BenchmarkConcatStringBySprintf-8                         2889898           410.1 ns/op
BenchmarkConcatStringByJoin-8                           25469310            47.15 ns/op
BenchmarkConcatStringByStringsBuilder-8                 13064298            92.33 ns/op
BenchmarkConcatStringByStringsBuilderWithInitSize-8     29780911            41.14 ns/op
BenchmarkConcatStringByBytesBuffer-8                    16900072            70.28 ns/op
BenchmarkConcatStringByBytesBufferWithInitSize-8        27310650            43.96 ns/op
PASS
ok      github.com/bigwhite/demo    9.198s

我们看到,相对于Go 1.16.5跑出的结果,Go 1.17在每一个测试项上都有小幅的性能提升,有些性能提升甚至达到10%左右。这种新版本带来的性能的“自然提升”显然是广大Gopher想看到的。

我们再来看看编译后的Go二进制文件的Size变化。以一个自有的1w行左右代码的Go程序为例,分别用Go 1.16.5和Go 1.17进行编译,得到的结果如下:

-rwxr-xr-x   1 tonybai  staff  7264432  8 13 18:31 myapp-go1.16.5*
-rwxr-xr-x   1 tonybai  staff  6934352  8 13 18:32 myapp-go1.17*

我们看到Go 1.17编译后的二进制文件大小相较于Go 1.16.5版本的减少了约4%。

另外Go 1.17发布说明也提到了:改为基于register的调用惯例后,绝大多数程序不会受到影响。只有那些之前就已经违反unsafe.Pointer的使用规则的代码可能会受到影响,比如不遵守unsafe规则通过unsafe.Pointer访问函数参数,或依赖一些像比较函数代码指针的未公开的行为。

除了改为基于寄存器的调用惯例之外,Go 1.17编译器还支持包含闭包的函数的内联(inline)了!这样一来,一个带有闭包的函数可能会在函数被内联的每个地方产生一个不同的闭包代码指针,因此,Go函数的值不能直接比较

2. 引入//go:build形式的构建约束指示符,以替代原先易错的// +build形式

Go 1.17之前,我们可以通过在源码文件头部放置+build构建约束指示符来实现构建约束,但这种形式十分易错,并且它并不支持&&和||这样的直观的逻辑操作符,而是用逗号、空格替代,下面是原+build形式构建约束指示符的用法及含义:

这种与程序员直觉“有悖”的形式让Gopher们十分痛苦,于是Go 1.17回归“正规”,引入了//go:build形式的构建约束指示符,这样一方面是与源文件中的其他指示符保持形式一致,比如: //go:nosplit、//go:norace、//go:noinline、//go:generate等。另外一方面,新形式将支持&&和||逻辑操作符,对于程序员来说,这样的形式就是自解释的,我们无需再像上面那样列出一个表来解释每个指示符组合的含义了,如下代码所示:

//go:build linux && (386 || amd64 || arm || arm64 || mips64 || mips64le || ppc64 || ppc64le)
//go:build linux && (mips64 || mips64le)
//go:build linux && (ppc64 || ppc64le)
//go:build linux && !386 && !arm

考虑到兼容性,Go命令可以识别这两种形式的构建约束指示符,但推荐Go 1.17之后都用新引入的这种形式。

gofmt可以兼容处理两种形式,处理原则是:如果一个源码文件只有// +build形式的指示符,gofmt会将与其等价的//go:build行加入。否则,如果一个源文件中同时存在这两种形式的指示符行,那么//+build行的信息将被//go:build行的信息所覆盖。

go vet工具也会检测源文件中同时存在的不同形式的构建指示符语义不一致的情况,比如针对下面这段代码:

// github.com/bigwhite/experiments/tree/master/go1.17-examples/runtime/buildtag.go

//go:build linux && !386 && !arm
// +build linux

package main

import "fmt"

func main() {
    fmt.Println("hello, world")
}

go vet会提示如下问题:

./buildtag.go:2:1: +build lines do not match //go:build condition

3. 运行时栈跟踪输出信息的格式更“可读”

之前写过一篇文章《记一次go panic问题的解决过程》,在那篇文章中,我们探讨了如何解读panic发生后输出的函数栈跟踪信息。

下面的代码示例用于对比运行时栈输出信息的差异:

// github.com/bigwhite/experiments/tree/master/go1.17-examples/runtime/stacktrace.go

package main

type myStruct struct {
    m int
    s string
    p *float64
}

func foo(a int, b string, c []byte, f *myStruct) (int, error) {
    panic("mypanic")
}

func main() {
    f := 3.14
    ms := myStruct{
        m: 17,
        s: "myStruct",
        p: &f,
    }
    a := 11
    b := "hello"
    c := []byte{'a', 'b', 'c'}
    foo(a, b, c, &ms)
}

在这个示例程序中,我们在foo函数中“故意”panic,以便go运行时在程序退出前输出栈跟踪信息(注意编译时关闭内联优化)。针对这个示例程序,Go 1.17之前的版本输出的栈跟踪信息是这样的(go 1.16.5版本):

$go build -gcflags '-N -l' -o stacktrace-go1.16.5 stacktrace.go
$./stacktrace-go1.16.5
panic: mypanic

goroutine 1 [running]:
main.foo(0xb, 0x1073f53, 0x5, 0xc000046715, 0x3, 0x3, 0xc000046758, 0x0, 0x0, 0x0)
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:10 +0x4a
main.main()
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:23 +0x148

上面输出信息中foo函数后面括号中的各个值与foo函数原型完全对不上。要想知道这些数值的含义究竟是什么,可以参考我上面提到的那篇文章,这里不赘述。

使用Go 1.17版本编译后会是什么样子呢?我们再来看一下:

go 1.17:

$go build -gcflags '-N -l' -o stacktrace-go1.17 stacktrace.go
$./stacktrace
panic: mypanic

goroutine 1 [running]:
main.foo(0xb, {0x10608d4, 0x5}, {0xc00004270d, 0x3, 0x3}, 0xc000042750)
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:10 +0x59
main.main()
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:23 +0x10f

对照着该示例程序中foo函数的原型:

func foo(a int, b string, c []byte, f *myStruct) (int, error)

这回一目了然了!我们看到Go 1.17改进了当发送未捕获的panic或当runtime.Stack被调动时,运行时输出的栈跟踪信息的格式。Go 1.17版本之前,函数参数被打印成基于内存布局的十六进制值的形式,就像前面那个难于解读的输出信息。Go 1.17版,源码中函数的每个参数都被单独打印,用逗号分隔。聚合类型(结构体、数组、字符串、切片、接口和complex)的参数用大括号分隔。需要注意的是,只存在于寄存器中而没有存储到内存中的参数的值可能是不准确的。函数的返回值(通常是不准确的)不再被打印了。

通过上的输出,我们还可以清晰的看到stringbyte切片以及结构体在内存中的表示方式,string本质上是一个拥有两个字段的结构,而切片则是一个三元组表示的结构。

3. 小结

上面是Go 1.17编译器与运行时的主要改动,通过使用寄存器的调用惯例,我们的Go程序可以轻松获得5%左右的性能提升,可执行程序的Size也会得到减小。Go 1.17对运行时栈输出信息的“可读化”改进进一步提升了开发体验。

除此之外,Go的标准库随着新版本的发布都会有大量的改动,但每个开发人员对标准库的关注点差别很大,因此,在这个系列中不会详细做说明了,大家还是参考Go 1.17的发布说明文档各取所需吧^_^。

本文所涉及的源码可以在这里 – https://github.com/bigwhite/experiments/tree/master/go1.17-examples/


“Gopher部落”知识星球正式转正(从试运营星球变成了正式星球)!“gopher部落”旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!部落目前虽小,但持续力很强。在2021年上半年,部落将策划两个专题系列分享,并且是部落独享哦:

  • Go技术书籍的书摘和读书体会系列
  • Go与eBPF系列

欢迎大家加入!

Go技术专栏“改善Go语⾔编程质量的50个有效实践”正在慕课网火热热销中!本专栏主要满足广大gopher关于Go语言进阶的需求,围绕如何写出地道且高质量Go代码给出50条有效实践建议,上线后收到一致好评!欢迎大家订
阅!

img{512x368}

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网热卖中,欢迎小伙伴们订阅学习!

img{512x368}

我爱发短信:企业级短信平台定制开发专家 https://51smspush.com/。smspush : 可部署在企业内部的定制化短信平台,三网覆盖,不惧大并发接入,可定制扩展; 短信内容你来定,不再受约束, 接口丰富,支持长短信,签名可选。2020年4月8日,中国三大电信运营商联合发布《5G消息白皮书》,51短信平台也会全新升级到“51商用消息平台”,全面支持5G RCS消息。

著名云主机服务厂商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
  • “Gopher部落”知识星球:https://public.zsxq.com/groups/51284458844544

微信赞赏:
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