插件管理器:四层境界,多数只在第三层

但大部分人搭到第三层就停了：能加载、能通信，然后每个插件开一个线程。插件一多，线程数就失控。

单机服务中最常用的扩展框架：插件结构，也是模块化的重要形式。

先分清插件和组件的概念。插件和组件在物理形态上都是共享库。插件是强调根据配置插拔，动态加载卸载。组件是业务依赖复用的公共库。

插件的实现有几个必要的点：

1、插件需要有插件管理器，负责根据配置等加载插件，保存插件的实例。插件本质上使用动态库的动态加载卸载功能。

真正的可扩展模式，是把变化交给数据。

2、插件需要有统一的契约接口，简单点有 init、run、uninit。常用于插件之间独立运行，互不通信。插件管理器加载后依次调用 init、run、最后 uninit。

当然插件接口要符合 ABI ——我的c++洁癖19：二进制边界使用纯 c 和 POD。

3、插件需要消息总线。前面两条可以实现简单的插件功能。复杂一点如果想要通信，插件的契约接口可以增加发送消息接口 sendMsg。

简单的方式插件 A 直接 sendMsg(B, msg1) 发给插件 B，这种方式 A 直接耦合 B。

解耦就用订阅发布方式：插件 B 注册消息接口 registerMsg(msg1) 的消息，插件 A 只管 sendMsg(msg1)，并不知道插件 B 的存在。插件之间只注册自己可以处理的消息，并不耦合其他插件。

想通信就发对应消息到总线上，有人注册就转给对应的插件，没人注册就拉倒。

这就引出了：消息总线。可以使用插件管理器充当总线功能，不必专门另写。

插件通信，每个插件都需要线程进行事件循环。

4、插件多了，避免线程膨胀。前面三点已经有了稍微复杂的插件间可通信的插件框架。但是如果每个插件都有自己的线程进行事件循环，那么插件多了，线程就多了。

这时理想的插件框架就是：不论插件多少，线程数量不变。就需要二级队列 + 线程池。

线程模型：从每任务一线程到二级队列线程池。

插件框架可简单可复杂。主要看项目业务采用不同复杂度的实现。

你的插件框架在第几层？第三层，还是已经做成第四层了？评论区说说，我看看能不能一起解。