EOS.IO中的插件布局 | 源码解读
目的：
技术小白如果不小心打开了本文，直接拖到最后看总结即可
本文的阅读对象是对EOS源码感兴趣的同学
通过本文，你会掌握阅读每一个插件的步骤
之前我们通过5行代码对eosiod的脉络有了大致的了解，我们知道了它是一个插件化的服务，插件化服务的特点是可以像USB一样即插即用，有着很高的灵活性。今天我们更深入一点，来看下EOS服务的插件是如何布局的，以及如何阅读每一个插件的代码。
EOS.IO的每个插件，在生命期内都会经历以下阶段
插件注册
插件初始化
插件启动
下面我们一一道来。
插件注册
还记得上次我们说过的最后一行代码吗？
这行代码会把不同的插件注册到管理插件的插件容器中，刚开始，不是所有插件都会主动把自己注册到系统中，我们来看下在初始状态下，有哪些插件会主动注册自己，如下图：
可以看到，插件的命名很清晰，通过命名就可以判断不同插件所具备的能力。例如producer_plugin肯定是和出块节点相关的插件。
解决插件依赖
在上一篇文章中，由于篇幅原因，我们跳过了注册过程中的一行代码：
plug->register_dependencies();
从字面来看，的作用是注册所依赖插件，今天我们就从这行代码开始，它的实现如下所示：
它会调用每个插件的plugin_requires函数，但诡异的是，没有任何一个插件有这个函数的实现，通过搜索发现，这个函数是由一个宏来定义的：
猜想只要插件类中包含了APPBASE_PLUGIN_REQUIRES宏，即是定义了plugin_requires函数，再查看不同插件中的头文件，果不其然，注册到系统中的插件都包含了该宏，下面是3个不同插件的例子
你一定发现了其中的差异，每个插件的参数是不同的，这是什么情况？此时就得看plugin_requires的具体的实现了
plugin_requires函数会调用boost库中的一个宏——BOOST_PP_SEQ_FOR_EACH，该宏的用法参见http://t.cn/REqJmyG。
在本例子中，意为对于PLUGINS中的每一个PLUGIN，都调用一次register_plugin，如上图所示。以net_api_plugin这个插件为例，下面是该插件的展开式
清楚了吧，可以看到展开后，对所依赖的每个插件，会继续调用register_plugin，形成了递归效果，直到遇到独立的插件为止，例如上面的chain_plugin就是一个独立的插件。
翻译为白话就是：
在注册一个插件之间，先把该插件所依赖的其他插件注册到系统中。且无论依赖多少个插件，你只需要写一行代码。
在我看来，这样的写法是非常优雅的，设计上可以用精妙来形容，此时，系统中的插件布局变成了这样：
至此，插件的注册部分就全部完成了，你可能已经发现了，上述插件有重复注册的情况，但不用担心，register_plugin函数的实现会避免该情况的发生，如下:
插件初始化
注册完插件后，下一步就需要对这些插件初始化，我们回到之前介绍的「第1行」代码，该代码的调用次序由上至下如下图所示，
可以看到初始化是由initialize_impl这个函数实现的，这个函数接收命令行选项，和3个自动启动的插件作为参数——chain_plugin、http_plugin和net_plugin（我用白色的下划线做了标记）。
initialize_impl做了2件事情：
获取配置信息，包括命令行选项和配置文件中的参数
初始化插件
获取配置信息这件事，EOS.IO也借助了boost库，对于该知识的说明，你可以参考这篇文章：http://sina.lt/fpBy。
值得说明的事，为了产生不同插件的特定配置项，每个插件都实现了set_program_options函数，以http_plugin为例
上面代码为http_plugin提供了外部参数http-server-address，该参数既可以通过命令行获取（由plugin_cli_opts和plugin_cfg_opts两个变量控制），又可以通过配置文件获取（由plugin_cfg_opts控制），于是，当你在命令行输入eosiod --help时，会输出以下信息
所有的参数信息最终会存储在options这个变量中，然后在初始化时，传入不同的插件
配置信息获取成功后，就该对插件进行初始化了，需要对哪些插件初始化呢，来自3个途径：
上文提到的自动启动的插件
配置文件中描述的插件
1和2所依赖的插件
第1个途径上面已经介绍了，现在看下第2个途径包含哪些插件，打开config.ini文件，可以看到以下插件列表
最后，我们再看下系统是如何初始化依赖插件的，在initialize_impl函数中，上述2个途径的插件初始化都会调用initialize这个函数，这个函数的实现如下所示
进入initialize函数，你发现了什么，plugin_requires这个函数是不是非常熟悉？没错，上文已经花了大量的篇幅来解释这个函数，但在初始化场景下有什么不同呢？细心的你应该发现了，差异在于Lambda表达式上，我们再次拿chain_api_plugin这个插件举例，尝试对其进行展开
看出变化了吧，意思是
如果这个插件依赖其他插件，则先对其依赖的插件调用
initialize，这些插件如果还依赖另外的插件，则先对另外的插件调用initialize，依此递归下去……直到遇到独立插件为止
待「依赖链」全部初始化完成后，该插件才会调用plugin_initialize对自己初始化，同样，不同插件实现了不同的初始化方式。于是，插件的布局及初始化部分就已经完成了。
不难发现，插件的启动也是通过这种方式完成的，这一部分我就不展开了，留给你作为作业吧：）
总结
本文主要分析了EOS.IO这个开源软件的插件布局，包括了插件在系统中的生命周期，同时我们也学习了一个非常Tricky的解依赖的编码技巧，当我第一次看到这样的实现时，我是这样感叹的：
eos里插件的设计都是链式的，太BT了
敲黑板了，通过以上内容，你在今后学习每个插件时，其实只需记住3个函数即可，它们是每个插件中的
set_program_options：用来设置插件的参数plugin_initialize：实现了插件具体的初始化过程plugin_startup：运行插件
免责声明：以上所有代码分析和对代码的感受，都不构成任何投资建议，谢谢