1. Hi区块链首页
  2. 资讯
  3. 竞争币

源码解读:EOS.IO中的插件布局

目的: 技术小白如果不小心打开了本文,直接拖到最后看总结即可 本文的阅读对象是对EOS源码感兴趣的同学 通过本文,你会掌握阅读每一个插件的步骤

之前我们通过5行代码对eosiod的脉络有了大致的了解,我们知道了它是一个插件化的服务,插件化服务的特点是可以像USB一样即插即用,有着很高的灵活性。今天我们更深入一点,来看下EOS服务的插件是如何布局的,以及如何阅读每一个插件的代码。

EOS.IO的每个插件,在生命期内都会经历以下阶段

  1. 插件注册
  2. 插件初始化
  3. 插件启动

下面我们一一道来。

插件注册

还记得上次我们说过的最后一行代码吗?

源码解读:EOS.IO中的插件布局

这行代码会把不同的插件注册到管理插件的插件容器中,刚开始,不是所有插件都会主动把自己注册到系统中,我们来看下在初始状态下,有哪些插件会主动注册自己,如下图:

源码解读:EOS.IO中的插件布局

可以看到,插件的命名很清晰,通过命名就可以判断不同插件所具备的能力。例如producer_plugin肯定是和出块节点相关的插件。

解决插件依赖

上一篇文章中,由于篇幅原因,我们跳过了注册过程中的一行代码:

plug->register_dependencies();

从字面来看,的作用是注册所依赖插件,今天我们就从这行代码开始,它的实现如下所示:

源码解读:EOS.IO中的插件布局

它会调用每个插件的plugin_requires函数,但诡异的是,没有任何一个插件有这个函数的实现,通过搜索发现,这个函数是由一个宏来定义的:

源码解读:EOS.IO中的插件布局

猜想只要插件类中包含了APPBASE_PLUGIN_REQUIRES宏,即是定义了plugin_requires函数,再查看不同插件中的头文件,果不其然,注册到系统中的插件都包含了该宏,下面是3个不同插件的例子

源码解读:EOS.IO中的插件布局

你一定发现了其中的差异,每个插件的参数是不同的,这是什么情况?此时就得看plugin_requires的具体的实现了

源码解读:EOS.IO中的插件布局

plugin_requires函数会调用boost库中的一个宏——BOOST_PP_SEQ_FOR_EACH,该宏的用法参见http://t.cn/REqJmyG。

在本例子中,意为对于PLUGINS中的每一个PLUGIN,都调用一次register_plugin<PLUGIN>();,如上图所示。以net_api_plugin这个插件为例,下面是该插件的展开式

源码解读:EOS.IO中的插件布局

清楚了吧,可以看到展开后,对所依赖的每个插件,会继续调用register_plugin,形成了递归效果,直到遇到独立的插件为止,例如上面的chain_plugin就是一个独立的插件。

翻译为白话就是

在注册一个插件之间,先把该插件所依赖的其他插件注册到系统中。且无论依赖多少个插件,你只需要写一行代码。

在我看来,这样的写法是非常优雅的,设计上可以用精妙来形容,此时,系统中的插件布局变成了这样:

源码解读:EOS.IO中的插件布局

至此,插件的注册部分就全部完成了,你可能已经发现了,上述插件有重复注册的情况,但不用担心,register_plugin函数的实现会避免该情况的发生,如下:

源码解读:EOS.IO中的插件布局

插件初始化

注册完插件后,下一步就需要对这些插件初始化,我们回到之前介绍的「第1行」代码,该代码的调用次序由上至下如下图所示,

源码解读:EOS.IO中的插件布局

可以看到初始化是由initialize_impl这个函数实现的,这个函数接收命令行选项,和3个自动启动的插件作为参数——chain_pluginhttp_pluginnet_plugin(我用白色的下划线做了标记)。

initialize_impl做了2件事情:

  1. 获取配置信息,包括命令行选项和配置文件中的参数
  2. 初始化插件

获取配置信息这件事,EOS.IO也借助了boost库,对于该知识的说明,你可以参考这篇文章:http://sina.lt/fpBy。

值得说明的事,为了产生不同插件的特定配置项,每个插件都实现了set_program_options函数,以http_plugin为例

源码解读:EOS.IO中的插件布局

上面代码为http_plugin提供了外部参数http-server-address,该参数既可以通过命令行获取(由plugin_cli_optsplugin_cfg_opts两个变量控制),又可以通过配置文件获取(由plugin_cfg_opts控制),于是,当你在命令行输入eosiod --help时,会输出以下信息

源码解读:EOS.IO中的插件布局

所有的参数信息最终会存储在options这个变量中,然后在初始化时,传入不同的插件

源码解读:EOS.IO中的插件布局

配置信息获取成功后,就该对插件进行初始化了,需要对哪些插件初始化呢,来自3个途径:

  1. 上文提到的自动启动的插件
  2. 配置文件中描述的插件
  3. 1和2所依赖的插件

第1个途径上面已经介绍了,现在看下第2个途径包含哪些插件,打开config.ini文件,可以看到以下插件列表

源码解读:EOS.IO中的插件布局

最后,我们再看下系统是如何初始化依赖插件的,在initialize_impl函数中,上述2个途径的插件初始化都会调用initialize这个函数,这个函数的实现如下所示

源码解读:EOS.IO中的插件布局

进入initialize函数,你发现了什么,plugin_requires这个函数是不是非常熟悉?没错,上文已经花了大量的篇幅来解释这个函数,但在初始化场景下有什么不同呢?细心的你应该发现了,差异在于Lambda表达式上,我们再次拿chain_api_plugin这个插件举例,尝试对其进行展开

源码解读:EOS.IO中的插件布局

看出变化了吧,意思是

如果这个插件依赖其他插件,则先对其依赖的插件调用initialize,这些插件如果还依赖另外的插件,则先对另外的插件调用initialize,依此递归下去……直到遇到独立插件为止

待「依赖链」全部初始化完成后,该插件才会调用plugin_initialize对自己初始化,同样,不同插件实现了不同的初始化方式。于是,插件的布局及初始化部分就已经完成了。

不难发现,插件的启动也是通过这种方式完成的,这一部分我就不展开了,留给你作为作业吧:)

总结

本文主要分析了EOS.IO这个开源软件的插件布局,包括了插件在系统中的生命周期,同时我们也学习了一个非常Tricky的解依赖的编码技巧,当我第一次看到这样的实现时,我是这样感叹的:

eos里插件的设计都是链式的,太BT了

敲黑板了,通过以上内容,你在今后学习每个插件时,其实只需记住3个函数即可,它们是每个插件中的

  1. `set_program_options`:用来设置插件的参数
  2. `plugin_initialize`:实现了插件具体的初始化过程
  3. `plugin_startup`:运行插件

免责声明:以上所有代码分析和对代码的感受,都不构成任何投资建议,谢谢

声明:登载此文出于传递更多信息之目的,观点仅代表作者本人,绝不代表Hi区块链赞同其观点或证实其描述。

提示:投资有风险,入市须谨慎。本资讯不作为投资理财建议。