容器 | Tony Bai

标签容器下的文章

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

九月 3, 2021
2 条评论

本文永久链接 – 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.cn和goproxy.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://tonybai.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语言的plugin

七月 19, 2021
2 条评论

本文永久链接 – https://tonybai.com/2021/07/19/understand-go-plugin

要历数Go语言中还有哪些我还没用过的特性，在Go 1.8版本中引入的go plugin算一个。近期想给一个网关类平台设计一个插件系统，于是想起了go plugin^_^。

Go plugin支持将Go包编译为共享库（.so）的形式单独发布，主程序可以在运行时动态加载这些编译为动态共享库文件的go plugin，从中提取导出(exported)变量或函数的符号并在主程序的包中使用。Go plugin的这种特性为Go开发人员提供更多的灵活性，我们可以用之实现支持热插拔的插件系统。

但不得不提到的一个事实是：go plugin自诞生以来已有4年多了，但它依旧没有被广泛地应用起来。究其原因，（我猜）一方面Go自身支持静态编译，可以将应用编译为一个完全不需要依赖操作系统运行时库(一般为libc)的可执行文件，这是Go的优势，而支持go plugin则意味着你只能对主程序进行动态编译，与静态编译的优势相悖；而另外一方面原因占比更大，那就是Go plugin自身有太多的对使用者的约束，这让很多Go开发人员望而却步。

只有亲历，才能体会到其中的滋味。在这篇文章中，我们就一起来看看go plugin究竟是何许东东，它对使用者究竟有着怎样的约束，我们究竟要不要使用它。

1. go plugin的基本使用方法

截至Go 1.16版本，Go官方文档明确说明go plugin只支持Linux, FreeBSD和macOS，这算是go plugin的第一个约束。在处理器层面，go plugin以支持amd64(x86-64)为主，对arm系列芯片的支持似乎没有明确说明（我翻看各个Go版本release notes也没看到，也许是我漏掉了），但我在华为的泰山服务器(鲲鹏arm64芯片)上使用Go 1.16.2(for arm64)版本构建plugin包以及加载动态共享库.so文件的主程序都顺利通过编译，运行也一切正常。

主程序通过plugin包加载.so并提取.so文件中的符号的过程与C语言应用运行时加载动态链接库并调用库中函数的过程如出一辙。下面我们就来看一个直观的例子。

下面是这个例子的结构布局：

// github.com/bigwhite/experiments/tree/master/go-plugin

├── demo1
│   ├── go.mod
│   ├── main.go
│   └── pkg
│       └── pkg1
│           └── pkg1.go
└── demo1-plugins
    ├── Makefile
    ├── go.mod
    └── plugin1.go

其中demo1代表主程序工程，demo1-plugins是主程序的plugins工程。下面是插件工程的代码：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo1-plugins/plugin1.go

package main

import (
    "fmt"
    "log"
)

func init() {
    log.Println("plugin1 init")
}

var V int

func F() {
    fmt.Printf("plugin1: public integer variable V=%d\n", V)
}

type foo struct{}

func (foo) M1() {
    fmt.Println("plugin1: invoke foo.M1")
}

var Foo foo

plugin包和普通的Go包没太多区别，只是plugin包有一个约束：其包名必须为main，我们使用下面命令编译该plugin：

$go build -buildmode=plugin -o plugin1.so plugin1.go

如果plugin源代码没有放置在main包下面，我们在编译plugin时会遭遇如下编译器错误：

-buildmode=plugin requires exactly one main package

接下来，我们来看主程序(demo1)：

package main

import (
    "fmt"

    "github.com/bigwhite/demo1/pkg/pkg1"
)

func main() {
    err := pkg1.LoadAndInvokeSomethingFromPlugin("../demo1-plugins/plugin1.so")
    if err != nil {
        fmt.Println("LoadAndInvokeSomethingFromPlugin error:", err)
        return
    }
    fmt.Println("LoadAndInvokeSomethingFromPlugin ok")
}

下面是主程序demo1工程中的关键代码：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo1/main.go
package main

import (
    "fmt"

    "github.com/bigwhite/demo1/pkg/pkg1"
)

func main() {
    err := pkg1.LoadAndInvokeSomethingFromPlugin("../demo1-plugins/plugin1.so")
    if err != nil {
        fmt.Println("LoadAndInvokeSomethingFromPlugin error:", err)
        return
    }
    fmt.Println("LoadAndInvokeSomethingFromPlugin ok")
}

我们在main函数中调用pkg1包的LoadAndInvokeSomethingFromPlugin函数，该函数会加载main函数传入的go plugin、查找plugin中相应符号并通过这些符号使用plugin中的导出变量、函数等。下面是LoadAndInvokeSomethingFromPlugin函数的实现：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo1/pkg/pkg1/pkg1.go

package pkg1

import (
    "errors"
    "plugin"
    "log"
)

func init() {
    log.Println("pkg1 init")
}

type MyInterface interface {
    M1()
}

func LoadAndInvokeSomethingFromPlugin(pluginPath string) error {
    p, err := plugin.Open(pluginPath)
    if err != nil {
        return err
    }

    // 导出整型变量
    v, err := p.Lookup("V")
    if err != nil {
        return err
    }
    *v.(*int) = 15

    // 导出函数变量
    f, err := p.Lookup("F")
    if err != nil {
        return err
    }
    f.(func())()

    // 导出自定义类型变量
    f1, err := p.Lookup("Foo")
    if err != nil {
        return err
    }
    i, ok := f1.(MyInterface)
    if !ok {
        return errors.New("f1 does not implement MyInterface")
    }
    i.M1()

    return nil
}

在LoadAndInvokeSomethingFromPlugin函数中，我们通过plugin包提供的Plugin类型提供的Lookup方法在加载的.so中查找相应的导出符号，比如上面的V、F和Foo等。Lookup方法返回plugin.Symbol类型，而Symbol类型定义如下：

// $GOROOT/src/plugin/plugin.go
type Symbol interface{}

我们看到Symbol的底层类型(underlying type)是interface{}，因此它可以承载从plugin中找到的任何类型的变量、函数(得益于函数是一等公民)的符号。而plugin中定义的类型则是不能被主程序查找的，通常主程序也不会依赖plugin中定义的类型。

一旦Lookup成功，我们便可以将符号通过类型断言(type assert)获取到其真实类型的实例，通过这些实例(变量或函数)，我们可以调用plugin中实现的逻辑。编译plugin后，运行上述主程序，我们可以看到如下结果：

$go run main.go
2021/06/15 10:05:22 pkg1 init
try to LoadAndInvokeSomethingFromPlugin...
2021/06/15 10:05:22 plugin1 init
plugin1: public integer variable V=15
plugin1: invoke foo.M1
LoadAndInvokeSomethingFromPlugin ok

那么，主程序是如何知道导出的符号究竟是函数还是变量呢？这取决于主程序插件系统的设计，因为主程序与plugin间必然要有着某种“契约”或“约定”。就像上面主程序定义的MyInterface接口类型，它就是一个主程序与plugin之间的约定，plugin中只要暴露实现了该接口的类型实例，主程序便可以通过MyInterface接口类型实例与其建立关联并调用plugin中的实现。

2. plugin中包的初始化

在上面的例子中我们看到，插件的初始化(plugin1 init)发生在主程序open .so文件时。按照官方文档的说法：“当一个插件第一次被open时，plugin中所有不属于主程序的包的init函数将被调用，但一个插件只被初始化一次，而且不能被关闭”。

我们来验证一下在主程序中多次加载同一个plugin的情况，这次我们将程序升级为demo2和demo2-plugins：

主程序代码如下：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2/main.go

package main

import (
    "fmt"

    "github.com/bigwhite/demo2/pkg/pkg1"
)

func main() {
    fmt.Println("try to LoadPlugin...")
    err := pkg1.LoadPlugin("../demo2-plugins/plugin1.so")
    if err != nil {
        fmt.Println("LoadPlugin error:", err)
        return
    }
    fmt.Println("LoadPlugin ok")
    err = pkg1.LoadPlugin("../demo2-plugins/plugin1.so")
    if err != nil {
        fmt.Println("Re-LoadPlugin error:", err)
        return
    }
    fmt.Println("Re-LoadPlugin ok")
}

package pkg1

import (
    "log"
    "plugin"
)

func init() {
    log.Println("pkg1 init")
}

func LoadPlugin(pluginPath string) error {
    _, err := plugin.Open(pluginPath)
    if err != nil {
        return err
    }
    return nil
}

由于仅是验证初始化，我们去掉了查找符号和调用的环节。plugin的代码如下：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2-plugins/plugin1.go
package main

import (
    "log"

    _ "github.com/bigwhite/common"
)

func init() {
    log.Println("plugin1 init")
}

在demo2的plugin中，我们同样仅保留初始化相关的代码，这里我们在demo2的plugin1中还增加了一个外部依赖：github.com/bigwhite/common。

运行上述代码：

$go run main.go
2021/06/15 10:50:47 pkg1 init
try to LoadPlugin...
2021/06/15 10:50:47 common init
2021/06/15 10:50:47 plugin1 init
LoadPlugin ok
Re-LoadPlugin ok

通过这个输出结果，我们验证了两点说法：

重复加载同一个plugin，不会触发多次plugin包的初始化，上述结果中仅输出一次：“plugin1 init”；
plugin中依赖的包，但主程序中没有的包，在加载plugin时，这些包会被初始化，如：“commin init”。

如果主程序也依赖github.com/bigwhite/common包，我们在主程序的main包中增加一行：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2/main.go
import (
    "fmt"   

    _ "github.com/bigwhite/common"    // 增加这一行
    "github.com/bigwhite/demo2/pkg/pkg1"
)

那么我们再执行demo2，输出如下结果：

2021/06/15 11:00:00 common init
2021/06/15 11:00:00 pkg1 init
try to LoadPlugin...
2021/06/15 11:00:00 plugin1 init
LoadPlugin ok
Re-LoadPlugin ok

我们看到common包在demo2主程序中已经做了初始化，这样当加载plugin时，common包不会再进行初始化了。

3. go plugin的使用约束

开篇我们就提到了，go plugin应用不甚广泛的一个主因是其约束较多，这里我们来看一下究竟go plugin都有哪些约束：

1) 主程序与plugin的共同依赖包的版本必须一致

在上面demo2中，主程序和plugin依赖的github.com/bigwhite/common包是一个本地module，我们在go.mod中使用replace指向本地路径：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo2/go.mod

module github.com/bigwhite/demo2

replace github.com/bigwhite/common => /Users/tonybai/go/src/github.com/bigwhite/experiments/go-plugin/common

require github.com/bigwhite/common v0.0.0-20180202201655-eb2c6b5be1b6 // 这个版本号是自行“伪造”的

go 1.16

如果我clone一份common包，将其放在common1目录下，并在plugin的go.mod中将replace github.com/bigwhite/common语句指向common1目录，我们重新编译主程序和plugin后，运行主程序，我们将得到如下结果：

$go run main.go
2021/06/15 14:09:07 common init
2021/06/15 14:09:07 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo2-plugins/plugin1"): plugin was built with a different version of package github.com/bigwhite/common

我们看到因common的版本不同，plugin加载失败，这是plugin使用的一个约束：主程序与plugin的共同依赖包的版本必须一致。

我们再来看一个主程序与plugin有共同以来包的例子。我们建立demo3，在这个版本中，主程序和plugin都依赖了logrus日志包，但主程序使用的是logrus 1.8.1版本，而plugin使用的是logrus 1.8.0版本，分别编译后，我们运行主程序：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo3

2021/06/15 14:18:35 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo3-plugins/plugin1"): plugin was built with a different version of package github.com/sirupsen/logrus

我们看到主程序运行报错，和前面的例子提示一样，都是因为使用了版本不一致的第三方包。要想解决这个问题，我们只需让两者使用的logrus包版本保持一致即可，比如将主程序的logrus从v1.8.1降级为v1.8.0：

$go get github.com/sirupsen/logrus@v1.8.0
go get: downgraded github.com/sirupsen/logrus v1.8.1 => v1.8.0
$go run main.go
2021/06/15 14:19:09 pkg1 init
try to LoadPlugin...
2021/06/15 14:19:09 plugin1 init
LoadPlugin ok

我们看到降级logrus版本后，主程序便可以正常加载plugin了。

还有一种情况，那就是主程序与plugin使用了同一个module的不同major版本的包，由于major版本不同，虽然是同一module，但实则是两个不同的包，这不会影响主程序对plugin的加载。但问题在于这个被共同依赖的module也会有自己的依赖包，当其不同major版本所依赖的某个包的版本不同时，同样会导致主程序加载plugin出现问题。比如：主程序依赖go-redis/redis的v6.15.9+incompatible版本，而plugin依赖的是go-redis/redis/v8版本，当我们使用这样的主程序去加载plugin时，我们会遇到如下错误：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo3

$go run main.go
2021/06/15 14:32:11 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo3-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix

我们看到redis版本并未出错，但问题出在redis与redis/v8所依赖的golang.org/x/sys的版本不同，这种间接依赖的module的版本的不一致同样会导致go plugin加载失败，这同样是go plugin的使用约束之一。

2) 如果采用mod=vendor构建，那么主程序和plugin必须基于同一个vendor目录构建

基于vendor构建是go 1.5版本引入的特性，go 1.11版本引入go module构建模式后，vendor构建的方式得以保留。那么问题来了，如果主程序或plugin采用vendor构建或同时采用vendor构建，那么主程序是否可以正常加载plugin呢？我们来用示例demo4验证一下。(demo4和demo3大同小异，这里就不列出具体代码了）。

首先我们分别为主程序(demo4)和plugin(demo4-plugins)生成vendor目录：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go mod vendor

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go mod vendor

我们测试如下三种情况(go 1.16版本默认在有vendor的情况下，优先使用vendor构建。所以要基于mod构建需要显式的传入-mod=mod)：

主程序基于mod构建，插件基于vendor构建

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go build -mod=vendor -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=mod -o main.mod main.go

$main.mod
2021/06/15 15:41:21 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix

主程序基于vendor构建，插件基于mod构建

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go build -mod=mod -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -o main.vendor main.go

$./main.vendor
2021/06/15 15:44:15 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix

主程序和插件分别基于各自的vendor构建

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go build -mod=vendor -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -o main.vendor main.go

$./main.vendor
2021/06/15 15:45:11 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package golang.org/x/sys/unix

从上面的测试，我们看到无论是哪一方采用vendor构建，或者双方都基于各自vendor构建，主程序加载plugin都会失败。如何解决这一问题呢？让主程序和plugin基于同一个vendor构建!

我们将plugin1.go拷贝到demo4中，然后分别用vendor构建构建主程序和plugin1.go：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -o main.vendor main.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build -mod=vendor -buildmode=plugin -o plugin1.so plugin1.go

将编译生成的plugin1.so拷贝到demo4-plugins中，然后运行main.vendor：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$cp plugin1.so ../demo4-plugins
$main.vendor
2021/06/15 15:48:56 pkg1 init
try to LoadPlugin...
2021/06/15 15:48:56 plugin1 init
LoadPlugin ok

我们看到基于同一vendor的主程序与plugin是可以相容的。下面的表格总结了主程序与plugin采用不同构建模式时是否相容：

插件构建方式\主程序构建方式	基于mod	基于自己的vendor
基于mod	加载成功	加载失败
基于基于自己的vendor	加载失败	加载失败

在vendor构建模式下，只有基于同一个vendor目录构建时，plugin才能被主程序加载成功！

3) 主程序与plugin使用的编译器版本必须一致

如果我们使用不同版本的Go编译器分别编译主程序以及plugin，那么这两者是否能相容呢？我们还拿demo4来验证一下。我在主机上准备了go 1.16.5和go 1.16两个版本的Go编译器，go 1.16.5是go 1.16的patch维护版本，其区别与go 1.16与go 1.15相比则不是一个量级的，我们用go 1.16编译主程序，用go 1.16.5编译plugin：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4-plugins
$go version
go version go1.16.5 darwin/amd64
$go build -buildmode=plugin -o plugin1.so plugin1.go

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go version
go version go1.16 darwin/amd64

$go run main.go
2021/06/15 15:58:44 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin.Open("../demo4-plugins/plugin1"): plugin was built with a different version of package runtime/internal/sys

我们看到即便用patch版本编译，plugin与主程序也是不兼容的。我们将demo4升级到用go 1.16.5版本编译：

$go version
go version go1.16.5 darwin/amd64
$go run main.go
2021/06/15 15:59:05 pkg1 init
try to LoadPlugin...
2021/06/15 15:59:05 plugin1 init
LoadPlugin ok

我们看到只有主程序与plugin采用完全相同的版本(patch版本也要相同）编译时，它们才是相容的，主程序才能正常加载plugin。

那么操作系统版本是否影响主程序和plugin的相容性呢？这个没有官方说明，我亲测了一下。我在centos 7.6(amd64, go 1.16.5)上构建了demo4-plugin(基于mod=mod），然后将其拷贝到一台ubuntu 18.04(amd64, go1.16.5)的主机上，ubuntu主机上的demo4主程序可以与centos上编译出来的plugin相容。

4) 使用plugin的主程序仅能使用动态链接

Go以静态编译便于分发和部署著称，但使用plugin的主程序仅能使用动态链接。不信？那我们来挑战一下静态编译demo4中的主程序。

先来看看默认编译的情况：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$go build main.go
$ldd main
    linux-vdso.so.1 (0x00007ffc05b73000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6a9fa3f000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6a9f820000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6a9f42f000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f6a9fc43000)

我们看到默认编译的情况下，demo4主程序被编译为一个需要在运行时动态链接的可执行文件，它依赖诸多linux系统运行时库，比如：libc等。

这一切的原因都是我们在demo4中使用了一些通过cgo实现的标准库，比如plugin包：

// $GOROOT/src/plugin/plugin_dlopen.go

// +build linux,cgo darwin,cgo freebsd,cgo

package plugin

/*
#cgo linux LDFLAGS: -ldl
#include <dlfcn.h>
#include <limits.h>
#include <stdlib.h>
#include <stdint.h>

#include <stdio.h>

static uintptr_t pluginOpen(const char* path, char** err) {
    void* h = dlopen(path, RTLD_NOW|RTLD_GLOBAL);
    if (h == NULL) {
        *err = (char*)dlerror();
    }
    return (uintptr_t)h;
}
... ...
*/

我们看到plugin_dlopen.go的头部有build指示符，它仅在cgo开启的前提下才会被编译，如果我们去掉cgo，比如利用下面这行命令：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4
$ CGO_ENABLED=0 go build main.go
$ ldd main
    not a dynamic executable

我们确实编译出一个静态链接的可执行文件，但当我们执行该文件时，我们得到如下结果：

$ ./main
2021/06/15 17:01:51 pkg1 init
try to LoadPlugin...
LoadPlugin error: plugin: not implemented

我们看到由于cgo被关闭，plugin包的一些函数并没有被编译到最终可执行文件中，于是报了”not implemented”的错误！

在CGO开启的情况下，我们依旧可以让外部链接器使用静态链接，我们再来试一下：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo4

$ go build -o main-static -ldflags '-linkmode "external" -extldflags "-static"' main.go
# command-line-arguments
/tmp/go-link-638385712/000001.o: In function `pluginOpen':
/usr/local/go/src/plugin/plugin_dlopen.go:19: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
$ ldd main-static
    not a dynamic executable

我们的确得到了一个静态编译的二进制文件，但编译器也给出了warning。

执行这个文件：

$ ./main-static
2021/06/15 17:02:35 pkg1 init
try to LoadPlugin...
fatal error: runtime: no plugin module data

goroutine 1 [running]:
runtime.throw(0x5d380a, 0x1e)
    /usr/local/go/src/runtime/panic.go:1117 +0x72 fp=0xc000091b50 sp=0xc000091b20 pc=0x435712
plugin.lastmoduleinit(0xc000076210, 0x1001, 0x1001, 0xc000010040, 0x24db1f0)
    /usr/local/go/src/runtime/plugin.go:20 +0xb50 fp=0xc000091c48 sp=0xc000091b50 pc=0x466750
plugin.open(0x5d284c, 0x18, 0xc0000788f0, 0x0, 0x0)
    /usr/local/go/src/plugin/plugin_dlopen.go:77 +0x4ef fp=0xc000091ec0 sp=0xc000091c48 pc=0x4dad8f
plugin.Open(...)
    /usr/local/go/src/plugin/plugin.go:32
github.com/bigwhite/demo4/pkg/pkg1.LoadPlugin(0x5d284c, 0x1b, 0xc000091f48, 0x1)
    /root/test/go/plugin/demo4/pkg/pkg1/pkg1.go:13 +0x35 fp=0xc000091ef8 sp=0xc000091ec0 pc=0x4dbbb5
main.main()
    /root/test/go/plugin/demo4/main.go:12 +0xa5 fp=0xc000091f88 sp=0xc000091ef8 pc=0x4ee805
runtime.main()
    /usr/local/go/src/runtime/proc.go:225 +0x256 fp=0xc000091fe0 sp=0xc000091f88 pc=0x438196
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc000091fe8 sp=0xc000091fe0 pc=0x46a841

warning最终演变为运行时的panic，看来使用plugin的主程序只能编译为动态链接的可执行程序了。目前go项目有多个issue与此有关：

https://github.com/golang/go/issues/33072
https://github.com/golang/go/issues/17150
https://github.com/golang/go/issues/18123

4. plugin版本管理

使用动态链接实现插件系统，一个更大的问题就是插件的版本管理问题。

linux上的动态链接库采用soname的方式进行版本管理。soname的关键功能是它提供了兼容性的标准，当要升级系统中的一个库时，并且新库的soname和老库的soname一样，用旧库链接生成的程序使用新库依然能正常运行。这个特性使得在Linux下，升级使得共享库的程序和定位错误变得十分容易。

什么是soname呢？在/lib和/usr/lib等集中放置共享库的目录下，你总是会看到诸如下面的情况：

2019-12-10 12:28 libfoo.so -> libfoo.so.0.0.0*
2019-12-10 12:28 libfoo.so.0 -> libfoo.so.0.0.0*
2019-12-10 12:28 libfoo.so.0.0.0*

关于libfoo.so居然有三个文件入口，其中libfoo.so.0.0.0是真正的共享库文件，而其他两个文件入口则是指向libfoo.so.0.0.0的符号链接。为何会出现这个情况呢？这与共享库的命名惯例和版本管理不无关系。

共享库的惯例中每个共享库都有多个名字属性，包括real name、soname和linker name：

real name

real name指的是实际包含共享库代码的那个文件的名字(如上面例子中的libfoo.so.0.0.0)，也是在共享库编译命令行中-o后面的那个参数；

soname

soname则是shared object name的缩写，也是这三个名字中最重要的一个，无论是在编译阶段还是在运行阶段，系统链接器都是通过共享库的soname(如上面例子中的libfoo.so.0)来唯一识别共享库的。即使real name相同但soname不同，也会被链接器认为是两个不同的库。共享库的soname可在编译期间通过传给链接器的参数来指定，如我们可以通过”gcc -shared -Wl,-soname -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o”来指定libfoo.so.0.0.0的soname为libfoo.so.0。ldconfig -n directory_with_shared_libraries命令会根据共享库的soname自动生成一个名为soname的符号链接指向real name文件，当然你也可以通过ln命令自己来创建这个符号链接。另外在linux下我们可通过readelf -d查看共享库的soname，ldd输出的ELF文件依赖的共享库列表中显示的也是共享库的soname及所在路径。

linker name

linker name是编译阶段提供给编译器的名字(如上面例子中的libfoo.so)。如果你构建的共享库的real name是类似于上例中libfoo.so.0.0.0那样的带有版本号的样子，那么你在编译器命令中直接使用-L path -lfoo是无法让链接器找到对应的共享库文件的，除非你为libfoo.so.0.0.0提供了一个linker name(如libfoo.so，一个指向libfoo.so.0.0.0的符号链接)。linker name一般在共享库安装时手工创建。

那么go plugin是否可以用soname的方式来做版本管理呢？基于demo1我们创建demo5，并来做一下试验。

在demo5-plugins中，我们为构建出的.so增加版本信息：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo5-plugins

$go build -buildmode=plugin -o plugin1.so.1.1 plugin1.go
$ln -s plugin1.so.1.1 plugin1.so.1
$ls -l
lrwxr-xr-x  1 tonybai  staff       14  7 16 05:42 plugin1.so.1@ -> plugin1.so.1.1
-rw-r--r--  1 tonybai  staff  2888408  7 16 05:42 plugin1.so.1.1

我们通过ln命令为构建出的plugin1.so.1.1创建了一个符号链接plugin1.so.1，plugin1.so.1作为我们插件的soname传给demo5：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo5/main.go

func main() {
    fmt.Println("try to LoadAndInvokeSomethingFromPlugin...")
    err := pkg1.LoadAndInvokeSomethingFromPlugin("../demo5-plugins/plugin1.so.1")
    if err != nil {
        fmt.Println("LoadAndInvokeSomethingFromPlugin error:", err)
        return
    }
    fmt.Println("LoadAndInvokeSomethingFromPlugin ok")
}

运行demo5：

// github.com/bigwhite/experiments/tree/master/go-plugin/demo5

$go run main.go
2021/07/16 05:58:33 pkg1 init
try to LoadAndInvokeSomethingFromPlugin...
2021/07/16 05:58:33 plugin1 init
plugin1: public integer variable V=15
plugin1: invoke foo.M1
LoadAndInvokeSomethingFromPlugin ok

我们看到以soname传入的插件被顺利加载并提取符号。

后续如果plugin发生变更，比如打了patch，我们只需要升级plugin为plugin1.so.1.2，然后soname依旧保持不变，主程序也无需变动。

注意：如果插件名相同，内容相同，主程序多次加载不会出现问题；但插件名相同，但内容不同，主程序运行时多次load会导致runtime panic，并且是无法恢复的panic。所以务必做好插件的版本管理。

5. 小结

go plugin是go语言原生提供的一种go插件方案（非go插件方案，可以使用c shared library等）。但经过上面的实验和学习，我们我们看到了plugin使用的诸多约束，这的确给go plugin的推广使用造成的很大障碍，导致目前go plugin应用不甚广泛。

根据上面看到的种种约束，如果要应用go plugin，必须要做到:

构建环境一致
对第三方包的版本一致。

因此，业内在使用go plugin时多利用builder container（用来构建程序的容器）来保证主程序和plugin使用相同的构建环境。

在go plugin为数不多的用户中，有三个比较知名的开源项目值得后续认真研究：

gosh: https://github.com/vladimirvivien/gosh
tyk api gateway: https://github.com/TykTechnologies/tyk
tidb : https://github.com/pingcap/tidb

尤其是tidb，还给出了其插件系统使用go plugin的完整设计方案：https://github.com/pingcap/tidb/blob/master/docs/design/2018-12-10-plugin-framework.md，值得大家细致品读。

本文涉及的所有源码可以在这里下载：https://github.com/bigwhite/experiments/tree/master/go-plugin 。

6. 参考资料

https://golang.org/pkg/plugin/
https://golang.org/cmd/go/#hdr-Build_modes
https://golang.org/doc/go1.8
https://www.reddit.com/r/golang/comments/b6h8qq/is_anyone_actually_using_go_plugins/
https://medium.com/@alperkose/things-to-avoid-while-using-golang-plugins-f34c0a636e8
https://medium.com/learning-the-go-programming-language/writing-modular-go-programs-with-plugins-ec46381ee1a9

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

欢迎大家加入！

img{512x368}

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

img{512x368}

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 module拉取方案

1. 问题来由

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

0. 方案示例环境拓扑

1. 选择一个goproxy实现

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

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

4. 方案的“不足”

3. 小结

一文搞懂Go语言的plugin

1. go plugin的基本使用方法

2. plugin中包的初始化

3. go plugin的使用约束

1) 主程序与plugin的共同依赖包的版本必须一致

2) 如果采用mod=vendor构建，那么主程序和plugin必须基于同一个vendor目录构建

3) 主程序与plugin使用的编译器版本必须一致

4) 使用plugin的主程序仅能使用动态链接

4. plugin版本管理

5. 小结

6. 参考资料

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

文章

评论

分类

归档

链接

开源项目

翻译项目

标签 容器 下的文章

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

1. 问题来由

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

0. 方案示例环境拓扑

1. 选择一个goproxy实现

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

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

4. 方案的“不足”

3. 小结

一文搞懂Go语言的plugin

1. go plugin的基本使用方法

2. plugin中包的初始化

3. go plugin的使用约束

1) 主程序与plugin的共同依赖包的版本必须一致

2) 如果采用mod=vendor构建，那么主程序和plugin必须基于同一个vendor目录构建

3) 主程序与plugin使用的编译器版本必须一致

4) 使用plugin的主程序仅能使用动态链接

4. plugin版本管理

5. 小结

6. 参考资料

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

文章

评论

分类

标签

归档

链接

开源项目

翻译项目

标签容器下的文章