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

晨曦之光 发布于 2012/03/09 12:11
阅读 366
收藏 1

摘要: 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)能支持各种不同操作系统的终端接入,包括PCWM以及各种嵌入式应用平台

 

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

 

 

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

 

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

 

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

 

OSGI具有Bundle的可配置, 可插拔, 并且有成熟的实践可供参考, 因此, 选定OSGI框架, 并尝试一个可以展示的Demo, 实践架构的可行性和降低后期风险性。

OSGI 可以满足系统的特性有:

1.       模块独立开发

2.       插件式管理

3.       项目后期比较复杂, OSGI存在复杂项目的优秀实践. 适合大型可扩展系统

 

 

: Demo需求分析

 

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

加法运算服务  等同于   行业搜索

乘法运算服务  等同于   专家系统

        

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

 

 

 

为了确保低耦合,可插拔的特点, 需要这些服务具有可配置(保证插拔), 相互独立(即耦合性低), 因此做以下设计

1.       Server接收到数据之后, 能根据数据提供的信息, 自动转发到相应的服务上

2.       两种Service, AddServiceMultiService 完全是独立的两个模块

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架构作为服务端开发的框架 

 

 

 

 


原文链接:http://blog.csdn.net/ostrichmyself/article/details/6554017
加载中
返回顶部
顶部