正在阅读:

轻量微服务库libmsf

1,023

一. 目的

更适应产品定制裁剪需求,降低耦合和依赖,增加代码复用, 便于问题调试定位,提高可维护性

二. 演变

下面都是根据个人理解整理而成,仅供参考

从功能模块的演变过程再来看,实现从模块化===> 组件化===> 插件化

三. 概要

针对模块化,组件化,插件话,微服务化概念做一个简单的分析

1.  模块化

模块化概念:

程序按照功能拆分成相互独立的模块,每个模块只包含与其功能相关的内容。

模块我们相对熟悉, 比如登录功能可以是一个模块, 搜索功能可以是个模块。

2.  组件化

组件化和模块化的区别: 

个人认为模块相对于组件的粒度较大,组件分的更细 , 一个模块可以由很多个组件构成 .

模块化粒度更小, 更侧重于重用, 而组件化粒度稍大于模块,  更侧重于业务解耦 .

组件化概念:

将一个大的软件系统按照分离关注点的形式,拆分成多个独立的组件,已较少耦合, 实现可重用。

开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等,但是最终发布的时候是将

这些组件合并成可执行程序包,这就是组件化开发

组件分类:

一类是application组件,application组件是一个可运行的app。

一类是libs组件,libs组件可以作为application的依赖,但是自身不可作为程序运行的存在。

组件化想要解决的问题:

1.      需求: 产品经理不能灵活的对工程进行需求配置和组装, 特别是需求变更。

2.     开发: 公共资源、业务、模块混在一起耦合度太高, 牵一发而动全身

3.     协调:  团队不能很好的协同并发开发, 影响开发效率.

4.     编译: 对工程所做的任何修改都必须要编译整个工程,耗时耗力

5.     测试: 功能测试和系统测试每次都要进行,测试资源浪费多

组件引入的问题:

组件开发比较常见的问题是业务组件的相互引用, 为此我们可以通过路由/总线的方式去处理.

挂载到组件总线上的业务组件 , 都可以实现双向通信.

组件路由机制:

实现方式有很多种,比如: dbus  rpc(xmlrpc  jsonrpc binary rpc ) restful 等等

下面是我个人实现的基于总线bus思想的进程间或者组件插件间通信机制。

https://github.com/wypx/libgipc

3.  插件化

插件化和组件化的区别:

开发思想: 插件化其实和组件化有点相似。

颗粒度: 个人认为插件化是组件化的一个进阶,两者功能服务细化颗粒度不同。

插件化概念:

在插件式的思想的指导下,系统所有功能都是插件。

比如组装机,所有硬件都有公共的插口,而机箱就是一个框架,组装硬盘、CPU、主板等到机箱.

这个案例中,CPU、主板、硬盘都是插件,他们都按照统一的接口即规范式的接口进行组合。

这些标准的接口就好比机箱这个公共框架下的既定的公共契约。

有了契约,我们才能把插件组装在一起,形成一个完成的系统。

当然,在这里可以我们采取多种方式,更有效的提高生产力----设计模式。

工厂模式(Factory Pattern)观察者模式

插件化的要解决的问题:

插件化具备组件化该有的功能优点,它将更加简洁,耦合度更低。

相对于组件化开发主要要解决的问题:

1.     宿主和插件分开编译

2.     并发开发提供效率,可以单独调试打包, 发版其实就相当于发插件

3.     动态热更新修复插件 (增量更新)

相信大部分APP软件的开发流程都会出现上面的流程,采用以前的架构的话,会有以下劣势:

a.    发现bug可能会反反复复去修改重发布,耗费人力和时间,成本非常大

b.    发布太多bug新版本,用户多次下载更,严重影响用户使用和体验,代价是很大的!

APP启动---> 校验检测插件更新--->更新插件<---插件管理中心推送插件更新

4.    按需下载模块

APP为了增加用户量,可能会偏向于“全功能”,但是又不需要太多功能,这时就可以按需下载。

5.    比组件化更低的耦合度,代码更新量小

6.    数据统计,功能对比体验, 可替换性和可扩展性强

插件化可以给不同的用户更新不同的插件,然后去观察他们的相关数据。

7.    增强代码的透明度与一致性

插件(Plugin)模式扩展程序的接口,用户可以按照规定接口编写插件来增加程序功能

8.   闭源代码的工程中使用GPL代码

一般来说,假如你使用了GPL发布的代码,那么你也需要开放你的源代码。

如果把GPL组件封装在插件中,你就不必发布插件的源码。

 

可能实际开发中不太会运用到插件模式,但是它确实我们经常会使用到的一种模式。

例如CocosBuilder和Unity3D都提供了插件功能,用户可以编写插件来完善或者定制编辑器。

此外,我们也可以编写Visual Studio、XCode 或 Eclipse的插件来扩展这些IDE。

插件模式中会有一个管理器用来管理这些插件,而如何调用插件的方法?

这里我们就需要制定一个接口,插件必须实现接口方法,而插件管理器则调用这些方法

插件API:

这个是创建插件必须要提供的接口,C++实现的话就是一个抽象类,C的话是一系列的功能回调.

回调中里面只提供接口,具体功能交给插件实现, 这部分代码应该在你的核心API之内。

插件管理器:

插件管理器负责插件的加载、注册以及卸载等功能,管理插件的整个生命周期。

该类一般都设计为单例模式,其实大部分资源管理的类一般都设计为单例模式。

插件的架构可以参考第四点,我们要做的就是基于微服务化的插件管理系统。

4.  微服务化

微内核框架主体:

分为宿主程序和插件对象两部分,宿主程序(host)和插件(plugin)

框架的总体结构上,参考OSGI的“微内核+系统插件+应用插件”结构

微内核核心层的设计和实现:

1.  插件的加载,  检测,初始化.  插件的加载利用Linux共享库的动态加载技术

2.  服务的注册,  服务的注册与调用采用表驱动的方法. 核心层中维护一个服务注册表.

3.  插件的调用

4.  插件的管理

5.  插件的版本依赖

6.  插件的出错处理

7.  插件事件的广播和订阅

微内核宿主和插件通信:

两部分交互基于一种公共的通信契约

微内核插件间通信:

利用观察者模式 , 在宿主中加载插件后 ,便能实现事件注册, 进而实现插件之间的通信。

建议采用可以采用第二点提到的组件路由机制,事件注册可以在bus中实现。

个人实现的轻量级基于微服化的插件管理系统:

https://github.com/wypx/libplugin

四. 参考框架

1. cpluff      http://www.c-pluff.org/

使用说明:

XBMC研究之C-Pluff熟悉

http://blog.sina.com.cn/s/blog_6c14c17e0100ln87.html

2.  monkey http库    http://monkey-project.com/

可以参考源码中的插件框架

3.  C++ 插件框架 Pluma Framework

http://blog.csdn.net/lclflash/article/details/8856876

http://pluma-framework.sourceforge.net/

4.  其他

很多软件以及库都是基于插件架构,例如PS,行业的GIS软件如Arcgis、QGIS、还比如开源图形引擎OGRE以及OSG,这些都是插件架构。

C++插件架构浅谈与初步实现

http://blog.csdn.net/zhouxuguang236/article/details/29365261

http://blog.csdn.net/pi9nc/article/details/29867999

五. 参考文档

APP项目如何与插件化无缝结合(一) 

APP项目如何与插件化无缝结合(二) 

APP项目如何与插件化无缝结合(三)

组件化与插件化华山论剑

留下脚印,证明你来过。

*

*

流汗坏笑撇嘴大兵流泪发呆抠鼻吓到偷笑得意呲牙亲亲疑问调皮可爱白眼难过愤怒惊讶鼓掌
关闭