文|丁飞（花名：路德 )
蚂蚁团体高级工程师
深耕于 SOFAMesh 产品的商业化落地 次要方向为基于服务网格技术的零碎架构降级方案设计与落地
本文 4394 字 浏览 10 分钟
|前言|
MOSN 作为蚂蚁团体在 ServiceMesh 解决方案中的数据面组件，从设计之初就思考到了第三方的扩大开发需要。目前，MOSN 反对通过 gRPC、WASM、以及 Go 原生插件三种机制对其进行扩大。
我在主导设计和落地基于 Go 原生插件机制的扩大能力时遇到了很多问题，鉴于这方面的相干材料很少，因此就有了这个想法来做一个十分浅显的总结，心愿能对大家有所帮忙。
注：本文只说问题和解决方案，不读代码，文章最初会给出外围源码的 checklist。
PART. 1– 文章技术背景
一、运行时
通常而言，在计算机编程语言畛域，“运行时”的概念和一些须要应用到 VM 的语言相干。程序的运行由两个局部组成：指标代码和“虚拟机”。比方最为典型的 JAVA，即 Java Class + JRE。
对于一些看似不须要“虚拟机”的编程语言，就不太会有“运行时”的概念，程序的运行只须要一个局部，即指标代码。但事实上，即便是 C/C++，也有“运行时”，即它所运行平台的 OS/Lib。
Go 也是一样，因为运行 Go 程序不须要前置部署相似于 JRE 的“运行时”，所以它看起来仿佛跟“虚拟机”或者“运行时”没啥关系。但事实上，Go 语言的“运行时”被编译器编译成了二进制指标代码的一部分。
图 1-1. Java 程序、runtime 和 OS 关系
图 1-2. C/C++ 程序、runtime 和 OS 关系
图 1-3. Go 程序、runtime 和 OS 关系
二、Go 原生插件机制
作为一个看起来更贴近 C/C++ 技术栈的 Go 语言来说，反对相似动态链接库的扩大始终是社区中较为强烈的诉求。
如图 1-5，Go 在规范库中专门提供了一个 plugin 包，作为插件的语言级编程界面，src/plugin 包的实质是 应用 cgo 机制调用 unix 的标准接口：dlopen() 和 dlsym()。因而，它给 C/C++ 背景的程序员一种“这题我会”的错觉。
图 1-4. C/C++ 程序加载动态链接库
图 1-5. Go 程序加载动态链接库
PART. 2– 典型问题解决
很遗憾，与 C/C++ 技术栈相比，Go 的插件的产出物尽管也是一个动态链接库文件，但它对于插件的开发、应用有一系列很简单的内置束缚。更令人头大的是，Go 语言岂但没有对这些束缚进行系统性的介绍，甚至写了一些比拟差的设计和实现，导致插件相干问题的排错十分反人类。
本章节重点跟大家一起看下，在开发、应用 Go 插件，次要是编译、加载插件的时候，最常见、但必须定位到 Go 规范库 （次要包含编译器、链接器、打包器和运行时局部） 源码能力齐全弄明确的几个问题，及对应的解决办法。
简而言之，Go 的主程序在加载 plugin 时，会在“runtime”里对两者进行一堆束缚查看，包含但不限于：
– go version 统一
– go path 统一
– go dependency 的交加统一
- 代码统一
- path 统一
– go build 某些 flag 统一
一、不统一的规范库版本
主程序加载插件时报错：
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 命令按上面的例子组装好：
留神，goland 组装的编译命令里蕴含要害的
-gcflags all=-N -l 参数，然而插件编译的命令里没有。此时，你在尝试拉起插件时就会失去一个无关 runtime/internal/sys 的报错。
图 2-1. 编译 flag 不统一导致的加载失败
解决这一类规范库版本不统一问题的计划比较简单：尽可能对齐主程序和插件编译的 flag。事实上，有一些 flag 是不影响插件加载的，你能够在具体的实际中缓缓摸索。
二、不统一的第三方库版本
如果应用 vendor 来治理 Go 的依赖库，那么当解决上一节的问题之后，你 100% 会立刻遇到以下这个报错：
plugin was built with a different version of package xxxxxxxx
其中，xxxxxxxx 指的是某一个具体的三方库，比方 github.com/stretchr/testify。这个报错有几个十分典型的起因，如果没有相干的排查教训，其中几个可能会烧掉开发人员不少工夫。
Case 1. 版本不统一
如报错所示，仿佛起因很明确，即 主程序和插件所独特依赖的某个第三方库版本不统一 ，报错中会明确通知你哪一个库有问题。此时，你能够比照排查主程序和插件的 go.mod 文件，别离找到问题库的版本，看看他们是否统一。如果这时候你发现主程和插件的确有 commitid 或 tag 的不统一问题，那解决的办法也很简略： 对齐它们。
然而在很多场景下，你只会用到三方库的一部分：如一个 package，或者只是引了某些 interface。这一部分的代码在不同的版本里可能基本就没有变更，但其余没用到的代码的变更，同样会导致整个三方库版本的变更，进而导致你成为那个“版本不统一”的无辜受害者。
而且，此时你可能立刻会遇到另一个问题：以谁为基准对齐？主程序？还是插件？
从常理上来说，以主程序为基线进行对齐是一个比拟好的策略，毕竟插件是新增加的“附属品”，且主程序与插件通常是“一对多”的关系。然而，如果插件的三方库依赖因为任何起因就是不能和主程序对齐怎么办？在尝试了很久当前，我临时没有找到一个完满解决这个问题的方法。
如果版本无奈对齐，就只能从根本上放弃走插件这条路。
Go 语言的这种对三方库的、简直无脑的强一致性束缚，从一方面来说，防止了运行时因为版本不统一带来的潜在问题；从另一方面来说，这种刻意不给程序员灵便度的设计，对插件化、定制化、扩大化开发十分的不敌对。
图 2-2. 独特依赖的三方库版本不统一导致的加载失败
Case 2. 版本号统一，代码不统一
当你依照 case 1 的思路排查 go.mod 文件，然而诧异的发现报错的库版本是统一的时候，事件就会变得复杂起来。你可能会拿出世界上最先进的文本查验工具，并花掉一个上午去 diff 三方库的 commitid，但它们就是截然不同，仿佛陷入了薛定谔的版本。
呈现这个问题可能的一个不是起因的起因是：有人间接批改了 vendor 目录下的代码，Go 插件机制会对代码内容的一致性进行校验。
这真的是一个十分令人头大，并难以排查的起因。除了批改代码的那个人，和曾经在其余 case 中被“坑”过的那些人，没人会晓得这件事件。如果批改的 vendor 代码呈现在主程序里，你就简直没有任何靠谱的方法让它们失常工作起来。
不要间接在 vendor 里改代码！！！
不要间接在 vendor 里改代码！！！
不要间接在 vendor 里改代码！！！
回馈开源社区，或者 fork-replace！！！
好消息是，你不须要解决这个问题。因为即便解决了，也还会有更大的问题等着你。
图 2-3. 独特依赖的三方库代码被就地批改导致的加载失败
Case 3. 门路不统一
当依照 case 1 和 case 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。
图 2-4. 应用 vendor 机制治理第三方库导致的加载失败
同样的问题也可能会呈现在应用不同机器 / 用户，别离编译主程序、插件的场景下：用户名不同，go 代码的门路应该也会不一样。
解决这类问题的办法很暴力间接：删掉主程序和插件的 vendor 目录，或者应用 -mod=readonly 编译 flag。
到这里，如果你是应用同一台机器进行主程序和插件的编译，那么常见的问题应该都根本解决了，插件机制理当可能失常工作。另一方面，因为不再应用 vendor 治理依赖，因而 case 2 的问题也会在这里被强制解决：要么提 PR 给社区，要么 fork-replace。
图 2-5. 胜利加载
三、不统一的 Go 版本
fatal error: runtime: no plugin module data
除了下面的那些问题以外，还有一个在多机器别离编译主程 / 插件场景下的常见报错。这个报错的一个可能起因是 Go 版本不统一，对齐它们即可。（如果从机器层面就是不能对齐怎么办？……）
图 2-6. Go 版本不统一导致的加载失败
PART. 3– 对立解决方案
从第二 Part 中，咱们看了一些既很难排查，也不是很好解决的问题。除此之外，其实还有一些问题没有被重点介绍进来。作为一个编程语言官网反对的扩大机制，做的如此用户不敌对的确出乎意料。
因为「专有云 MOSN」重点依赖 Go 的插件机制做定开，因而必须拿出一个系统化的计划把这些问题通通解决掉。在尝试间接批改 Go 源码无果当前 （吐槽：Go 插件机制源码写的令人略感遗憾），咱们重点从“产品层”及外围基础设施动手发展了相干工作：
– 对立编译环境：
- 提供一个规范的 docker image 用来编译主程序和插件，躲避任何 go 版本、gopath 门路、用户名等不统一所带来的问题；
- 预制 go/pkg/mod，尽可能减少因为没有应用 vendor 模式导致每次编译都要从新下载依赖的问题。
– 对立 Makefile：
- 提供一套主程序和插件的编译 Makefile，躲避任何因为 go build 命令带来的问题。
– 对立插件开发脚手架：
- 由脚手架，而不是开发者拉齐插件与主程序的依赖版本。并由脚手架解决其余相干问题。
– 流水线化：
- 将编译部署流水线化，进一步避免出现谬误。
图 3-1. 对立解决方案
PART. 4– 要害源码地位
如果真的想从根本上搞清楚插件校验的机制，那这里为你提供一些疾速进入源码浏览状态的入口。我应用的 Go 源码为 1.15.2 版本。相干 Go 源码地位：
– compiler：go/src/cmd/compile/*
– linker：go/src/cmd/link/internal/ld/*
– pkg loader：go/src/cmd/go/internal/load/*
– runtime：go/src/runtime/*
一、go build 到底在做啥
你能够在 go build 命令里增加 -x 参数，以显式的打印出 Go 程序编译、链接、打包的全流程，例如：
go build -x -buildmode=plugin -o ../calc_plugin.so calc_plugin.go
二、指标代码生成
go/src/cmd/compile/internal/gc/obj.go:55：留神第 67 和第 72 行，这里是两个入口；
go/src/cmd/compile/internal/gc/iexport.go:244：留神 280 行，这里会记录 path 相干数据。
三、库哈希生成算法
go/src/cmd/link/internal/ld/lib.go:967：留神第 995-1025 行，这里计算 pkg 的 hash。
四、库哈希校验
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 赋值点。
PART. 5– 总结
能够看到，即便 Go 的原生插件机制有各种各样令人头痛的问题，SOFAStack 团队仍旧秉持“开源、凋谢、可扩大”的初衷，通过各种伎俩解决问题，并最终将此能力做到生产可用。
目前，专有云 MOSN 的协定编解码器和 logger 的定制化开发曾经实现全面的插件化。接下来，咱们将继续对 MOSN 架构进行降级，指标对包含路由逻辑、LB 逻辑、注册核心 / 配置核心对接等在内的多方面能力进行插件化反对。
理解更多……
MOSN Star 一下✨： https://github.com/mosn/mosn
点击浏览原文，和咱们一起共建吧🧸
本周举荐浏览
MOSN 构建 Subset 优化思路分享
MOSN 文档使用指南
MOSN 1.0 公布，开启新架构演进
MOSN Contributor 采访|开源能够是做力不从心的事
欢送关注：