插件式架构设计

插件式的架构设计简单来说就是将一套系统中的算法和功能不同而接口相同的同类事物抽象为插件的一种架构设计方式。我更将其看作是策略模式在整个系统的应用,如果采用微服务架构,插件也可以理解为微服务中的微单元。甚至于微服务架构也可以理解为一定程度上的插件设计,微服务作为大系统的插件而存在。

我最初使用这种方式是在工作第一年,当时参与公司产品重新架构,使用C编写程序,利用C语言的动态库动态加载能力,我们实现了不同厂家设备的动态支持和适配。当时还没有这样的架构名称,我在后来的使用中,不断提炼核心思想,姑且将其命名为插件式架构设计。

插件式架构设计的抽象设计如图所示:

主要给出了基于插件体系的一系列相关层,这里进行说明:

插件抽象层是插件的抽象接口,尽可能做到好的通用性,这样有利于作为一种特征加入项目,比如项目A需要插件特性,只需要将插件抽象层的代码拷贝到对应的项目即可。减少不必要的重复工作。插件管理器可以采用各种手段实现,如注册式或者监听式,注册式开放注册和注销接口,通过接口动态注册插件和插件实例,监听式可以监听某个目录,当有插件文件加入时加载插件,当有插件实例文件加入时,创建插件实例。插件更可能作为插件实例的工厂而存在,这样可以基于插件创建插件实例。

插件实现层是对插件抽象层的实现,用来对接具体功能和业务逻辑,如物联网网关,可以将驱动作为插件,将实际设备作为插件实例,又比如一个支持多种网络服务器的平台可以将不同网络协议的服务器作为插件,而具体的服务器实例作为插件实例。

插件使用层很简单,就是使用插件组织业务逻辑的地方,如果是Web应用,可以是service层,如果是MVC架构的客户端,可以是C层。

表示层提供系统的表示方式,如页面,API等。

插件式的架构设计目前使用来看,主要有以下优点:

1. 主框架程序短小精悍,主要实现插件的管理和动态加载,开放表示层。插件动态配置,按需加载,整个系统的资源占用减少,功能结构更加紧凑;

2. 可以将复杂的未知需求和功能留待以后开发,缓解了未知问题的解决压力,例如物联网平台我们不知道有多少设备协议需要对接时,我们不必惊慌,见招拆招,来了新设备,编写新的插件,然后动态加入系统即可;

3. 实现系统组件的可插拔和系统的最小化配置,需要什么功能,我才添加对应的插件;

4. 开发者只需要关注插件如何编写,代码量和知识量明显减少,可以降低开发者技术水平要求,使得代码更易于维护,故障更容易恢复,对于公司,降低人力成本。

缺点主要有:

1. 插件接口层变动会影响到所有已有插件和主框架,前期需要一段时间的接口调试期,当接口稳定后,这个问题就会得到改善;

2. 开发者技术提升存在门槛,开发者很难看到系统全貌,对于肯学的人,可能会去看看框架实现,一些人可能只会停留在开发插件的水平,针对这个问题,可以采用轮岗维护制,插件主框架部分经常换人维护学习;

3. 调试和排查问题不太方便,对于主框架和插件的联调比较麻烦,尤其是线上问题排查,要尽可能多的提供日志记录;

实践中,任何允许运行时动态加载程序单元的编程语言,都可以使用插件式的架构设计,例如,C/C++有动态库动态加载,Java运行时动态加载jar包,golang的plugin包等。如果采用微服务架构,每个微服务推荐尽可能采用插件式的架构设计,这样可以保证每个服务更新负担进一步减小,一定程度上降低微服务的维护成本。

文末引用《道德经》一句话

万物之始,大道至简,衍化至繁

 

  • 2
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值