服务端架构技术——基于OSGI服务端的架构设计和实现

摘要: OSGI架构一个服务端, 满足可插拔, 低耦合, 重用率高的问题. 并且服务端接收到指定协议的数据后, 能自动分发到相应的服务进行处理。 目的是为了满足后期的可插拔特性。本文是服务端设置的一个Demo. 后期这个Demo回重构, 以满足真实的通信能力. 不过读者完全可以自己写一个Socket连接池来完成整个设计规划。

项目的需求是:
1. 整体架构是基于Server-Client架构
2. 建立一个服务端, 这个服务端是可以扩展的, 即后续可以有服务插入到该系统.
3. 系统可以即时对服务进行插拔的能力, 自动升级的能力等

该Demo模拟了这样一个功能, 从OSGI命令行接收到一个命令:
服务名 参数1 参数2
就能将服务转发到对应的服务插件上去.
比如:
AddService 12 34
这样就能将参数传递给AddService这样的服务, 并得到两个参数相加的结果, 与加法对应的是乘法计算, 这是本Demo提供的另外一个与加法对等的Service.

目前方案确定的架构:

OSGI Cloud (Server端)+ Open API(Client端)方案.

一:概述:
本篇作为技术研究, 目的是为了研究OSGI框架能满足后续项目XXX的服务端架构需求, 目前归纳的XXX项目服务端架构需求如下:

1）热插拔，能动态集成各种应用服务；

2）低耦合，各模块不相互依赖；

3）易用、可扩展，各层相对独立；

4）能屏蔽底层协议内容及细节

5）能支持各种不同操作系统的终端接入，包括PC、WM以及各种嵌入式应用平台

6）远程程序动态更新下载、更新以及升级


总体归结起来, 最需要满足以下两个特点:

1. 扩展性[如插拔特性, 低耦合性, 自动更新和升级都跟这个相关]

2. 效率的问题[代码的重用性问题, 独立开发问题]

OSGI具有Bundle的可配置, 可插拔, 并且有成熟的实践可供参考, 因此, 选定OSGI框架, 并尝试一个可以展示的Demo, 实践架构的可行性和降低后期风险性。
OSGI 可以满足系统的特性有:
1. 模块独立开发
2. 插件式管理
3. 项目后期比较复杂, OSGI存在复杂项目的优秀实践. 适合大型可扩展系统


二: Demo需求分析

能提供加法运算和乘法运算服务的Server端功能. 真实的XXX项目包含行业搜索，专家系统，智能门户等功能. 这里可以做这样的类比:
加法运算服务 等同于 行业搜索
乘法运算服务 等同于 专家系统

从下面的示意图可以略见一斑:






为了确保低耦合，可插拔的特点, 需要这些服务具有可配置(保证插拔), 相互独立(即耦合性低), 因此做以下设计
1. Server接收到数据之后, 能根据数据提供的信息, 自动转发到相应的服务上
2. 两种Service, AddService和MultiService 完全是独立的两个模块
3. Server端能注册所有服务, 这些服务由配置信息决定, 不需要硬编码
4. Server端转发服务, 也是通过配置信息完成, 无需硬编码


三: Demo系统设计
按照OSGI的基本知识, 将项目的系统组织为如下插件方式, 注意这里插件分层的重要性, 因为插件之间不允许存在相互引用，即引用关系式单向的, 所以分层非常重要, 只允许上层对下层的调用。











分层的依据:
1. 插件系统提供可访问的结构(即依赖关系), 但不可以双向访问(插件A访问插件B, 同时插件B又访问插件A. 这样式不允许的)
2. 插件系统的环状访问(插件A访问插件B, B访问插件C, C 访问插件A,这样同样不允许)
3. 遵照众多SDK API的设计原理, 访问的单向性, 每个插件必须确定其层次, 只允许高层对低层的访问, 明确各自插件的范围。


下面介绍下这三层设计的特点:
1. L1层是最底层, 这层将所有的公用包综合在一起, 对外提供统一的接口, 这层跟C语言的ANSI 提供的API性质类似.
2. L2层是业务无关的代码, 比如通信模块, 线程池，数据库连接池, 图像处理，文件，数学处理公式, HTML处理, 文本分词，算法原型等，该层可以重用，可以用到XXX项目，也可以用到其它未来的项目。
3. L3 是跟业务强相关的层次, 具体的Service类型, 具体的业务功能, 这层代码不可重用，只能应用于特定/唯一的项目中(但具体Service的开发者需考虑可重用)。


四: Demo 系统编码



点击下载




下载后, 按照通常的方式导入到Eclipse RCP版本中, 注意:
1. Eclipse开发版本为RCP版本
2. 按照通常的import exist project to work space, 而不是导入Plug-in development
3. com.ostrichmyself.util.xml2obj是从配置文件生成Service注册的插件, 并且能帮助分发服务. 其下有一个配置文件，需要copy到Eclipse运行的根目录，这个文件夹是serviceconf

按提示输入, 即可以演示:
Addservice 12 34
将发往AddService进行加法处理
MultiSerivce 12 34
将发往MultiService进行乘法

注意注册机制是依赖注入的原理












五: 结论

1. 插件结构适合当前XXX项目的开发. 模块间相对独立, 适合分工
2. 满足Service独立和分离, Service可以方便配置, 满足可插拔特性
3. 插件访问机制优良，方便代码重用

共识: XXX 项目系统架构采用OSGI架构作为服务端开发的框架