golang插件化方案

Posted 2021-04-25 Golang语言社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了golang插件化方案相关的知识，希望对你有一定的参考价值。

1. 背景

业务线的活动，每一次新活动都做独立项目开发，有大量重复代码，并且浪费数据服务的连接资源；排序服务也许要经常添加业务代码，目前是停服务发布……这些场景为了开发维护效率、稳定性、安全性和性能都使用了Go语言。Go是静态编译语言，在具体的动态场景该如何实现应用级别的持续交付呢？

基于k8s，nginx网关，队列回溯消费等工具的实现也可以实现不同程度的持续交付，但是持续交付的要求越高，搭建平台和维护的成本也越高。

从应用开发本身出发，可以考虑插件化。

插件使用场景特点

可以热更新式扩展应用程序的功能列表
应对多变的业务需求，方便功能上下线
对于任意的go应用，能进行增量架构、代码分发以及代码上下线

插件设计标准

性能：调用插件要尽可能的快；对于任务插件，使用单独的工作空间（协程、线程、进程的池子化处理），大的、慢的、长期运行的插件，要少调用
稳定性：插件依赖的发布平台要少发布，交互API的设计要做好抽象，上下文的环境变量非必须不添加，减少升级需求，甚至能支持多个实例互备热升级
可靠性：如果有失效、崩溃的可能，必须有快速、简单、完整的恢复机制；业务插件的执行不能影响依赖的发布平台的守护进程或者线程的稳定
安全性：应该通过代码签名之类的手段防篡改
扩展性：支持插件热更新和上下线，下线需要健康检查，公共库插件至少能热加载
复用性：业务插件不要太多一次性的上下线
易用性：提供使用简单、功能正交的API，业务插件能够获取依赖的发布平台的上下文和调用公共库

2. Go的插件方式

动态链接库plugin，官方文档

语言本身支持，插件和主程序原生语法交互

进程隔离：无，单进程
主程序调用插件：一切预协定object（包括function、channel）
插件感知主程序上下文：主程序预定义类型参数object（包括function、channel）
stream支持：单向，基于channel
插件发现：主程序循环扫描插件目录并维护状态；通过第三方文件diff工具维护，例如git
上线：能
下线：不能
更新：不能
通信：进程内
序列化：不需要
性能：高

Go plugin判断两个插件是否相同是通过比较pluginpath实现的，如果没有指定pluginpath，则由内部的算法生成, 生成的格式为plugin/unnamed-“ + root.Package.Internal.BuildID 。这种情况下，如果两个插件的文件名不同，引用包不同，或者引用的cgo不同，则会生成不同的插件，同时加载不会有问题。但是如果两个插件的文件名相同，相关的引用包也相同，则可能生成相同的插件，即使插件内包含的方法和变量不同，实现也不同。判断插件相同，热加载不会成功，也就意味着老插件不支持覆盖更新。

最好在编译的指定pluginpath，同时方便版本跟踪。目前生产环境建议一些公共库无服务依赖的函数，例如算法库之类的。

1go build -ldflags "-pluginpath=plugin/hot-$(date +%s)" -buildmode=plugin -o so/Eng.so eng/greeter.go

通信+序列化

natefinch/pie，github仓库

进程隔离：有，多进程，provider+comsumer
主程序调用插件：provider模式调用插件进程中预协定method；consumer模式消费插件进程中的预协定参数object（包括function、除了channel）
插件感知主程序上下文：provider模式消费主程序的预定义参数object（包括function、除了channel）；consumer模式调用主程序中预定义method
stream支持：不支持
插件发现：主程序循环扫描插件目录并维护状态；通过第三方文件diff工具维护，例如git
上线：能
下线：能
更新：能
通信：支持stdin/stdout、pipe、unix socket、tcp、http、jsonrpc
序列化：gob，protobuf, json, xml
性能：中/偏高

基于Go的net/rpc库，无法支持主程序和插件之间的streaming数据交互，有golang的官方包[issue1]和[issue2]直接建议。另外，每一个插件都要开一个进程，因此要注意通信序列化的性能消耗和进程管理，默认使用stdin/stdout建立连接，如下图，一个plugin和主程序之间有两条单向连接。

可以上成产环境，要做好资源管理。