道招

对微内核的一点执念

如果您发现本文排版有问题,可以先点击下面的链接切换至老版进行查看!!!

对微内核的一点执念

自从知道了这个名词,咋一听觉得很神秘的,等看了网上的例子才发现其实没有那么高不可攀,等对自己周围主要产品的深入了解后发现这个思想原来在我们的周围很常见的,比如webpack,nginx等。 之前还写过一篇《以webpack为例来看微内核架构》 微内核系统一般分为两个部分——核心系统和插件系统,核心系统通过注册表感知插件信息。

在了解了几个微内核系统后,觉得很实用,很自然的就有想将这套理念运用到自己的项目中的想法,比如自己的web项目当中,但是按照自己的理解感觉这样可能并不可行,或者说就算强行实现的话可能也不纯粹。其中一个问题就是注册表怎么弄?微内核系统一般都是这样的,有个配置文件,除了配置系统参数外还会配置准备使用的插件,然后有一个“编译”过程,这个过程会读取配置文件,然后生成注册表,也就是说后续哪些插件可用在“编译后”就已经定型了。我们常规的web项目在运行时就已经是打包之后的,而哪些插件是否可用在当时打包时并不知道。要么就是我们推迟注册表的实现,具体怎么说呢? 我们可以认为所有的插件都可用,但是不同用户的插件的差异性怎么体现呢?我们可以在进入web项目后就读取自己的配置,一般可能调用后台接口来获取不同用户的不同权限、插件信息,这种方式有些弊端:

  1. 实现不同用户操作行为时功能的差异性需要程序员根据写代码时自觉完成隔离。
  2. 想让插件间相互依赖比较困难,我们不太好有个遍历所需插件的过程。

我一直是想自己开发一个简易的微内核系统,个人认为只有自己开发一个才能更深刻的理解微内核的精髓。 比如做一个app,然后有一个插件市场,在里面可以选择安装各种插件,安装后就可以实现对应的功能,也可以尝试插件中的相互依赖使用,比如有一个订单系统,一个支付系统和一个通知系统,当启用了通知系统后,订单系统和支付系统的通知就可以通过通知系统来通知了,否则就走各个系统自己的通知流程。

上面只是自己想法的一部分,后面的后续会继续完善。

更新时间:
上一篇:下一篇:

相关文章

关注道招网公众帐号
道招开发者二群