一个开源的 IoC 采集服务器体系结构设计
基于 IoC 思想设计的系统架构
作者：成晓旭
http://blog.csdn.net/CXXSoft/
( 声明：版权保留，欢迎转载、请保证文章完整性 )
1.
引言
Java 领域的开发人员，可以采用 spring 开源框架，快速构建自己的业务应有系统，本人羡慕不已。但是在我采用的传统开发语言、专业应用领域，都没有这样的好框架可以沿用。于是早有自己设计一个 IoC 框架，适用于本人涉及的实时监控、通信采集领域。
“他山之石、可以攻玉”。其实 IoC 、 DI 等优秀的分析、设计理论未必非要用来构架通用的基础开发框架，在具体的应有系统开发中借用，同样能构建灵活的系统体系架构，尤其是对于企业战略性的长期的产品、系统的构建，更是事半功倍。
2.
系统背景简介
在实时监控、数据采集等通信类系统中，通常的设计都是：将数据采集或者与底层逻辑单元（比如：底层的软件子系统、硬件终端、远程设备）通信的逻辑功能独立封装在一个子系统中，实现基础通信收发、通信方式分化、通信流程控制、底层协议规整、基础数据整合等网络通信、数据采集职责。
本设计是针对常见的实时监控、数据采集系统。下面以一个典型的通信采集服务器应有为例：系统的底层是硬件采集设备，硬件设备完成整个系统与外界环境或者设备的交互；上层的软件系统完成与自己硬件设备的交互，并且对采集的数据进行分析、处理、存储、与外部系统接口。
<shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></path><lock aspectratio="t" v:ext="edit"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 414.75pt; HEIGHT: 232.5pt" type="#_x0000_t75"><imagedata o:title="新框架" src="file:///C:%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.png"></imagedata></shape>
3.
问题
在我工作的软件项目中，类似的应用存在于多个软件系统中，虽然这些系统在子系统设计及职责划分方面也如上图一般进行了明确的分层及模块化，但在核心的“通信采集子系统”的设计及实现上存在诸多通病，导致整个子系统的可理解性、可维护性、可测试性、对需求变动的适应性极差。集中表现在：
1. 整个系统被设计成一个“非常庞大”的“业务调度控制类”，没有进行职责的拆分和封装；
2. 在通信方式实现类（比如：串口通信类、语音卡控制类、 TCP/IP 通信类）中完成所有业务处理功能；（绝大多数板卡厂商 Demo 程序就是这样演示的，有意无意间误导了很多刚刚接触 CTI 、 IVR 系统开发的入门者）
3. 对于多任务并发，多个设备上、下行同时通信的管理非常复杂；
4. 对于需求变化的适应性非常差；
5. 系统代码几乎没有可复用性了。
4.
新问题
针对上述问题，总结、分析以往经验和教训，以“代码复用”为出发点重新设计了通信采集系统体系架构，并较好地解决这些突出问题，并梳理出大量可复用的功能代码。详细说明请参考《一个典型的采集服务器体系结构设计》一文： http://blog.csdn.net/cxxsoft/archive/<chsdate isrocdate="False" islunardate="False" day="18" month="9" year="2006" w:st="on">2006/09/18</chsdate>/1236331.aspx 。
但是，后来再次开发通信采集服务器，以应有于不同的业务需求时，发现原来的架构存在如下的典型问题：
1 、“采集控制器”几乎不能重用、但与新开发的采集控制模式非常相识。但是，每次新开发的“采集控制器”逻辑都非常相识，但必须修改业务采集类的类名和方法名，修改状态机的转换关系，修改协议调用的类名和方法名。
2 、“业务采集类”的变化，会直接影响到“采集控制器”。
3 、“通信协议类”的变化，会直接影响到“采集控制器”。
4 、通信控制流程、时序的变化，会直接影响到“采集控制器”。并且要正确实现这些变化，必须在与此无关的“采集控制器”中，小心翼翼地扣代码出来改。
5.
IoC
重构设计
开源的通用采集服务器，是在原有系统架构的基础上，增加业务抽象接口，引用 IoC 的设计理念，倒置交互类之间的依赖关系，采用 DI 来实现类之间的依赖关联的动态关联。
1、 抽象“业务调度核心类”的核心逻辑流程，将所有类方法的调用设计成对接口方法的调用。
2、 抽象“采集控制类”的核心逻辑流程，将所有类方法的调用设计成对接口方法的调用。“采集控制器”类被设计成一个通用的“工控机主板”，只要遵循“主板”约定的接口，换插不同的“业务采集类”、“通信协议类”，就可以实现完全不同的采集业务需求、按照完全不同的通信协议与底层模块通信。
3、 将“采集控制类”中的状态机管理逻辑剥离出来，将状态机检测和控制代码设计成对接口方法的调用。只要遵循状态机接口，就可以灵活实现不要业务需求的状态转换控制，在运行期动态创建状态机实例，并注入到“采集控制类”，完全接触“采集控制器”与“业务状态机类”静态依赖。
4、 去掉“通信适配器”、“协议适配器”，增加“通信接口”、“协议接口”和“业务接口”，按照接口要求重构通信类、协议类、采集业务类，解决原来系统架构中：新增一种通信方式、通信协议时，还必须在相关的适配器中增加新类型识别代码的设计弊端。
6.
技术基础与规约
本设计的核心的设计原理： IOC 容器根据反射机制动态创建实现约定接口的业务对象，动态注入到采集调度控制器中。采集调度控制器是一个高层次抽象的 Active Class ，自动不断地调用状态机接口方法来执行“业务采集类”要求的业务通信指令。
本设计的核心的重要设计约定：采集调度控制器只调用抽象的接口方法，那么具体的上层业务任务，如何动态的翻译成具体的通信协议？又如何知道当前的任务如何开始，何时结束？本设计要求：业务采集类必须管理好自己的业务步骤与通信协议之间的对应关系（确实非常难以在抽象，用动态配置的方法使用起来反而更复杂），采集调度控制器只负责动态建立两者之间的运行期对象关系。业务采集类必须实现采集调度控制器要求的指定接口方法，用以实现采集任务的发起、执行下一条指令、结束、异常重发、异常中止、故障处理等采集流程控制功能。这正好是采集调度控制器高层抽象的价值和通用性的设计基础。
框架使用者只需按照接口约定，编码实现具体业务需求的相关采集、状态机、协议业务类；在配置这些类的运行期参数，采集服务器就大功告成。采集服务器在允许时，会自动加载配置参数，动态创建相关的业务逻辑对象，并完成依赖注入，整个系统就能按具体的业务要求完成通信、采集任务。
7.
采集服务器设计
通信采集服务器是常常是实时监控、数据采集类系统的核心，实现与底层的软件子系统、硬件终端、远程设备的通信、下行命令的执行、上行数据的接收、协议解析，并且完成业务数据的分析以及显示驱动。它既是系统的通信枢纽，也是业务核心。
下图是基于 IoC 理念重新设计的通用的开源采集服务器子系统体系结构：
<shape id="_x0000_i1026" style="WIDTH: 414.75pt; HEIGHT: 345.75pt" type="#_x0000_t75"><imagedata o:title="IoC框架图" src="file:///C:%5CTemp%5Cmsohtml1%5C01%5Cclip_image003.png"></imagedata></shape>
8.
核心组件设计简介
1. 业务数据接口
以统一的方式，输出本框架按配置的“通信模块”、“通信协议”、“采集业务类”所采集到的数据。框架使用者实现此接口的方法可以继续分析、处理、存储、展现业务数据。
2. 外部系统接口
本系统对外部系统的接口，目前没有定义具体方法，属于框架设计预留接口。框架使用者可以实现此接口，定制通信协议、通信方式实现与外部系统信息交互。外围系统通过此接口向“业务调度核心类”发起通信命令、操控底层设备、实时提取设备状态等业务请求。
3. 业务调度核心类
是采集子系统的业务调度核心类和业务请求中转站。外部系统的命令请求通过“外部系统接口”转入到“业务调度核心类”，“业务调度核心类”将命令请求存入命令队列中共“”执行；“”采集到数据之后，调用“数据接口”的方法将数据返回到“业务调度核心类”，之后，“业务调度核心类”调用“业务数据接口”或者“外部系统接口”将业务数据反馈到更上层模块。
4. 任务队列管理类
下行任务信息缓存类。“业务调度核心类”向其中增加命令请求；“采集调度控制器”自动检测是否有新命令请求，当检测到后立即“中断”通信握手，执行请求，执行成功之后，从队列中删除该命令。
5. 采集调度控制类
管理、协调其下的“采集业务类”、“通信实现类”、“业务状态机类”、“通信协议类”等模块，完成所有的通信控制及数据采集功能。通过调用任务接口获取采集指令；之后，调用业务接口（业务接口由“采集业务类”实现，在具体使用中由框架使用者根据自己的业务采集需求开发），获取具体的通信指令；根据通信指令调用正确的协议接口（协议接口由“通信协议类”实现，在具体使用中由框架使用者根据自己的通信协议需求开发）获得通信帧；最后，启动状态机开始本次采集任务的执行。采集调度控制器
6. 采集业务类
封装当前系统的具体采集业务对象，为通用的“采集调度控制类”定制具体的采集任务。本质就是：把上层的“抽象任务”细化成具体的“通信帧”和“通信控制步骤”、是一个简单的“工作流定制器”。
7. 业务状态机类
实现状态机接口，根据采集业务状态的控制、转换需求，框架使用者定制开发。主要用于通信链路的通断控制、数据收发、忙闲标识及转换等业务状态机逻辑。
8. 采集方式类
封装具体的串口、 TCP/IP 、语音卡等通信采集类，实现具体的通信方式控制及通用的数据收发接口。
9. 通信协议类
封装系统中软件与底层软件子系统、硬件设备、远程终端的通信协议。
9.
设计模式与原理
1) 整个系统采用 MVC 的设计模式 ：业务数据、显示控制及界面显示严格分层，单独实现。业务数据通过下层模块产生，通用“业务调度核心”这个中介与“界面接口定制类”这个控制器交互；控制器“界面接口定制类”可以根据不同的显示需要进行定制，与不同的界面组件交互，可满足不同的显示需求；在界面显示层，引用了其它项目中实现的“标准界面通用组件库”中的部分源码。
2) “业务调度核心类”采用 Mediator 模式。
3) “采集调度控制器”采用“微内核”的实时设计模式。
4) 命令队列采用 Command 模式： 以强制分离命令的发起者与命令的执行者。
5) “业务状态机”采用 State 模式： 通过抽象业务状态机，可以灵活地实现不同采集控制需求。并且，如果采集方式类是语音卡之类的设备时，采集类里面也往往采集“状态机”模式来管理这类自身以状态方式驱动的通信设备。
6) “业务采集类”，对多协议的自动处理采用 Chain Of Responsibility ： 将多个协议组件组织成一条“职责链”，实现对当前通信协议的自动识别、自动解析功能。
7) “采集调度控制器”，考虑并发和性能，采用“通道”的实时设计模式： 以尽可能地提升系统并发能力、提高系统吞吐能力。
8) “采集调度控制器”，采用“轮巡”和“中断”的实时设计模式： 为检测通信链路是否可用，在通信空闲时，系统要求与硬件终端进行定期“通信握手”，当“采集调度控制器”检测到“命令队列”或者“硬件终端”的任务请求时采用“中断”方式立即响应上、下行命令。
10.
应有实例
采用此框架的体系架构，框架使用者只需按“任务接口”实现自己特定的“任务队列管理类”，按“业务接口”实现自己特定的“采集业务类”，按“状态机接口”实现自己特定的通信业务控制“业务状态机类”，再按“协议接口”实现自己特定的“通信协议类”，就能够非常快速地开发一个功能完备、运行稳定的通信采集服务器。目前，应有此框架已成功构建“指纹采集系统”、“粮情测控系统”的通信采集服务器。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1775341
