首页 新闻 论坛 群组 Blog 文档 下载 读书 Tag 网摘 搜索 .NET Java 游戏 视频 人才 外包 培训 数据库 书店 程序员
中国软件网
欢迎您:游客 | 登录 注册 帮助
    • 开源框架：设计瓶颈何在？？？
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • CXXSoft
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    • 揭帖率：
    发表于：2007-11-27 14:47:22 楼主
    问题：
        本人设计了一个“基于IoC思想设计的系统架构”，并在实际项目中使用，架构设计文档参见小作：“一个开源的IoC采集服务器体系结构设计”：http://blog.csdn.net/CXXSoft/archive/2007/09/06/1775341.aspx
        一个网友指出说：这样的设计一定存在并发缺陷、将导致系统性能瓶颈。但是：我自己一直没有看出来，麻烦各位高手帮忙看看、指点迷津、不甚感激！
    [color=#FF0000]设计摘要：color]
        通信采集服务器是常常是实时监控、数据采集类系统的核心，实现与底层的软件子系统、硬件终端、远程设备的通信、下行命令的执行、上行数据的接收、协议解析，并且完成业务数据的分析以及显示驱动。它既是系统的通信枢纽，也是业务核心。
    下图是基于IoC理念重新设计的通用的开源采集服务器子系统体系结构：

    [color=#FF0000]核心组件设计简介：color]
    1.  业务数据接口
        以统一的方式，输出本框架按配置的“通信模块”、“通信协议”、“采集业务类”所采集到的数据。框架使用者实现此接口的方法可以继续分析、处理、存储、展现业务数据。
    2.  外部系统接口
        本系统对外部系统的接口，目前没有定义具体方法，属于框架设计预留接口。框架使用者可以实现此接口，定制通信协议、通信方式实现与外部系统信息交互。外围系统通过此接口向“业务调度核心类”发起通信命令、操控底层设备、实时提取设备状态等业务请求。
    3.  业务调度核心类
        是采集子系统的业务调度核心类和业务请求中转站。外部系统的命令请求通过“外部系统接口”转入到“业务调度核心类”，“业务调度核心类”将命令请求存入命令队列中共“”执行；“”采集到数据之后，调用“数据接口”的方法将数据返回到“业务调度核心类”，之后，“业务调度核心类”调用“业务数据接口”或者“外部系统接口”将业务数据反馈到更上层模块。
    4.  任务队列管理类
        下行任务信息缓存类。“业务调度核心类”向其中增加命令请求；“采集调度控制器”自动检测是否有新命令请求，当检测到后立即“中断”通信握手，执行请求，执行成功之后，从队列中删除该命令。
    5.  采集调度控制类
        管理、协调其下的“采集业务类”、“通信实现类”、“业务状态机类”、“通信协议类”等模块，完成所有的通信控制及数据采集功能。通过调用任务接口获取采集指令；之后，调用业务接口（业务接口由“采集业务类”实现，在具体使用中由框架使用者根据自己的业务采集需求开发），获取具体的通信指令；根据通信指令调用正确的协议接口（协议接口由“通信协议类”实现，在具体使用中由框架使用者根据自己的通信协议需求开发）获得通信帧；最后，启动状态机开始本次采集任务的执行。采集调度控制器
    6.  采集业务类
        封装当前系统的具体采集业务对象，为通用的“采集调度控制类”定制具体的采集任务。本质就是：把上层的“抽象任务”细化成具体的“通信帧”和“通信控制步骤”、是一个简单的“工作流定制器”。
    7.  业务状态机类
        实现状态机接口，根据采集业务状态的控制、转换需求，框架使用者定制开发。主要用于通信链路的通断控制、数据收发、忙闲标识及转换等业务状态机逻辑。
    8.  采集方式类
        封装具体的串口、TCP/IP、语音卡等通信采集类，实现具体的通信方式控制及通用的数据收发接口。
    9.  通信协议类
        封装系统中软件与底层软件子系统、硬件设备、远程终端的通信协议。

    20  修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • CXXSoft
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-11-27 14:50:111楼 得分:0
    本人看来好久，就是没有看出问题所在。欢迎大家一起来找找

    完整全文，请参考blog文章：
    http://blog.csdn.net/CXXSoft/archive/2007/09/06/1775341.aspx
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • CXXSoft
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-11-28 23:16:112楼 得分:0
    没人回复，只能转到人气旺的地方.
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • ming4098
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：

    • 6

      3

      2
    发表于：2007-11-28 23:34:563楼 得分:0
    up
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • yuanhuaj
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-11-29 00:04:564楼 得分:0
    支持一下.........
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • work_in_java
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-11-29 12:39:005楼 得分:0
    回复一下,虽然不太懂
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • kelph
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-13 12:14:266楼 得分:0
    做过一个项目，有相似之处。
    概要设计上没有问题。

    不存在什么并发缺陷
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • CXXSoft
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-13 14:57:377楼 得分:0
    kelph ：
    谢谢。但是朋友很肯定地说，“这样的设计存在运行性能瓶颈”，麻烦在帮我继续、仔细看看
    不甚感激。
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • CXXSoft
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-14 10:02:168楼 得分:0
    发这么久，都没人理我，再次转贴.
    希望管理员不要删贴....
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • CXXSoft
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-14 10:03:029楼 得分:0
    问题解决后，我一定会归到相应的栏目下面的.
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • heipn
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-14 17:35:3010楼 得分:0
    你的所有操作和运行都要经过这个采集调度控制器，并且在你的通信接口和采集调度控制器中间没有看到缓存系统或者异步处理机制，在海量数据下，也就是说在各种采集数据来的时候的通信接口直接根据IOC容器产生的adapter直接处理吗？这肯定是搞不定的，需要先把数据接收下来，中间有个缓冲.各种数据过来应该进入各自数据的接收缓冲器，然后采集调度控制器异步的去读取这些缓冲器的信息，再交给后面的核心系统处理，而且这之间可以做出级别控制，以保证先处理紧急的事情，保持系统的稳定性，永远不会瘫痪，一旦发现堆积过多的时候，就是应该提高核心处理模块的速度的时候，加机器或者添加线程或者优化核心业务逻辑处理程序。
       
      个人意见啊，仅供参考！
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • cm4ever
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-17 02:57:2311楼 得分:0
    楼上说得不错啊。
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • CXXSoft
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-17 12:42:4012楼 得分:0
    呵呵。谢谢“heipn ”的关注与高见
    我的设计是：
    下行(向下采集命令)：数据缓存放到命令队列里面的。
    上行(通信交互数据)：放到底层的每种通信采集类里面，比如：串口、板卡、TCP/IP等，底层通信抽象里面，都有自己的缓存机制。
    你说了一点非常重要：我确实没有设计高并发、海量的数据上报，到业务处理模块数据缓存机制。谢谢。
    只是：在数据存储(比如统一往DB写入数据是有缓存、队列机制)、消息转发(向外部其他系统通知采集数据时，也有缓存、队列机制)。中间的确缺少了重要的一环，非常感谢。
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • kaoloveting
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-17 13:35:5313楼 得分:0
    up for you
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • zdljq
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-17 14:39:4114楼 得分:0
    该回复于2007-12-19 10:51:55被版主删除
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • yys5566
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2007-12-21 21:30:3415楼 得分:0
    JAVA C++ 技术群：45609427
    提出问题，挑战技术，呈请加入!
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • ggokind
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2008-01-12 00:31:4716楼 得分:0
    任何一个架构都存在瓶颈，关键还是架构的定位和质量属性，正所谓质量属性决定架构。
    在不清楚楼主的系统上下文的情况下，简单的说“存在性能瓶颈”多少有些不负责任：）。

    性能瓶颈没有发现，但是对于架构层次，我个人觉得不是很清晰。我理解楼主的架构分层是：
    1、展示层
    2、业务层
    3、调度层
    4、采集业务层
    5、通讯适配层

    其中2、3、4定位较为模糊。尤其是“采集业务”与“业务调度核心类”的关系我没有看懂（缺少一个概念模型，没有理解楼主的业务建模，见谅），我觉的定位有些不清晰，采集业务是不是业务？“业务”、“任务”和“采集业务”是什么关系？

    潜在的隐患可能是建模不清晰导致逻辑不清晰，最终维护困难；层次过多，有可能层间存在耦合，倒是消耗较大（接口增多，调度复杂）。

    heipn回复的也是有个前提“在海量数据下”，这个前提似乎是大多数系统都受不了的。
    质量属性较高的架构，就意味着高成本（硬件成本，软件设计成本，维护成本，测试成本），架构就是在夹缝中生存：）。

    以上纯粹个人猜测，没有太多论据，如有欠考虑的地方，请楼主包涵：）。
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • Intotherain1
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2008-01-16 08:06:1517楼 得分:0
    既然是数据采集系统，那么核心就是怎么处理来自硬件的海量的不确定的数据和发出命令。 

    这个核心和IoC并没有太多关系， 何况， 你所处理的业务场景并不是IoC要解决的问题。

    在你说道利用IoC的好处时， 你只是谈到了把功能抽象为接口借以实现不同业务代码间解耦合，这是我们
    任何设计都要这么做的，所以如果是论文，你这点就很容易被人置疑


    访问  yilan.googlecode.com  或许你对IoC有个别样的了解 
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • UltraBejing
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2008-05-01 00:53:3818楼 得分:0
    该回复于2008-05-01 06:19:41被版主删除
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • slimfeng
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2008-05-06 13:37:4819楼 得分:0
    非常赞同ggokind的看法，我在看这个架构是就没有搞清楚“采集业务”、业务、任务的关系，更没有搞清楚“采集业务调度”与“业务调度”的关系。好像记得这个架构是某个开源项目的，期待找到源代码看看
    修改 删除 举报 引用 回复
    进入用户个人空间
    加为好友
    发送私信
    在线聊天
    • helanpiaoxue
    • 等级:
    • 可用分等级：
    • 总技术专家分：
    • 总技术专家分排名：
    发表于：2008-05-08 18:36:2020楼 得分:0
    follow you
    修改 删除 举报 引用 回复
    网站简介－广告服务－网站地图－帮助－联系方式－诚聘英才－English－ 问题报告
    北京创新乐知广告有限公司 版权所有 京 ICP 证 070598 号
    世纪乐知(北京)网络技术有限公司 提供技术支持
    Copyright © 2000-2008, CSDN.NET, All Rights Reserved