简介： 自己在设计和落地基于Go原生插件机制的扩大开发产品时踩到了很多坑，因为这方面相干材料很少，因此借此机会做一个十分浅显的总结，心愿能对大家有所帮忙。本文只说问题和解决方案，不读代码。
作者 | 丁飞起源 | 阿里开发者公众号导言自己在设计和落地基于Go原生插件机制的扩大开发产品时踩到了很多坑，因为这方面相干材料很少，因此借此机会做一个十分浅显的总结，心愿能对大家有所帮忙。本文只说问题和解决方案，不读代码。一些背景常识2.1 运行时通常而言，在计算机编程语言畛域，“运行时”的概念和一些须要应用到vm的语言相干。程序的运行由两个局部组成：指标代码和“虚拟机”。比方最为典型的JAVA，即Java Class + JRE。对于一些看似不须要“虚拟机”的编程语言，就不太会有“运行时”的概念，程序的运行只须要一个局部，即指标代码。但事实上，即便是C/C++，也有“运行时”，即它所运行平台的OS/Lib。Go也是一样，因为运行Go程序不须要前置部署相似于JRE的“运行时”，所以它看起来仿佛跟“虚拟机”或者“运行时”没啥关系。但事实上，Go语言的“运行时”被编译器编译成了二进制指标代码的一部分。
图2-1. Java程序、runtime和OS关系
图2-2. C/C++程序、runtime和OS关系
图2-3. Go程序、runtime和OS关系 2.2 Go原生插件机制作为一个看起来更贴近C/C++技术栈的Go语言来说，反对相似动态链接库的扩大始终是社区中较为强烈的诉求。如图2-5，Go在规范库中专门提供了一个plugin 包，作为插件的语言级编程界面，src/plugin 包的实质是应用cgo机制调用unix的标准接口：dlopen() 和dlsym() 。因而，它给C/C++背景的程序员一种“这题我会”的错觉。
图2-4. C/C++程序加载动态链接库
图2-5. Go程序加载动态链接库 典型问题解决很遗憾，与C/C++技术栈相比，Go的插件的产出物尽管也是一个动态链接库文件，但它对于插件的开发、应用有一系列很简单的内置束缚。更令人头大的是，Go语言岂但没有对这些束缚进行系统性的介绍，甚至写了一些比拟差的设计和实现，导致插件相干问题的排错十分反人类。本章节重点跟大家一起看下，在开发、应用Go插件，次要是编译、加载插件的时候，最常见、但必须定位到Go规范库（次要包含编译器、链接器、打包器和运行时局部）源码能力齐全弄明确的几个问题，及对应的解决办法。简而言之，Go的主程序在加载plugin时，会在“runtime”里对两者进行一堆束缚查看，包含但不限于：go version统一go path统一go dependency的交加统一代码统一path统一go build 某些flag统一3.1 不统一的规范库版本主程序加载插件时报错：plugin was built with a different version of package runtime/internal/sys从这个报错的文本能够得悉，具体有问题的库是runtime/internal/sys ，很显然这是一个go的内置规范库。看到这里，你可能会有很大的纳闷：我明明用的是同一个本地环境编译主程序和插件，为什么报规范库不是一个版本？答案是，go的error日志形容不精确。而这个报错呈现的根本原因能够归结为：主程序和插件的某些要害编译flag不统一，跟“版本”没啥关系。比方，你应用上面的命令编译插件：GO111MODULE=on go build --buildmode=plugin -mod readonly -o ./codec.so ./codec.go然而你应用goland的debug模式调试主程序，此时，goland会帮你把go build命令按上面的例子组装好：/usr/local/go/bin/go test -c -o /private/var/folders/gy/2zv22t710sd7m0x9bcfzq23r0000gp/T/GoLand/___Test_TaskC_in_github_com_fdingiit_mpl_test.test -gcflags all=-N -l github.com/fdingiit/mpl/test #gosetup留神，goland组装的编译命令里蕴含要害的-gcflags all=-N -l 参数，然而插件编译的命令里没有。此时，你在尝试拉起插件时就会失去一个无关runtime/internal/sys的报错。
图3-1. 编译flag不统一导致的加载失败 解决这一类规范库版本不统一问题的计划比较简单：尽可能对齐主程序和插件编译的flag。事实上，有一些flag是不影响插件加载的，你能够在具体的实际中缓缓摸索。3.2 不统一的第三方库版本如果你应用vendor来治理Go的依赖库，那么当解决3.1的问题之后，你100%会立刻遇到以下这个报错：plugin was built with a different version of package xxxxxxxx其中，xxxxxxxx 指的是某一个具体的三方库，比方github.com/stretchr/testify 。这个报错有几个十分典型的起因，如果没有相干的排查教训，其中几个可能会烧掉开发人员不少工夫。3.2.1 Case 1. 版本不统一如报错所示，仿佛起因很明确，即主程序和插件所独特依赖的某个第三方库版本不统一，报错中会明确通知你哪一个库有问题。此时，你能够比照排查主程序和插件的go.mod 文件，别离找到问题库的版本，看看他们是否统一。如果这时候你发现主程和插件的确有commitid或tag的不统一问题，那解决的办法也很简略：对齐它们。然而在很多场景下，你只会用到三方库的一部分：如一个package，或者只是引了一个interface。这一部分的代码在不同的版本里基本就没有变更；但其余没用到的代码的变更，同样会导致整个三方库版本号的变更，进而导致你成为那个“版本不统一”的无辜受害者。而且，此时你可能立刻会遇到另一个问题：以谁为基准对齐？主程序？还是插件？从常理上来说，以主程序为基线进行对齐是一个比拟好的策略，毕竟插件是新增加的“附属品”，且主程序与插件通常是1对多的关系。然而，如果插件的三方库依赖因为任何起因就是不能和主程序对齐怎么办？在尝试了很久当前，我临时没有找到一个完满解决这个问题的方法。如果版本无奈对齐，就只能从根本上放弃走插件这条路。Go语言的这种对三方库的、简直无脑的强一致性束缚，从一方面来说，防止了运行时因为版本不统一带来的潜在问题；从另一方面来说，这种刻意不给程序员灵便度的设计，对插件化、定制化、扩大化开发十分的不敌对。
图3-2. 独特依赖的三方库版本不统一导致的加载失败 3.2.2 case 2. 版本号统一，代码不统一当你依照3.2.1的思路排查go.mod 文件，然而诧异的发现报错的库版本是统一的时候，事件就会变得复杂起来。你可能会拿出世界上最先进的文本查验工具，并花掉一个上午去diff 三方库的commitid，但它们就是截然不同，仿佛陷入了薛定谔的版本。呈现这个问题可能的一个不是起因的起因是：有人间接批改了vendor目录下的代码，Go插件机制会对代码内容的一致性进行校验。这真的是一个十分令人头大，并难以排查的起因。除了批改代码的那个人，和曾经在其余case中被“坑”过的那些人，没人会晓得这件事件。如果批改的vendor代码呈现在主程序里，你就简直没有任何靠谱的方法让它们失常工作起来。不要间接在vendor里改代码，回馈开源社区，或者fork-replace。好消息是，你不须要解决这个问题。因为即便解决了，也还会有更大的问题等着你。
图3-2. 独特依赖的三方库代码被就地批改导致的加载失败 3.2.3 case 3. 门路不统一当依照3.2.1和3.2.2的思路都把问题排查、解决完，但它还是报different version of package的时候，可能你就会开始对Go的插件机制口吐芳香了：版本真的一毛一样，代码真的一行没动，为什么还报不同版本？？？起因是：插件机制会校验依赖库源码的「门路」，因而不能应用vendor治理依赖。举个例子：你的主程序源码放在/path/to/main目录下，因而，你的某个三方库依赖的目录应该是/path/to/main/vendor/some/thrid/part/lib；同理，你的插件源码放在/path/to/plugin目录下，因而，同一个三方库依赖的目录应该是/path/to/plugin/vendor/some/thrid/part/lib。这些「文件门路」数据会被打包到二进制可执行文件里并用于校验，当主程序加载插件时，Go的“运行时”“聪慧的”通过「文件门路」的差别认定它和插件用的不是同一份代码，而后报了个different version of package。
图3-3. 应用vendor机制治理第三方库导致的加载失败 同样的问题也可能会呈现在应用不同机器/用户，别离编译主程序、插件的场景下：用户名不同，go代码的门路应该也会不一样。解决这类问题的办法很暴力间接：删掉主程序和插件的vendor目录，或者应用-mod=readonly 编译flag。到这里，如果你是应用同一台机器进行主程序和插件的编译，那么常见的问题应该都根本解决了，插件机制理当可能失常工作。另一方面，因为不再应用vendor治理依赖，因而3.2.2的问题也会在这里被强制解决：要么提PR给社区，要么fork-replace。
图3-4. 胜利加载 3.3 不统一的Go版本fatal error: runtime: no plugin module data除了下面的那些问题以外，还有一个在多机器别离编译主程/插件场景下的常见报错。这个报错的一个可能起因是Go版本不统一，对齐它们即可。（如果从机器层面就是不能对齐怎么办？）
图3-5. Go版本不统一导致的加载失败 对立解决方案从3.1到3.3，咱们看了一些很难排查，也不是很好解决的问题。除此之外，其实还有一些问题没有被重点介绍进来。作为一个编程语言官网反对的扩大机制，做的如此用户不敌对的确出乎意料。我所在的团队因为重点依赖Go的插件机制做定开，因而必须拿出一个系统化的计划把这些问题通通解决掉。在尝试间接批改Go源码无果当前（吐槽：Go插件机制源码写的令人略感遗憾），我重点从以下几个方面动手发展了相干工作：对立编译环境：提供一个规范的docker image用来编译主程序和插件，躲避任何go版本、gopath门路、用户名等不统一所带来的问题预制go/pkg/mod，尽可能减少因为没有应用vendor模式导致每次编译都要从新下载依赖的问题对立Makefile：提供一套主程序和插件的编译Makefile，躲避任何因为go build命令带来的问题对立插件开发脚手架：由脚手架，而不是开发者拉齐插件与主程序的依赖版本。并由脚手架解决其余相干问题ACI化：将编译流程aci化，进一步避免出现谬误
图4-1. 对立解决方案 至此，对于Go插件的常见问题及解决办法介绍就暂告段落了，心愿对你有所帮忙。Bonus如果真的想从根本上搞清楚插件校验的机制，那这里为你提供一些疾速进入源码浏览状态的入口。我应用的Go源码为1.15.2版本。相干Go源码地位：compilergo/src/cmd/compile/linkergo/src/cmd/link/internal/ld/package loadergo/src/cmd/go/internal/load/runtimego/src/runtime/5.1 go build到底在做啥你能够在go build 命令里增加-x 参数，以显式的打印出Go程序编译、链接、打包的全流程，例如：go build -x -buildmode=plugin -o ../calc_plugin.so calc_plugin.go5.2 指标代码生成go/src/cmd/compile/internal/gc/obj.go:55 ：留神第67和第72行，这里是两个入口go/src/cmd/compile/internal/gc/iexport.go:244 ：留神280行，这里会记录path相干数据5.3 库哈希生成算法go/src/cmd/link/internal/ld/lib.go:967 ：留神第995～1025行，这里计算pkg的hash5.4 库哈希校验go/src/runtime/symtab.go:392 ：要害数据结构go/src/runtime/plugin.go:52 ：链接期hash与运行时hash值校验点go/src/cmd/link/internal/ld/symtab.go:621 ：链接期hash赋值点go/src/cmd/link/internal/ld/symtab.go:521 ：运行时hash赋值点 开发者评测局第五期——函数计算Serverless评测征集令 开发者评测局上新啦，第五期评测函数计算Serverless江湖征集令来袭，全新玩法，权利降级，价值千元高级版产品乘风者收费限量专享。群雄争霸夺好礼，Beats耳机、机械键盘、千元天猫超市卡等好礼等你来拿，公布你的评测成为江湖新“一代宗师”。点击这里，查看详情。原文链接:http://click.aliyun.com/m/100...本文为阿里云原创内容，未经容许不得转载。