「跨链网关的模块化进程」插件机制演化

—— 背景 ——

当前，区块链跨链平台的接入方式在架构设计上存在着较大差异，如何将应用链快速、便捷地接入跨链系统是一个亟待解决的问题。趣链 BitXHub 跨链服务平台采用中继链+网关的跨链方案，其中，跨链网关担任着区块链间收集和传播交易的角色。采用插件机制的设计将网关（Pier）与应用链交互的模块与跨链网关核心功能模块进行解耦，从而实现不同种类应用链高效地接入跨链系统。在 Pier 运行时，通过动态加载插件的方式完成不同应用链的灵活适配。为了更好的提升 Pier 与应用链的交互能力，具体应用链插件需要根据不同区块链的特性实现具体的接口，交互接口需要满足以下几个功能：

1）监听应用链上的跨链事件并传给核心模块进行处理；

2）执行来自于网关发出（来自于其他应用链）的跨链请求；

3）能够主动查询应用链上已收到和已执行的跨链请求状态。

在插件实现方案的设计中，我们先后采用了两种不同的插件机制，下面就来介绍一下我们使用原生插件时碰到的问题以及新插件方案的优势。

—— 原生插件——

go 语言从 1.13 版本开始支持编译为插件，使用方式如下：

go 项目在编译时可以通过 --buildmode 指定为插件模式，这种方式将输出为动态链接文件。该文件并非可直接运行的二进制文件，而是提供给其他二进制运行时的动态调用。

在主二进制文件中的使用方式如下：

总结来说原生插件具有以下特点：

优点：

1） 使用体验和原生代码一致，类似于代码模块的二进制化；

2） 效率较高，插件直接在主程序进程空间中运行。

缺点：

1）原生插件中的依赖库与主程序必须保持完全一致，否则启动的时候会报错，而且不论这个依赖是直接引用还是间接引用，都会出现这个问题。

—— 转战 RPC 插件——

原生插件中严厉的版本限制，使得在升级插件和或网关主程序功能时，可能因为无意升级了主程序某些依赖，插件也必须作出相同的适配升级。这种方式不利于插件的完全解耦，因此我们转向了另外一个使用 RPC 方式的 GO 插件项目。（该项目 GitHub 地址：https://github.com/hashicorp/go-plugin）

在 GO 原生支持的插件机制出现之前，hashicorp 的 go-plugin 就已经存在，不过 GO 原生插件出来之后，他们也并没有放弃对该项目的支持，因为总的来说原生插件并不是很完善，在某些场景下还是 go-plugin 更方便。

go-plugin 插件的使用方式如下：

简单来说，go-plugin 项目实现的插件方式采用了 C/S 模式，主程序作为 RPC Client，具体插件作为 RPC Server，Server 和 Client 通信也是基于的 interface 接口规范来通信。

具体使用流程如下：

1）抽象需要插件化的 interface，这里直接复用原生插件中使用的接口定义即可；

2）针对 Client 端和 Server 端，都实现上述接口。Server 端的实现是具体的插件处理逻辑部分的代码；Client 端的实现只需封装一下 gRPC 处理的结果和异常信息，之后便可以做到主程序在使用插件时对于 gRPC 的弱感知化。

Server 实现部分：

Client 实现部分：

▲额外需要注意的是：

• 插件中需要调用 plugin.Serve 来授权主程序使用自己的 RPC 服务。这里需要注意的是，主程序和插件通信前需要进行握手，主要包括确认该插件的版本信息。

• 主程序使用 plugin.Client 对象启动插件，该插件是运行在另一个进程中的，所以插件崩溃并不会影响到主程序。

• client 与 server 在使用中实际上是通过进程间 Socket 来完成通信，这虽然牺牲了一定的性能却换来了原生插件的单进程方案所不具备的依赖解耦､多语言支持等灵活应用。

—— 结语——

go-plugin 提供两种通信方式的选择，一种是 GRPC，一种是 GO 语言标准库中自带的 net/rpc 。GRPC 插件的好处是可以采用不同的语言来实现，并且 Google protobuf 也是支持多语言的。网关插件本质上已成为连接应用链并实现对网关提供 RPC 服务的桥梁，开发者在跨语言编写插件时的阻碍会大大降低，在面对不同应用链特性时也能做到更加可靠与简洁的逻辑呈现。跨链技术感兴趣的小伙伴，添加小助手桔子（18458407117）加入技术交流群，共论区块链的无限未来～

作者简介

王荻矣 

趣链科技数据网格实验室 BitXHub 团队