混合架构

2024-07-29

混合架构(通用7篇)

混合架构 篇1

云计算技术现在无处不在, 随便打开一本计算机杂志或网站, 你都有可能会看到云计算, 云计算其实往往是网络的代名词, 用来表示处理网络数据的所有其他设备。随着云技术的高速发展, 越来越多的计算机从业人员将不得不学习云技术, 来为自己的企业建立私有云或混合云。为自己的企业提供大数据分析和云服务, 大数据分析可以为企业分析自己的目标客户, 了解客户需求, 产品发展方向等, 为客户提供更好的产品或服务。云技术则可为大数据处理提供必需的云计算, 云存储等。

1、混合云的定义

混合云最简单的定义就是公有云和私有云的组合。美国国家标准与技术研究院所采用的定义为“混合云是使用标准或专有技术使数据和应用程序具有可移植性的公有云和私有云绑定在一起的组合。”它可能是一个企业的私有云与一个或多个供应商的公有云的组合, 或托管在第三方场所里面的私有云与一个或多个供应商的公有云的组合。

根据对公有云服务能不能满足IT和一些商业组织的业务需求的调查, 混合云环境可以更好的满足他们的需求。在某种程度上, 混合云可以被理解为是企业准备将大部分工作转移到公有云上的一个中间阶段。

2、混合云的优点

混合云提供公有云的成本和规模优势的同时, 还提供了私有云的安全和控制。

2.1 节约成本

2.1.1将企业的基础设施需求外包给公有云供应商可以减少资本支出。

2.1.2将临时项目资源外包给公有云供应商可以大幅降低成本, 因为使用公有云不再需要投资就可以开展这些项目。

2.1.3帮助在应用程序生命周期的不同阶段优化基础设施支出, 公有云可以用于开发和测试, 同时私有云可以被用于制作成品。更重要的是, 当企业使用Saa S应用程序时, 公有云可以随时退出, 这比使用专用的内部部署基础设施的成本低得多。

2.2 反应速度快

2.2.1 同时提供了私有云的控制能力和公有云快速扩展能力。

2.2.2 支持云爆发技术, 公有云可以在企业计算需求突然提高时提供额外的计算资源, 如果完全依赖私有云来满足业务高峰期的需求, 那么将有很大一部分资源在日常处于闲置状态。

2.2.3 由于利用了公有云技术, 整个企业的业务敏捷性得到大幅改善, 从而增加了传统的基础架构或纯私有云上无法获得的机会。

2.3 安全性注意事项

要让企业为他们的业务需求使用混合云, 他们必须了解的一个混合云环境中的新的安全要求, 而混合云提供了私有云的安全性优势, 也为企业带来了一些独特的安全挑战, 在考虑私有云相关的典型安全问题之外, 也应该考虑在混合环境中的一些其他因素。

2.3.1 周边延伸:

混合云架构会将企业的IT业务范围扩大, 它有更大的面积可以被攻击, 在云服务供应商控制下的混合云部分更容易被攻击。

2.3.2 身份和访问管理:

一个简单的方法来解决混合云的身份认证, 是扩展现有的企业身份认证来访问和管理公有云, 但这种做法也带来了企业对其身份安全性的担忧。

2.3.3 管理工具:

当企业在复杂的混合云环境使用管理工具, 无论是作为云平台的一部分, 或作为第三方工具, 企业应该考虑使用这种工具的安全隐患。例如, 管理工具应该能够在混合云环境下安全的进行身份认证和任务执行。

2.3.4 数据迁移:

混合云架构使得数据从私人环境中流动到公有云中更加容易, 这样的数据移动具有保密性和完整性, 因为在公有云环境比私有云更注重隐私控制。

2.3.5 安全策略:

混合云环境下的安全策略有一定的风险, 如相对于一个纯粹的私有云环境公有云中的加密密钥如何托管。

3、提高安全性的最佳做法

调查显示, 如果企业了解他们如何能在云中保护他们的数据, 许多企业将考虑迁移到公有云。混合云可以作为一个过渡性的办法, 来帮助企业调整自己对未来的公有云应用的战略。混合云为企业提供一个安全的外壳, 他们可以尝试公有云服务, 同时仍把敏感数据放在一个更可控的私有云中。还有, 这将有助于减轻与混合云部署相关的风险, 在本节中, 我们将重点研究这部分内容。

3.1 虚拟机级安全性:

混合云环境的范围不仅有弹性, 而且跨越多个云, 包括内部部署的私有云, 这就需要在虚拟机级别穿过在云和多个云供应商之间的预置数据中心, 自提升自我防御的安全性。

3.2 多层防御:

使用工具, 如防火墙, IDS/IPS, 日志检查等面向虚拟机的防御策略是很重要的, 更重要的是, 虚拟机之间的通信应通过设定适当的策略连续不断的监控。

3.3 流量控制:

内部网关应该被用来控制发送到公有云的流量, 而不是提供直接访问。

3.4 数据和加密:

在云计算中的数据应该加密, 加密解决方案应该有精心设计的加密密钥管理政策, 以确保数据的完整性。此外, 企业应保留加密密钥的所有权, 以保持企业的工作和公有云服务供应商之间的分离。这也使得企业可以在其私有云和公有云中使用它们的加密和防止厂商锁定, 允许企业自由选择云服务供应商。

3.5 安全控制:

云安全应该由企业来控制, 而不是云供应商。无论是使用登录或使用第三方工具来管理企业的公有云部分, 企业应当对其部署的混合云架构的安全性有完整的控制权。

3.6 执行标准:

企业应当了解法律规定对于混合云部署的影响, 并及时作出调整, 在混合云技术发展过程中收集信息, 如审计日志, 并妥善保存这些信息。还有是从共有云供应商收集必要的信息, 并将其存储在公有云环境之外的其他地方。此外, 企业还有必要雇佣了解使用云服务风险的员工来执行这些规定。

4、对于混合云架构的建议

4.2 混合云技术应用实例

有许多不同的环境适合采用混合云, 这里会列出一些最重要的:

4.2.1使用私有云技术处理关键任务, 使用公有云技术处理非关键技术。例如, 一家公司可能会使用公有云技术来进行产品测试和开发, 在私有云中进行产品最终设计和调试。另一个例子是使用公有云处理面向外部的应用程序, 同时使用一个私有云处理内部应用程序。

4.2.2云爆发, 动态部署应用程序设置, 平时运行在私有云上, 当遇到运算量突然提升时启用公有云以满足意外的运算需求, 如零售企业的假日购物量突然提升。

4.2.3无损灾难恢复测试。如果产品含有灾难恢复功能, 企业可以利用公有云平台对其进行测试, 期间不会产生中断。

5、结论

混合云提供了更大的灵活性, 为企业提供了可以同时保持控制和安全性的选择。希望建设混合云架构的企业, 通常出于让公有云分担工作量、防止云爆发、加快产品生产速度等目的。因为每个混合云基于的公司需求和实现结构各不相同, 没有一个通用的解决办法。由于混合云环境包含本地和公有云供应商, 企业需要额外考虑考虑公有云相关的安全性问题。任何计划部署混合云的企业都应当了解混合云的安全需求, 并参照现有混合云部署的经验和最好的做法, 来降低风险。在保障了混合云环境的安全性的前提下, 企业可以将更多的工作放到公有云上去完成, 节约更多的成本。

摘要:云计算技术分为公有云、私有云和混合云三种, 其中混合云是使用公有云来降低经济支出, 同时使用私有云来保证企业核心技术的安全运行。混合云也被认为是云计算技术的最终解决方案。

关键词:公有云,私有云,混合云

参考文献

[1]陈全, 邓倩妮.云计算及其关键技术[J].计算机应用, 2009.

[2]张莉.浅谈云计算技术国内发展现状[J].计算机光盘软件与应用, 2012.

[3]中国云计算产业发展白皮书[M].赛迪顾问股份有限公司, 2011

[4]基于混合云的安全数据存储架构[J].现代计算机 (专业版) , 2011.

[5]公共云?私有云?哪个才是我的云?[J].微电脑世界, 2010.

[6]罗军舟, 金嘉晖, 宋爱波, 东方.云计算:体系架构与关键技术[J].通信学报, 2011.

基于混合架构的医院综合集成系统 篇2

我国医疗信息化的建设起于20世纪70年代, 大致分4个阶段[1]:20世纪70~80年代的单机单用户阶段, 此阶段的特征是程序以单机单用户为特征, 服务器以小型机为主, 慢慢过渡到苹果PC;20世纪80年代中期的科室级应用, 此阶段系统实现了局域网内的互联互通, 如住院管理、门诊计价收费系统等, 此时C/S架构慢慢进入视野;20世纪90年代的全院级应用阶段, 此阶段中快速以太网和大型关系数据库日益成熟, 完整的全院级医院管理系统, C/S架构成为主流;21世纪计算机技术进入新的发展纪元[2], 新技术不断为医疗信息化的发展注入新的动力。随着医院规模的快速扩大, 区域医疗逐步进入视野, 特别是近年来全国居民健康档案系统的发展、医疗云系统的探索、远程会诊的应用, 同时由于服务器软硬件水平的提升, B/S架构的医院信息系统 (HIS) 开始慢慢步入主流。

2 我院的信息化建设历程

我院信息化的发展史是中国县级医院信息化建设的一个很好缩影。我院的信息化起始于20世纪90年代中期, 主要以单机单用户为主。随着医院的逐步发展和壮大, 新医院HIS的上线, 实现了科室级的联网, 使得我院的信息化水平, 在同级医院中走在了前列。

然而2008年5·12大地震, 使得大家的辛苦付之东流, 医院也成了一片废墟。但医院以重建为契机, 再次引入全院级的HIS、检验信息系统 (LIS) 、影像存储与传输系统 (PACS) 等, 使得我院的信息化水平进一步提升。

经过地震后3年的发展, 我院的业务量快速上涨, 计算机终端的数量也从初期的100台升至700台左右, 而信息科的人员数量变化不大, 因此每个工作人员都处于超负荷工作状态。HIS的C/S架构的缺点开始暴露:人员维护成本高、终端分布广、升级麻烦, 使得信息科人员疲于奔命, 严重影响了医院各科室的业务发展, 运维效率的提高成为了我们要考虑的重点[3,4]。

医院信息系统中的诸多子系统中, 既有我院自主研发的, 又有第三方软件公司安装的, 且大部分都采用C/S架构, 出现了很多信息孤岛和信息烟囱。为了解决这些问题, 我们设计了一个通用的前台加载器, 将应用程序本身以大对象的方式存入数据库, 用时动态加载。使用了一段时间后, 发现效果并不理想, 主要是360等杀毒软件会进行拦截, 导致加载或升级失败。后来我们采用纯B/S架构, 维护和部署方便了, 但系统反应迟钝, 有时莫名其妙地卡死, 再次登录后先前的工作全部丢失, 又要重新再来。尽管做了特别的优化, 但在医院海量的信息量面前系统响应仍然不及时。特别是一次后台Web服务器故障, 导致前台系统全部瘫痪, 严重影响了业务的正常运转。我们不得不又将相应的应用系统改回C/S, 于是又陷入了先前的恶性循环。

后来我们发现以IE为运行媒介的ACTIVEX架构[5], 不失C/S的速度响应, 也具有B/S的免安装维护, 应用此架构对系统再次进行改造, 取得了一定效果。但由于HIS的特点, 经常都会有新的需求出现, 而每次软件升级后, 插件需要重新安装, 业务科室的人员对具体的业务很精通, 而对计算机相对陌生。软件的升级维护和部署问题制约了我院信息化的进一步发展。

在吸取先前的经验教训, 在上级领导的关心帮助下, 在全科人员的努力下, 经过摸索和研究, 我院的医院综合集成系统[6]出炉, 其既有C/S架构响应时间短、反应速度快的优点, 又结合了B/S架构的免安装、零维护的长处。同时将不同的子系统无缝集成在一起, 既方便了信息科人员的安装和维护, 也方便了全院各科室的使用, 这种混合架构比C/S和B/S更先进[5]。

3 混合结构的实现

3.1 技术原理

根据应用场景, 该架构将业务系统分为2类。对运行速度、响应时间要求严格的系统, 在实现时, 改造为类DLL (Dynamic Link Library, 动态链接库) , 其运行时以IE为媒介, 通过通用的ACTIVEX加载插件进行。这样只要通用的加载插件平台功能不变, 具体的业务系统再变化, 用户使用同样便利, 不需要安装加载插件。而第三方的通用加载插件多种多样, 技术上已经成熟, 国内比较知名的有cbx和WebXone, 我院采用后者。而对于响应时间运行速度要求不严格的系统, 采用传统的B/S架构, 而开发B/S的系统工具有很多选择, 如PHP、ASP等。不管哪种架构, 对用户来说, 就像访问普通的Web应用一样, 唯一的区别是完成的具体业务流程不同, 但响应时间和传统C/S程序一样快。

3.2 系统架构图

混合架构的体系结构, 见图1。

结构说明:由于我院使用的院内即时通讯软件系统ActiveMessenger (AM) 覆盖全院, 而该软件在功能上支持第三方的动态链接, 因此我们将医院综合集成系统链接其中, 全院各科室就像使用QQ一样, 在医院综合集成系统中就可以启动各个子业务系统[7]。

由于AM系统后台使用的是SQL2000数据库, 其用户验证模式为服务器和主机的混合认证, 如果采用二层结构, 需要各科室的主机用户和密码与服务器保持一致, 这样既不安全也不现实。因此我们采用了三层结构。在实际应用中, 三层架构还可保证医护人员不在医院也能进行相应的远程办公。

初次登陆综合业务平台时, 首先会获取当前登陆AM软件用户的工号, 进而动态获取次工号对应的全新视图。通过模块的动态添加和权限的动态设置, 能在后台统一设定前台的用户权限视图, 带来了极大的方便和灵活, 同时由于AM软件的全覆盖, 基本做到了新系统上线的零安装和免维护。

3.3 核心技术

以IE为运行媒介, 以第三方activeX加载插件为基础, 通过软件的DLL改造, 同时使用极具灵活性的三层架构技术, 使得我院综合集成系统的架构体系充分综合了C/S架构和B/S架构免安装、零维护、响应速度快的特点, 同时不会因为单点故障导致整个系统的瘫痪, 动态的适应局域网和广域网。

4 应用效果

医院综合集成系统的成功上线和运行, 使得信息科人员从原有的繁琐工作中解放出来, 能有时间研究新技术, 以便更好地应用于医院信息化[6];医院各科室对信息科的满意度直线上升;系统稳定、好用, 提高了医护人员的工作效率;出现问题能及时处理, 信息科人员的工作压力大大减轻, 实现了运维效率的提升。

我院综合集成系统的成功运行, 为医院今后的信息化建设积累了宝贵的经验, 同时也对医院信息化建设中的信息孤岛和信息烟囱提供了一个解决办法[8]。我们深知, 医院的信息化建设不是毕其功于一役的, 而是一个艰苦而长期的过程, 在今后的工作中还要不断总结经验、不断改进, 使我院的信息化建设跟上医院发展的需要。

参考文献

[1]华永良.试谈中国医院信息化事业发展的激励因素和历经阶段[J].中国数字医学, 2013, 8 (1) :79-86.

[2]吴飚, 彭梦晶.中小医院信息化建设现状和发展趋势[J].中国医疗设备, 2010, 25 (6) :90-92.

[3]王志强.医院信息化建设面临的问题与对策[J].中国数字医学, 2007, 2 (12) :31-32, 35.

[4]言卓.我国医院信息化建设过程中存在问题与应对策略的探讨[J].实用预防医学, 2011, (10) :2022, 2018.

[5]李玉杰, 熊文举, 姜浩娜.基于SOA架构的医院信息系统集成[J].中国数字医学, 2008, (8) :54-56.

[6]许健, 查佳凌, 尤超, 等.医疗信息化集成平台在医院的建设与思考[J].中国医院, 2012, 16 (2) :5-8.

[7]陈功, 沈宫建, 于洁.医院系统集成平台建设内容和方法[J].中国数字医学, 2008, 3 (10) :58-60.

混合架构 篇3

JSP (Java Server Page) , 是一种方便有效的动态网页制作方法。在传统的网页HTML文件 (*.htm, *.html) 中加入Java程序片段 (Scriplet) 和JSP标记 (tag) , 就构成了JSP网页 (*jsp) 。所有程序操作都在服务器端执行, 网络上传送给客户端的仅是得到的结果, 对客户浏览器的要求最低, 可以实现无Plugin, 无Active X, 无Java Applet, 甚至无Frame。

1.1 开发环境

(1) 开发平台:Java;

(2) 数据库系统:Microsoft SQL Server;

(3) WEB页面设计:Dreamweaver[1];

94) 服务器:Tomcat

1.2 混合构架系统数据库的设计

Microsoft SQL Server是一个高性能数据库系统, 既能支持小型数据库, 也能支持企业级大型数据库。由于该数据库系统具有使用的方便性、可伸缩性和可扩展性, 所以SQL Server被广泛的应用。数据库备份是每一个数据库系统应用中的重要环节, 如何保证数据备份的安全性是一个值得研究的课题。

Microsoft SQL Server分布式数据库系统允许用户透明地操作远程数据库的数据, 可以把多个数据库满足多个工作组、部门或地区的需求连接在一起, 使应用程序看起来只有一个大型数据库。Microsoft SQL Server分布式数据库管理系统支持混合的网络拓扑结构, 还支持混合网络协议, 并自动地进行网络协议转换。

(1) 创建到另一个数据库的链接。数据库链接存放在“本地”计算机的数据字典内, 当使用时, 它作为远程数据库的用户帐户连接到指定的数据库。当操作完成后, 数据库链接退出远程的数据库。数据库链接的建立语句为:

其中:Linkname数据库链接的名称

Usemame用户帐户

password口令

connectstring远程数据库的连接串

连接串在SQL*NET2.X版中, 为远程数据库的别名。在SQL*NET1.X版中包括用冒号隔开网络接口驱动程序、服务器名称和数据库实例。在一个数据库内, 可以建立多个数据库链接分别指向不同的数据库。

Microsoft SQL Server的数据字典视图ALLDBLINKS包含连接用户所创建的公共数据库和私有数据库链接, 其结构为:

而数据字典视图VSERBLIND, 包含一个用户的全部私有数据库链接, 其结构为:

用户可用SQL查询语句去查看有哪些数据库链路是可用的。

(2) 访问远程数据库的数据。数据库链接建立好后, 即可访问远程数据库的数据, 使用数据链接的方式为:

SELECT coll, col2, ……FROM tablename@dbLink

在该查询语句中, 符号@指示该基表为数据库链接db Link所指定的存放在远程数据库中的基表。在应用程序中, 用户可以访问远程数据库的数据, 但当基表地址改变了, 用户希望不修改应用程序。这时, 可用同义词为应用程序提供地址的透明性。同义词的建立如下:

CREATESYNONYMsynoname

FOR tablename@dbLink

同义词在应用程序中隐藏了对象的实际地址。当基表移动时, 修改一个同义词定义要比修改应用程序中的所有对象引用容易得多。

(3) 使用快照。在访问远程对象时性能非常低时, 可以使用快照, 以提高使用远程数据库数据的应用程序的性能。创建快照需要Microsoft SQL Server的分布式选件。

快照可以基于多个基表的查询, 可按照预先设置的时间间隔定期自动刷新。建立快照的语句如下:

在进行大量操作前, 用户希望引用的快照的数据己经被刷新, 这时可在应用程序中用手工刷新快照。Microsoft SQL Server提供了DBMSsnapshot包允许用户手工刷新快照, 调用REFRESH过程如下:

DBMSSnapshot.Refresh (snapshotname, refreshtype)

其中:refreshtype刷新类型。若对所有快照进行刷新, 可用过程:

DBMSsnapshot.RefreshALL

(4) 远程内嵌过程。在远程数据库上执行内嵌的过程或者函数, 仅把执行结果返回本地应用程序, 可以降低网络负担, 改善远程数据操作的性能。建立远程内嵌过程和函数, 通过一个数据库链接执行一个远程的内嵌过程, 其调用语法为:

PROCEDUREname@dBLink

使用数据库链接前, 远程数据库连接的用户帐号必须有使用者所需的特权[2]。一旦数据库链路是可用的, 用户就可以通过链接执行远程操作, 而不必关心远程数据在什么位置。

1.3 Microsoft SQL Server 2000数据库备份策略

最佳备份策略取决于各种因素, 以下因素在确定一个好的备份策略时尤其重要:

(1) 如果存在一个可预测的非高峰时段, 则建议将完整数据库备份安排在此时段。

(2) 一天中应用程序访问数据库的时间有多长?

(3) 完整数据库备份需要多少磁盘空间?

(4) 如果更改经常发生, 请考虑下列事项:

(a) 可能只是更改数据库的小部分内容, 还是需要更改数据库的大部分内容?

(b) 在完整恢复模式下, 应安排经常的日志备份。在完整备份之间安排差异备份可减少数据还原后需要还原的日志备份数, 从而缩短还原时间。

(c) 在简单恢复模式下, 请考虑将差异备份安排在完整数据库备份之间。差异备份只能捕获自上次完整数据库备份之后的更改。

(d) 对于更改集中于部分文件或文件组的大型数据库, 部分备份和/或文件备份非常有用。

(5) 更改和更新可能发生的频率如何?

根据以上因素, 结合数据库系统的实际使用情况和备份设备的情况, 可制定一个完整的、科学的备份策略。

2. 系统实现

2.1 客户端系统用户登录

学校就业中心或学生处 (一级用户) 凭教育厅给予的院校用户名和密码登录客户端, 各高校下属院系 (二级用户) 则根据学校就业中心 (学生处) 设置的用户名和密码登录。

2.2 文件操作

2.2.1 页面设置

打印页面设置, 根据所连接的打印机设置相关参数。

2.2.2 数据导入 (生源信息)

将现有的毕业生生源信息导入院校端, 要求导入的数据库格式为dbase IV版本的DBF文件。如果现有数据为Excel格式或其他.dbf格式, 则需转换为dbase IV版本的DBF文件。具体操作为:

(1) 点击“文件”*“数据导入”*“导入生源信息”, 可得到数据导入/导出向导界面。

(2) 点击<下一步>得到图1。

(3) 点击<浏览>, 在文件对话框中选择需要导入的DBF生源信息库, 然后点击<下一步>得到图2。

(4) 选择导入数据库中的源字段与生源信息库中的目标字段相对应, 点击<下一步>得到图3的结束界面。

(5) 点击<完成>, 系统开始导入生源信息, 待全部数据导入完毕弹出界面4, 点击<确定>结束生源导入操作。

2.2.3 数据上传下载

Web服务器[3]设置无误后, 可以进行上传或下载生源信息、下载就业方案、下载各类代码表。

依次点击“文件”*“数据上传下载”*“生源信息上传”等进入相应操作提示界面。

点击“生源信息下载”可以保证学校的数据与教育厅处的数据一致 (若在“网上办公”里对生源信息有改动, 该功能可以把改动的数据下载到学校) 。

2.2.4 注销

点击“注销”, 当前用户退出系统操作, 进入用户登录界面, 可再次登录。

2.2.5 退出

点击“退出”, 结束系统运行。

2.3 生源信息操作

2.3.1 生源信息录入

此功能用于逐条添加生源信息。点击“生源信息”→“生源信息录入”, 进入“生源信息录入”界面, 录入各项内容后点击<保存>按钮即可完成生源信息的录入。

2.3.2 生源信息浏览和修改

此功能可以实现逐条查询和修改、删除生源信息。点击此菜单项进入浏览与修改。选中浏览条件, 点击<查询>可显示查询结果。若要修改某学生的信息, 选中该生点击<浏览>, 可对相关内容进行修改。如果该生信息未上传教育厅, 则按<保存>可以将修改后的内容保存到数据库;如果该生信息已上传教育厅, 则你无权保存修改的内容。若要删除某个学生信息, 可在查询结果表里选中该生记录, 点击<删除>完成删除操作。

3. 结论

在开发过程中, 在实现阶段我主要是负责做信息查询和报表统计, 由于本系统是基于Web的开发, 因此给代码的调试带来了很多方便。

通过同时进行不同层次的开发, 在面向对象的编程中, 我们作为软件编程人员应更加注重代码的重用性。设计模式使我们可以更加简单方便地复用成功的设计和体系结构, 进行面向对象的软件开发, 采用什么样的设计模式将显得尤为重要。另外, 由于该项目涉及到需要到用户处了解需求, 这其实是一个项目成功与否的关键所在。目前系统基本开发完毕。

摘要:随着我国高等教育的迅速发展和高校招生规模的扩大, 各高校的在校学生人数不断增加, 每年的毕业生人数也在剧增, 高校毕业生的就业工作已纳入到日常性工作之中。就业问题, 关系到我国经济建设、社会稳定和人民群众的根本利益, 关系到高等教育的持续健康协调发展, 是我们党的执政能力建设的重要组成部分。该课题对高校毕业生的就业工作具有积极的现实意义。一是可以规范操作、规范程序、规范数据, 便于准确、快速地进行数据处理;二是可以克服行政办公人手少、工作繁多等困难, 提高工作效率;三是可以及时地掌握毕业生就业的动态。

关键词:JSP,混合构架系统,高校毕业生,系统实现

参考文献

[1]Dreamweaver MX入门与提高。周家地, 肖小清编著。北京:清华大学出版社, 2002

[2]李修建.Web上多层Client/Server数据库系统的设计与实现.计算机工程与应用.2000.11

混合架构 篇4

受三星鹏泰公司委托,我公司为其开发一套基于现有E-Learning平台的Android手机客户端在线学习系统。我作为项目经理兼设计师主持了该项目各项工作,项目成果“M-Learning移动学习客户端”于2011年10月05日上线正式运行,该软件主要为三星公司全国促销及渠道人员提供各类移动设备技术和销售方面的培训服务。

2 系统架构

2.1 逻辑结构

本系统总体采用B/S架构,服务器端有数据存储模块、文件存储模块、E-Learning模块、M-Learning服务模块。客户端分为两部分:一部分是已有的电脑端在线学习功能模块,另一部分是Android手机客户端模块。其中手机客户端模块是本次开发的重点,它与服务器端的“M-Learning服务模块”实现各类数据交换及文件交换。这些数据交换功能既有B/S结构形式的程序实现,又混合着C/S结构的程序实现。而M-Learning服务模块与E-Learning模块很多数据实现了共享,例如:课程数据、试题试卷数据、每日应用推荐文件等。

2.2 部署结构

服务端由两台PC服务器和一个磁盘阵列组成,一台PC服务器提供Web服务和流媒体服务,上下载带宽为100MB/s。另一台PC服务器安装了Oracle10g数据库软件,提供数据存储服务,此服务器安装了Linux操作系统主要是考虑保证提供较高的数据访问并发性指标;磁盘阵列500G,用于存储数据库文件、培训资料文件等重要数据,采用集中备份策略。Web服务器对外提供80端口http服务、21端口ftp服务及554端口流媒体服务,其中apache负责接收处理80端口请求数据和实现动静分离,以提升系统对外服务性能,weblogic负责解析jsp及servlet请求、处理后台业务逻辑及数据存取;DB服务器没有外部IP不对外提供服务,而只与Web服务器通过内网相连,保证安全性,如图1所示。

3 设计与开发

3.1 设计思路

首先,使用Axure工具进行原型设计,原型可以模拟简易的UI样式、内容展示和操作顺序,给客户方讲解功能如何实现比较直观。然后由美工针对典型页面设计效果图,设计出来再与客户方确认。与此同时设计模块逻辑结构和交互方式、接口格式。

3.2 客户端设计

3.2.1 针对不同操作系统版本、不同分辨率

由于采用了OS版本自适应算法、分辨率及横竖屏自适应和不同机型自适应算法,这个app不区分HD版和普通版,平板手机都可以安装、大屏小屏不同分辨率都可以自适应显示。

3.2.2 针对UI占用太大空间

由于客户端功能数量较多,页面图片也较多,如果每个布局和分辨率一套图片,那么apk文件大小将达到50M,因此采用了Android规范UI设计,通过较少的、符合UI规范和格式(PNG)的图片就可以适应绝大多数机型和分辨率,做到最小失真。最终的程序包大小稳定在5M左右,更新下载安装很方便快捷。

3.2.3 针对手机学习特殊性而进行的课件格式

由于在线培训所涉及的课件较多、较大,在手机中观看遇到的直接问题就是屏幕小、流量少、网速慢。如何解决这个问题?采用下述方法:首先,将较大的scorm课件进行精简,多余篇章直接去掉,有些篇章内容进行压缩,制作成flash格式小课件。这样一来,课件文件大小减少了、字体按钮都变大了,适合在手机屏幕播放和点击操作,在提高了流畅度的同时也大大减少了下载流量。

3.2.4 针对程序和内容文件分离

由于产品介绍内容是不定期发布的,促销员会经常打开观看,因此采用离线下载方式节省流量、提高流畅度。Apk程序和产品zip文件分离,apk中只包含数据库和程序,产品介绍内容打包成zip由apk运行时自动检测下载,每个zip都在1M-3M之间。每个产品介绍内容之间也都是分离的,这样实现了单个产品信息被管理员修改后手机客户端可以局部更新下载节约流量。

3.3 系统实现

手机客户端的开发不同于传统B/S架构系统开发,主要在于服务器端程序开发人员与手机端程序开发人员需要及时和准确的沟通,需要多次试验并最终确定功能实现方式;手机开发人员还需要与美工进行大量沟通、尝试修改工作,以试验10多种不同分辨率、尺寸和型号手机的显示效果,同时也需要试验不同操作系统版本,检查样式问题、内存使用问题等。产品的开发过程采用演化模型法,即针对核心功能先开发出来试验效果,及时给客户演示并听取修改意见。经过多次修改完善,手机客户端程序包含所有功能演化到最终版本。

4 功能介绍

4.1 E-Learning

该部分为基础系统,主要功能模块:系统管理、数据管理、资源管理、培训实施、报表管理、网站发布管理、在线学习、在线考试等;其中在线学习和考试为学员角色具备的功能,学员可以使用电脑连入互联网实现在线学习课程、在线答卷考试。

其中,数据管理模块中的企业机构数据、人员数据和岗位角色数据,资源管理模块中的课程数据及课件文件、试题试卷数据、应用推荐数据和文件在M-Learning服务模块中进行了复用。

4.2 M-Learning

该部分为系统扩展开发部分,分为服务器端和手机客户端。服务器端提供服务:登录验证、检索在线课程及考试数据、记录手机学习信息和手机考试信息、提供应用推荐下载、培训管理和培训报表填写上报、通知信息编辑和发送等。

手机客户端功能(图2):产品介绍模块、行业知识模块、应用推荐模块、在线学习模块。

产品介绍模块(图3-图5):该模块以信息推送形式为三星全国促销员提供最新、最准确的产品信息。当促销员打开app后,客户端自动检测网络,如果连接网络则与服务器进行数据同步。当发现有最新的三星电子产品(例如Note2、Galaxy S4)发布时,自动提示是否下载最新产品资料。每个产品资料文件zip约1-3M,包含“产品介绍、如何给顾客讲解、产品配件信息、与竞争机型的对比信息、短视频资料”。当选择下载后,app程序进行后台下载、自动解压并更新手机内的产品资料数据库信息。再次进入产品介绍模块后,显示最新产品图标“NEW”:点击进入查看详细产品资料。通过分类按钮可以切换到“智能手机、智能平板、智能迷你本”等不同机型。

行业知识模块:该模块以信息推送形式为三星全国促销员提供最新、最流行的行业知识。其形式与产品介绍模块类似,栏目有所不同。展现形式为书架,可以上下滑动,点击图标进入。其子栏目可以由管理员自己配置,一般为1~3个。

应用推荐模块(图5):该模块是最简单的一个模块,其主要是为促销员可查看最新应用程序,并直接下载apk进行安装。展现形式为多级列表+详情介绍页面。其页面内容都在服务器端生成,而不是下载到手机本地后用内嵌浏览器打开观看,因此该模块的功能调整和页面修改不用客户端下载更新包更新。

在线学习模块(图6):该模块是最复杂的一个模块,其主要功能为:在线学习、资料下载、在线考试、SNS互动社区、讲师管理培训项目与学员参与培训项目。另外,管理员手机端管理功能包括:讲师管理、通知管理、培训报表。其中SNS社区是电脑Web版本的简化版,主要是方便手机小屏幕浏览和互动操作。SNS社区主要功能为:心情、日志、投票、相册,通过客户端可以互动交流、分享照片。

5 遇到的技术问题及采用的关键技术

5.1 技术选型

在开发过程中不断会遇到技术选择,在解决内容浏览方式的问题时,由于当时(2011年)HTML5技术还不太成熟,因此在技术选型中未选择HTML5技术。在课件内容是选用MP4还是flash的时候,我们考虑到观看流畅性和手机下载流量,最后仍采用了flash形式。Android新版本发布后采用了变通的方式实现了flash在3.1、4.2以上版本流畅播放。

5.2 问题举例

问题一:高版本Android系统内嵌浏览器不支持flash。由于flash存在安全漏洞问题、费电问题,Android新版本的内嵌浏览器chrome不再支持flash。在课件播放模块需要用到内嵌浏览器播放在线课件,课件形式为flash。根据技术分析的结果,不同Android版本采用了不同的打开策略:2.3-3.0版本采用内嵌浏览器直接打开课件,3.1-4.2及以上版本采用弹出手工选择第三方浏览器(UC支持flash播放)方式打开课件。两种方式都不影响播放质量和学习计时功能。

问题二:功能界面较多与开发工期不足之间的矛盾。根据功能特点分析,我们将一部分功能使用内嵌浏览器本地打开或远程打开方式,模拟B/S的通用方式。这样,功能界面可以由普通界面开发工程师完成,功能调整也比较方便;需要流畅操作的功能或页面由开发Android原生程序的手机工程师完成。我所采用的方式得到了客户的同意,同时节约了开发成本和工期(手机开发工程师成本远高于普通界面开发工程师)。在后期系统维护工作中也得到了很好的效果:apk不用频繁修改和下载重新安装,而只需要修改服务器端的jsp就可以实现界面更新。

问题三:数据接口设计非常关键,因为该系统采用的是B/S和C/S混合方式,接口数量多且复杂。考虑到为了减少以后的变更难度,部分固化接口采用JSON格式数据通过Servle收发;部分与更新相关接口采用配置文件方式,文件内容格式可以随意配合手机端程序更改,而不用修改服务器端程序。

以下是手机客户端各功能模块所采用的关键技术一览表,如表1所示。

6 结语

混合架构 篇5

关键词:移动应用,混合模式,软件架构

移动应用的发展和开发模式

2000年,中国移动互联网诞生,2010年已被业界普遍认为是移动互联网的元年。从2000到2010的十年时间里,中国移动互联网呈爆发式发展,使得在移动终端上使用各种互联网应用渐渐成为一种习惯。移动应用的发展激发了广大开发者进行移动应用创作的极大热情。目前,移动应用开发方式主要分为三种类型:原生开发模式、移动Web开发模式和混合开发模式。

原生开发模式使用移动终端操作系统所支持的程序语言来编写移动应用。目前市场上移动终端操作系统有很多种。因此,要使用原生开发模式开发出一款能够适用于各种操作系统的原生应用,开发者需要花费大量的时间和精力来进行平台间的移植工作,这就决定了采用原生开发模式进行移动应用开发具有周期长、开发门槛高、开发成本高、不跨平台等缺点。当然,原生开发模式也有优点,它可以访问移动终端的所有功能,速度更快、性能更高、用户体验更好,等等。

移动Web开发模式使用传统的Web开发技术进行开发,通过移动终端浏览器进行访问。较原生开发模式, 它具有开发周期短、开发门槛低、开发成本低、跨平台等优点,但是移动Web应用是基于浏览器的,无法调用移动终端系统API来实现一些高级功能,用户体验差。

混合开发模式采用Web开发技术,通过中间件包装成各平台的应用程序,可以通过中间件的集成,调用大部分常用的移动终端系统API。因此,混合开发模式同时具有原生开发模式和移动Web开发模式的优点,即具有跨平台、开发门槛低、开发成本低等优点。

校园移动应用发展现状

目前国内各大高校基本完成了校园无线网的基础设施覆盖,为移动终端开展各项应用打开了方便之门。但就目前的情况看,校园的移动应用还存在一些问题,成熟的校园移动应用很少,部分校园移动应用是由学生团体自发组织进行研发,研发过程缺乏统一的规划和科学的工程性管理,可维护性比较差,难以实现可持续发展。要想使校园移动应用更好地、持久地服务于广大师生,就需要构建一个校园移动应用软件架构,学生通过简单的学习就可以进行校园移动应用的开发和维护工作,这样就可以保持移动应用的研发团体相对稳定,也可以保证校园移动应用的可持续发展。

校园混合模式移动应用软件架构的构建

混合开发模式具有开发门槛低、 跨平台开发的优点,是今后移动应用开发的主流,也是进行校园移动应用开发的首选。但目前采用混合开发模式的校园移动应用较少,大部分应用仍处于摸索阶段,并没有形成成熟的技术体系。 因此,在对基于HTML5的混合开发模式研究的基础上,我们构建了混合模式移动应用软件架构,并应用此架构进行校园移动应用的开发,力求通过使用该架构,探索出校园移动终端应用开发的新途径。

基于混合开发模式的混合移动应用软件架构分为服务器端业务逻辑处理和移动应用UI设计两个部分,如下图所示。

1.服务器端业务逻辑处理

服务器端业务逻辑的处理我们采用了MVC设计模式,在具体的处理上, 采用了Spring MVC框架和My Sql数据库。为了便于移动应用的数据显示,架构采用了JSON数据交换格式。通过配置Jackson类库,实现JSON的输入和输出, 并在此基础上提供了WEBService接口, 将处理后的数据转化为JSON格式。采用Spring MVC中的@Response Body将JSON数据传递给客户端。这里重点介绍Spring MVC配置、数据库操作和JSON传递的实现方法。

(1)Spring MVC配置

在Java Web项目中导入Spring的类库集,并按照如下内容的配置web. xml文件。

其中Dispatcher Servlet是前端控制器设计模式的实现,提供Spring Web MVC的集中访问点,而且与SpringIOC容器无缝集成。然后在spring-servlet.xml文件中配置数据库、注解、反射、 国际化,并创建Controller、 Service、Dao的相关基类,用于被未来MVC中使用的类来继承,通常情况下,基类中配置了日志处理,基本的增、删、改、查的方法,便于最大范围地实现多态。

(2)数据库操作

Spring MVC的Dao层和Service层是处理数据库操作和业务逻辑功能的部分。通过Dao层完成针对数据库系统的增、删、改、查,通过Service层进行业务判断。通过继承Jdbc Dao Support类定义Dao基类,再针对每一个数据结构定义自己的Dao类,这样便于数据独立性的处理,也可以为持久化奠定基础。

(3)JSON传递

Spring MVC支持JSON,一定要引用jackson-core-asl和jacksonmapper-asl的类库,并在Spring的配置文件中,增加如下配置。

在服务器端定义如下JSON数据类。

通过Controller类中的方法将数据JSON化。在Controller类中,定义 @Response Body,直接将Json Data实例传递给客户端就完成了JSON数据向客户端推送。具体实现代码如下:

除上述关键点以外,考虑到服务器端向外提供接口的时候,有信息安全的要求,在客户端访问服务器端接口的时候需要通过HTTPS协议进行安全认证,并遵照软件架构的自身要求进行协议握手认证,这样就防止了校园关键信息的泄露和恶意攻击。

2.移动应用UI设计

我们的移动应用UI设计部分采用成熟的JS组件与原生API混合形式进行,当进行普通画面显示的时候,采用HTML、CSS3和JQuery Mobile技术, 当需要设备端功能的时候,调用原生API。这里重点介绍获取并显示JSON数据、本地存储和移动应用界面效果的实现方法。

(1)获取并显示JSON数据

在移动应用端获取JSON数据,通常采用ajax方式,这样客户的体验感受会更好,配合Loading的显示,整个移动应用端非常流畅。JQUERY提供了非常完善的ajax方法。下面代码是在Id为show_div的div中显示JSON数据的实现方法。

(2)本地存储

为了保证用户在离线的情况下,可以查看本地已经下载完成的数据信息, 如校园的新闻信息、课程信息等,需要将一些数据信息保存在本地,保证非实时在线的情况下应用是可用的。我们采用HTML5的存储方式,存储少量数据的时候,使用Local Storage来实现, 如果存储的数据偏大,使用Web SQL Database来实现。通过HTML5操作Web SQL Database的open Database、 transaction、execute Sql三个基本方法,分别规定了数据库打开、事务处理、 执行SQL语句的使用方式。我们定义了基本的客户端数据库结构以后,通过这些基本方法操作数据库将信息保存在本地。

(3)移动应用界面效果

通过JQUERY Mobile实现客户端的界面效果,主要是将一个应用中的多个Page实现出来,再经过各种效果的页面跳转,构成整个界面风格的主体。

Page是JQUERY Mobile的重要组成部分,由data-role="page"属性产生,每个Page由header、content和footer组成(不是必须的),配合JQUERY Mobile提供的标准控件,构成一系列常用的Page库,这个Page库就是移动应用的UI框架。当然作为后续扩展开发者,可以自定义Page来实现自己的应用界面。

将上述这些功能集成为一套功能集合,就形成了一个混合模式移动应用软件架构的雏形,在此基础之上,开发人员可以更多地关注业务本身,而不需要考虑底层的技术问题,这样既保证了应用的完善性,也将共通性功能进行了最大化的资源共享。

结语

混合架构 篇6

关键词:全媒体应用,混合云,平台服务层,软件应用服务层

0引言

随着互联网技术和云计算技术的快速发展,全媒体应用技术平台的设计呈现出互联网化、云化和专业化的特性,其中,互联网化和云化体现在平台的构建开始选择基于公有云+私有云的混合云架构,充分利用遍布海内外的公有云资源提供的IT基础设施服务,专业化体现在媒体应用技术平台服务层的设计充分考虑媒体行业属性,不再局限于原有的通用平台服务层功能,正朝着媒体专业化的方向演进。

本文基于“中华云(新型全媒体融合平台)”项目设计实例,结合中国国际广播电台全媒体业务需求,阐述了全媒体应用技术平台混合云总体架构、媒体专业平台服务层设计和媒体软件应用服务层设计方案,其中,平台服务层向下对接基础设施服务层提供混合云基础资源的统一调度,向上对接软件应用服务层提供全媒体业务支撑及生产加工能力,内部功能模块及工作流程提供符合媒体行业业务特性的基础服务能力,并引入运营支撑服务能力;软件应用服务层构建支撑国际台全媒体业务端到端全流程的软件应用系统,满足用户随时随地访问和使用全媒体应用技术平台的业务需求。

1全媒体混合云总体架构设计

全媒体应用技术平台基于混合云架构设计,平台分为基础设施服务层、平台服务层和软件应用服务层。其中,平台服务层在本文中为带有媒体行业特色的专用平台服务层,软件应用服务层为满足国际台全媒体应用的软件服务平台。

基础设施服务层在全媒体应用技术平台中为基础云环境,既可配置为阿里云、腾讯云等公有云环境,也可配置为基于Openstack平台的私有云环境,或者为多种公有云+私有云的组合。全媒体应用技术平台运营商可根据具体情况选择使用不同种类、不同厂家、不同技术的云服务,并可实现对整个云环境的统一管理,异构云平台资源的同构以及业务的跨平台协同工作等。

平台服务层是全媒体云平台的核心层,它与基础设施服务层对接,提供对底层资源的统一管控调度,实现对异构云平台的统一管理;它与软件应用服务层对接,通过标准的API接口为软件应用服务层提供媒体内容采集、生产加工、管理发布以及多终端展示等软件服务,便捷完成基于音视图文的应用开发。平台服务层设计紧密结合了媒体行业专业技术需求,可作为通用的媒体专业平台服务层。

软件应用服务层直接为平台用户提供软件服务,紧密结合国际台全媒体、多语种、多渠道全球发布等具体应用需求,设计了支撑国际台全媒体业务全流程的软件应用服务,包括融合媒体汇聚系统、全媒体文稿系统、全媒体媒资系统和全媒体发布系统,系统功能、流程配置灵活,新功能研发快捷,基础媒体处理能力可直接调用平台服务层提供的API实现,满足用户随时随地使用全媒体云服务的需求(图1)。

2媒体专业平台服务层设计

2.1平台架构

平台服务层由MW (中间件)、CSE (云服务引擎)、BSP(基础能力服务平台)、BSS(运营服务系统)和API(标准接口)组成。媒体专业平台服务层技术架构如图2所示。

1.MW

对基础云服务的统一封装和协议转换,适配不同云服务提供商的开发接口,为上层平台提供一个标准化的开发环境,构建统一的基础云服务资源池,消除不同技术、协议之间的差别。

2.CSE

对基础云资源池中的资源进行管理和统一调度,包括虚机管理、云存储管理、数据库管理、CDN管理等。

3.BSP

提供包括音视图文的加工处理、管理发布等基础核心服务能力,实现基础服务能力的注册管理,包括服务的注册、上线、下线、启动、停止等。

4.BSS

对整个系统进行计量、计费、控制、管理等,并承载用户管理,产品定义以及业务结算和收费等功能。

5.API

是对接软件应用服务层的标准接口层,提供各个系统的Rest API。

2.2平台工作流程

平台工作流程如图2中箭头指示所示:

1.流程:媒体专业平台服务层通过MW (中间件层)的设计,将不同来源的云平台和CDN服务转化为统一标准的接口,提供给CSE (云服务引擎层)进行基础资源管理。

2.流程:CSE提供强大的资源管理功能,包括集群管理、镜像管理、快照管理、实例管理、虚机管理等,可根据实际需要在线灵活调整虚机配置和带宽,提供多种资源弹性管理策略,实现按需使用和按需收费,并提供生成快照-生成镜像-创建实例-创建集群-配置弹性管理策略-将实例添加到集群-启动实例这一标准化的快速产品服务部署流程。

3.流程:BSP (基础服务层)提供工具、产品、服务的注册、上线、下线、启动、停止等操作,既包括上传、转码、技审、拆条、打点、快编、非编、打包合成等平台自带的基础服务包,也兼容集成第三方产品及服务,并为各服务提供统一的运行环境和接口服务,为新上线服务提供服务注册-服务测试-安装部署-回归验证这一标准化服务部署前准备流程。

4.流程:BSS (运营支撑层)提供对产品及服务运营相关的全流程管理,为上线的产品及服务提供一系列产品管理功能以及相关的客户管理、结算管理、收费管理和业务报表等运营功能,设置业务处理-处理日志-收费标识-服务价格-订单批价-收费明细-结算账单这一规范化运营管理流程,并为调用接口层各类API的应用系统提供运营支撑服务。

5.流程:开发软件应用服务层应用系统时,除调用接口层的各类API之外,还可通过API直接调用基础服务层中部署的独立工具及服务模块,避免重复开发。

6.流程:运营支撑层的业务报表管理不仅针对部署在平台上的系统、产品及服务输出业务报表,还对云基础资源的计量进行业务报表输出。

媒体专业平台服务层设计满足了媒体对于互联网信息的需求,海量内容加工处理需求,新业务快速开发部署需求,第三方产品快速集成需求,业务运营管理需求、专业化人员多地协同作业需求以及渠道、多终端发布的需求。

3媒体软件应用服务层设计

基于媒体专业平台服务层提供的服务能力,构建支撑国际台融媒体业务端到端全流程的软件应用服务层应用系统,设计包括融合媒体内容汇聚系统、全媒体文稿系统、全媒体媒资系统和全媒体发布系统在内的“采制播存管”全媒体业务一体化应用技术平台。基于混合云资源构建的应用系统可满足用户随时随地的访问和使用需求。

3.1融合媒体内容汇聚系统

3.1.1系统定位

融合媒体内容汇聚系统是获取全媒体信息资源的统一入口和支撑全媒体业务生产的基础信息平台,通过开放多个接口与互联网信息抓取、文件收录、直播流收录、素材回传等采集收录系统进行对接,整合各渠道信息资源,支撑全媒体制播流程中的“采集”需求,同时,为了保证信息统一获取的便捷性,将全媒体文稿系统中的台发稿件部分和媒资库内容引入汇聚系统进行统一检索调用。

融合汇聚系统基于汇聚的海量媒体内容,提供热点事件、热门微博、热门词汇、专题汇聚、个性化推荐、关联新闻等大数据分析工具进行数据挖掘,为用户提供直观的信息展现,并与全媒体文稿系统、全媒体媒资系统、发布系统进行系统对接,输出信息资源,使信息可通过提取、引用、推送、发布等方式进入其它系统进行业务流转和处理,充分体现其信息获取统一入口的作用。

融合汇聚系统与其它系统之间的逻辑关系如图3所示。

3.1.2系统设计

融合媒体汇聚系统由内容汇聚、专题汇聚、个性化推荐和个人空间四大业务板块组成。

内容汇聚是核心业务板块,由内容检索区、内容列表区、内容详情区和热点新闻区构成。内容检索区展现互联网汇聚、外电回传、素材回传、媒资库和文稿系统五大汇聚来源,提供按照语种、时间、地点等检索标签进行的二级检索功能,检索标签根据我台业务需求进行灵活自定义。其中,互联网汇聚检索标签包括站点、分类、低于、语种、时间类型等;外电收录检索标签包括来源、语种、时间、类型和挑选状态等;素材回传检索标签包括记者站点、时间、类型和和挑选状态等;媒资库检索标签包括中心(部门)、分类、类别、时间和类型等;文稿系统检索标签包括中心(部门)、分类、低于、类别、发布、时间和类型等。此外,内容检索区还提供全文检索和递进式检索等功能。内容列表区是逐条全媒体内容的缩略展示区,带标题前标识(标识内容用途、覆盖范围等特征)和标题后标识(标识内容包括的媒体形态),展示每条全媒体内容的关键词并提取内容简介,并提供“标签”、“挑选”、“收藏”、“推送”、“发布”、“引用”和“下载”八项操作。其中,“标签”为用户提供对内容手动打标签的功能,标签可供内容检索使用;“挑选”集成音视频简编工具和可灵活配置元数据项的初级编目页面,为用户提供简单的内容编辑功能;“收藏”提供了将汇聚内容保存在用户“个人空间”中的接口;“推送”可将选中内容推送至媒资系统进行长期归档;“发布”可将选中内容一键发布至发布系统中,完成新媒体快捷发布;“引用”支持将选中内容复制至文稿系统中进行后续的全媒体文稿编辑;“下载”支持打包下载全媒体内容源文件,包括音频、视频、图片和DOC文档等。此外,内容列表区还提供“相关新闻”功能,它通过内容标题切词后进行匹配,并按匹配度排序,将与当前内容最相关的五条内容罗列在“相关新闻”区域,并可刷新替换及直接点击跳转进行浏览。内容详情区是全媒体内容的详情展示区,为提升用户浏览体验,所有渠道汇聚的内容都进行规范化排版处理,并提供“热度趋势图”、“媒体统计图”、“关键词的相关新闻”和“热门评论”等功能。其中,“热度趋势图”和“媒体统计图”分别展示各大媒体(可配置)对该条新闻主题在某一时间区间内的报道热度和报道次数;“关键词的相关新闻”显示5条与该关键词相关度较高的新闻;“热门评论”从互联网抓取该内容的相关评论,可显示评论人昵称和评论内容。热点新闻区通过后台大数据分析挖掘功能提供“APP推送热点新闻”、“热点事件”、“热门微博”和“热词推荐”等功能,便于用户第一时间获取最热门新闻事件的相关信息。

专题汇聚是根据业务需求手动设置关键词,将相关内容汇聚成一个专题为用户提供内容聚类服务,用户可随时根据当前报道热点进行专题汇聚,快速获取大量相关内容;个性化推荐是内容汇聚和专题汇聚的补充,系统根据用户预先设置的关键词或用户行为自动给用户推荐内容,用户行为包括用户一个时间区间内的浏览操作情况(收藏、引用、下载、推送等)及检索关键词判断其关注点,个性化推荐列表以相关度从高到低排序。

个人空间为用户提供了灵活的内容上下载交互区,在用户终端和汇聚系统之间的交互上,支持PC-WEB和手机APP两种内容上传方式,上传的内容均在个人空间中“我的上传”目录下展示;在精编工作站文件存储目录和汇聚系统之间的交互上,提供自动和手动同步两种云盘同步方式,支持灵活的音视频精编工作流程。

3.2全媒体文稿系统

全媒体文稿系统是紧密结合国际台全媒体业务工作流程打造的全媒体内容生产系统,不再局限于原有文字稿件的制作,而是在定制化流程下支持音频、视频、图片和文字的富媒体内容编辑制作发布。

3.2.1系统定位

全媒体文稿系统与其它系统的逻辑关系如图4所示,支持从融合汇聚系统获取稿件、新建稿件以及从本地上载内容等信息输入方式,以应对不同的业务场景。经过文稿系统处理完成的稿件,可输出至融合汇聚系统进行统一检索展现,也可根据业务需求选择发布渠道进入全媒体发布系统,对于需要长期存档的稿件,在汇聚系统统一推送至媒资系统存档,文稿系统不单独开放存档接口,简化工作流程。

系统设计了“任务”、“稿件”、“串联单”三条稿件内容生产相关的业务主线。“任务”业务线支撑海内外记者约稿、任务分配调度和执行进度追踪,并通过任务收发机制,建立即时通信的信息沟通渠道;“稿件”业务线支撑全媒体文稿内容的全流程制作,“串联单”业务线支撑国际台各子媒体、各频率、各语种全媒体内容的节目单制作,用以辅助内容播出,本文重点介绍“稿件”和“串联单”两条业务线。

3.2.2系统设计

1.“稿件”业务线

文稿系统“稿件”模块包括“新建稿件”、“我的稿件”、“稿件处理”和“全部稿件”区域。“新建稿件”区域用于新建全媒体稿件,提供支持音视图文编辑的富媒体文本编辑区,根据业务需求设置稿件类型、发布范围等配置字段,集成视频、音频快编工具和图片裁切工具,可在编辑区内完成音视频剪切、合并等简编操作,合成新的文件插入文稿中。“新建稿件”区域支持“CRI可见”和“内部可见”两种公开状态,用于支撑发台内通稿和部门内部稿等业务场景。新建稿件是稿件处理流程的驱动,支持配置固定流程或自由流程进行稿件的后续审核,对于有特定权限的用户,可以直接发布至成稿状态。其中,固定流程为用户配置预先设置的固定角色,如编辑、翻译、审核、专家审核,稿件处理人在处理完本环节工作后,将稿件提交至下一环节的相应角色处理,如本环节需打回至上一环节,可选择退回,将稿件打回至上一环节或稿件起草人,该流程适用于部门内有明确职责分工、人数较多的语言部门或媒体;自由流程比固定流程更加灵活,用户可以自主选择稿件下一环节的执行人,且环节的个数可根据具体业务需求自由选择,直至稿件发布。“我的稿件”区用于追踪由我创建的稿件的状态,可实时查询我的稿件目前是处于原稿、编辑、翻译、专家审核、审核还是成稿状态。“稿件处理”区是用于存放用户所在部门各个状态稿件的区域,包括该部门用户生产的从原稿、编辑、翻译、专家审核、审核到成稿所有状态的稿件,并通过特殊标识区别稿件是否需要处理以及是否是当前用户需要处理的稿件,使用户实时接收和处理稿件任务。“全部稿件”区用于存放在新建稿件时标识为“CRI可见”的稿件,便于用户相互间共享稿件资源,也用于区分标识为“内部可见”的稿件。

“稿件”业务线的逻辑设计基于国际台全媒体文稿生产的业务需求,为满足不断变化的细节需求,在软件设计上使后端系统具备强大的流程和数据配置功能,极大地降低了前端页面和后台管理的耦合性。

2.“串联单”业务线

文稿系统“串联单”模块包括“新建串联单”、“我的串联单”、“待处理”和“全部串联单”区域。“新建串联单”区域用于新建串联单,通过设置各个栏目的标题、开始时间和结束时间制定某频率或子媒体某一时间段的节目单模板,用户可在模板有效期内在栏目下添加节目稿件,节目稿件可按需从汇聚系统,本地上传或个人空间选取,系统可自动计算节目时长,并根据每条节目的时长计算出栏目总时长及与标准栏目时长之间的时间差,提醒用户补充或删除修改节目。“我的串联单”区域用于存放我所创建的串联单,可对串联单进行模板修改,有效期修改等操作,并可对串联单进行打印。“待处理”区域用于存放需要当前用户审核或补充的串联单。“全部串联单”区域用于存放当前用户所在部门权限可见的串联单或“CRI”可见的串联单。

“串联单”业务线是基于CRI原文稿处理系统中的“电台”模块进行的扩展设计,扩展了稿件插入来源范围和稿件插入类型,引入了稿件时长自动化计算,增加了串联单审核流程等,更加符合全媒体节目串联单使用需求。

3.3全媒体媒资系统

3.3.1系统定位

全媒体媒资系统是全媒体资源进行有效存档和再利用的统一入口,它整合媒体资产,是全媒体业务生产的内容仓库,满足全媒体制播流程中的“存取”需求。系统具备新媒体资源存档和访问的快速、便捷、随时随地等特性,整个媒资管理和检索再利用过程灵活高效,并通过集成各种媒体处理工具,支撑对全媒体内容的管理。同时,为实现媒体资产的高效交换,开放多个接口,可与其它媒资系统进行对接和数据交换。

全媒体媒资系统与其它系统之间的逻辑关系如图5所示。

全媒体媒资系统数据来源为融合媒体内容汇聚平台推送资源,同时提供了批量上传/导入视音图文全媒体文件和编目文件的功能。上传完成的文件自动进行转码,转码成低码率供预览使用,在资源管理区域提供编目、快编、技审、打点等多媒体处理工具,编辑完成的文件可提交审核,审核通过的即进入发布资源列表,审核不通过的则返回至我的资源列表进行修改。发布资源列表的内容可下载到本地,并自动同步到融合媒体汇聚平台中供检索。

除此之外,系统还提供了统计报表、用户权限管理、编目模板设置、转码设置等功能。

3.3.2系统设计

全媒体媒资系统包括“资源管理”、“系统配置”、“数据报表”三个主业务区域。

“资源管理”区域承载全媒体媒资业务全流程,由我的资源、中心资源、审核资源和发布资源构成。我的资源列表存放当前用户上传并进行媒资处理的媒体资源,并为每条媒体资源提供编目、快编、打点、技审等操作,编目页面支持视频、音频、图片等多种类型文件编目,可根据不同的文件类型自动匹配编目模板,编目模板可根据具体需求进行灵活设置,编目时的输入语言支持中、英、法、俄、德等多语种语言。此外,我的资源列表为处于不同生命周期的媒体资源标记全部、处理中、处理失败、处理成功、待审核、审核中、审核未通过、审核已通过共八种状态,其中处理中,处理成功,处理失败用于标记媒体资源上传、转码是否成功的状态;待审核、审核中、审核未通过、审核用于标记经过媒资编目和编辑处理后的媒体资源提交至审核阶段后所处的状态。我的资源目录下集成了“上传/批量导入功能”,系统会对上传成功的全媒体文件自动分析其视音频文件的媒体属性,包括文件格式、码率、大小、时长等,并能自动读取图片的exif信息,上传完成后的视频文件自动转码成分辨率为720×405,码率为800kbps的低码率flv文件供预览,上传功能使用html5+插件技术实现,支持不同操作系统和浏览器,并支持文件断点续传功能。中心资源列表为用户提供媒体资源共享功能,可检索查看用户所在中心其它用户上传的内容,默认情况下,用户可以查看自己所在中心的资源,具备一定权限的管理员可查看所有中心的资源。审核资源列表中存放我的资源列表中提交审核的内容,审核完成的内容自动移出审核资源列表,审核资源列表中仅为其中存放的内容标记待审核、审核中两种状态,并为每条媒体资源提供审核、批量审核两种操作。发布资源列表用于存放审核通过的资源,为每条媒体资源提供查看、退回两种操作,发布资源列表将自动同步至融合汇聚系统进行统一检索。

“系统配置”区域是媒资系统功能及流程的核心配置区,包括字段配置、编目模板配置、流程配置和转码设置。其中,字段配置提供了自定义编目字段功能,可根据具体需求明确字段名称、字段形式(手动输入、下拉框式、多选框式、日期控件等)、分类(成品、素材等)、长度限制等关键信息添加编目字段;编目模板配置可根据新增或变更的编目需求重新设置编目模板,可为不同节目类型、媒体类型的内容设置不同的编目模板;流程配置支持可视化的流程配置,通过排列组合开始、转码、编目、技审、审核、发布、结束等功能模块进行流程设定,并可对各个功能模块进行参数设定,设定好的流程通过消息机制实现。

“数据报表”区域提供了媒资情况统计、工作量统计和媒资数据统计,统计数据可按需进行配置。初次配置时,媒资情况统计包括某一时间区间内媒资浏览量(点击查看详情页的次数)及媒资使用量(引用、下载的总次数);工作量统计包括统计特定用户上传、下载、快编、审核、技审、打点操作的媒资数量;媒资数据统计包括媒资格式、媒资大小、媒资时长和媒资数量统计,上述各项数据统计皆提供图片或EXCEL表格导出统计数据功能。

3.4全媒体发布系统

3.4.1系统定位

全媒体发布系统是全媒体云平台的信息输出平台,可将融合汇聚系统和全媒体文稿系统中的内容发布至各个不同的业务渠道,通过与网站CMS、APP、社交媒体、视频网站或其他第三方发布渠道的对接,实现内容的统一快速发布。

全媒体发布系统具备发布内容适配、发布内容审核、发布渠道账号配置功能,通过与第三方开放接口对接,将内容和多发布渠道串联起来,用户可通过一个系统实现内容的多渠道的发布(图6)。

3.4.2系统设计

全媒体发布系统包括渠道及账号配置、稿件发布、平台接入和后台管理四大功能模块。

渠道及账号配置模块实现发布账号绑定和账号授权功能,通过设置发布账号、账号名和第三方接入平台提供的appid和密钥配置发布渠道,选择发布渠道绑定用户账号,使绑定用户拥有使用该发布账号进行发布的权限。

稿件发布模块支持根据发布内容类型进行图文类(微信、长微博、CMS、APP等)、短消息类(短微博、twitter、facebook等)、视频类(优酷土豆、爱奇艺等)三种方式的发布。为了延续用户在原内容管理系统的发布习惯,稿件发布模块针对不同发布渠道设计了不同的内容编辑发布页面,以发布至微信公众号为例,稿件发布模块支持发布账号选择、图片/图片组、本地上传封面、标题、内容编辑发布,集成了微信公众号后台CMS的主要发布功能;以发布至微博为例,稿件发布模块支持长微博和图文两种发布类型切换,发布账号选择、标题、内容、素材展现;以优酷网站为例,稿件发布模块支持发布账号选择、标题、简介、标签、类别、内容编辑功能。此外,三种发布方式都支持“提交发布”,即提交给具有审核权限的用户,审核后发布至对应的发布渠道,以及“一键发布”,即具有一键发布权限的用户,可直接发布当前信息到发布渠道展现。

平台接入模块目前可支撑CMS、APP、社交媒体和视频网站四类业务渠道的接入,渠道信息及接入情况如表1所示。

4结束语

本文基于“中华云(新型全媒体融合平台)”项目实例和国际台全媒体业务发展需求,设计了全媒体应用技术平台的总体技术架构、能力模块构成以及支撑国际台全媒体业务运行的应用系统和工作流程。

全媒体应用技术平台构建了基于混合云的基础设施服务层、支撑媒体行业应用需求的平台服务层以及支撑国际台实际业务需求及工作流程的软件应用服务层,其在基础设施服务层的选择上灵活多样化,既支持私有云和专属云,也支持各厂商提供的公有云,并可灵活组合;在平台服务层的设计上充分考虑媒体行业应用特性,引入支撑专业音视频处理的能力服务,在软件应用服务层的打造上,可基于平台服务层提供的专业能力服务,根据具体业务需求进行轻量级的定制开发,并可随着业务需求的变化而快速迭代升级。随着云技术的发展和软件架构的优化,混合云+媒体专业平台服务层+软件应用软件应用服务层这一全媒体云平台技术架构将不断演进和深入,将成为全媒体业务支撑平台的主流技术架构。

参考文献

[1]陈天,陈楠,黄志兰,樊勇兵,赖培源.基于OpenStack的异构混合云解决方案[J].电信科学,2015(07).

[2]张蜂.云计算应用服务模式探讨[J].信息技术与信息化,2012(02).

[3]朱雨涵.基于私有云架构的全媒体信息汇聚平台设计[J].广播与电视技术,2015(03).

[4]房秉毅,张云勇,陈清金.云计算环境下统一SaaS平台[J].电信网技术,2011(05).

[5]朱雨涵,廖文芳,郭晓梅.基于内容智能聚合服务的元数据处理技术应用研究[J].世界广播电视,2014(04).

混合架构 篇7

随着Web2.0的快速发展, 无模式数据库得到了快速发展, 并逐渐由互联网应用扩展到企业应用中, 其最大的优势是对大数据量的高效处理。与此同时, 采用传统数据库架构的数字档案系统却普遍面临着巨大的挑战, 如何应对海量数据存储对数据库架构扩展性的要求, 以及如何实现海量数字档案数据的高效检索利用等问题在传统数据库架构模式下都不能很好地解决。本文在研究档案数据特点以及无模式数据库架构技术的基础上, 提出了能解决档案管理系统普遍面临的海量数据存储、分析、共享等方面问题的新模式, 希望能够在实际应用中有所帮助。

一、档案数据特点

档案是国家机构, 社会组织或个人在社会活动中直接形成的有价值的各种形式的历史记录[1]。随着信息技术的广泛应用和高速发展, 大部分国家机构、社会组织在其自身信息化建设工作内容中均涵盖了档案信息化工作, 而档案管理系统软件是实现档案管理信息化的必要工具。OAIS (Open Archival Information System) 参考模型是国内外档案管理系统设计过程中普遍参考的模型。根据OAIS中的功能模型定义, 档案管理系统应实现档案数据摄取、存储、管理、保存、存取、数据管理等6个主要功能模块[1], 这些功能模块对应着档案数据的不同阶段。在不同阶段, 档案数据在IO读写、数据量大小等方面差异很大, 导致了采用单一模式 (现阶段主流档案管理系统均采用传统关系数据库架构) 无法全面满足不同阶段下档案数据的处理要求, 会产生系统性能瓶颈, 影响用户体验。所以, 为了科学合理的实现档案数据的管理, 首先需要对档案数据特点进行深入分析。

(1) 档案数据业务 (功能) 阶段特点

1) 数据摄取、存储、管理阶段。该阶段对应的业务场景主要为档案收集、编目、组卷、审批和办结等, 档案管理系统需要频繁读取、修改数据以实现业务功能, 并且对系统响应速度要求高。这部分数据主要为当年、当季、当月应归档的档案数据, 数据量随着归档业务活动在一定区间范围内始终处于变化状态, 相对整个档案管理系统来说数据量非常小, 与一般事务性管理信息系统相似。

2) 数据保存阶段。该阶段对应的业务场景主要为档案归档办结业务, 办结后的数据将在其保管期限内为限制更新状态, 以数据的长期保存为主。数据读操作也以周期性的系统内部操作 (如数据检查、数据迁移等) 和对外发布为主, 对系统响应速度没有太高的要求, 而数据写操作几乎为零。这部分数据可以说是数字形态的馆藏档案。据统计, “十一五”末我国的馆藏档案量已到达约4亿卷 (件) , 比“十五”末增长近40%[2], 据此估算“十二五”末, 我国的馆藏档案量将达到约5.6亿卷 (件) 。按每卷档案数字化后形成10MB数据进行估算, 我国档案数据约为5.2PB, 并以每5年约2PB速度增长。同时, 考虑档案价值鉴定的难度和因档案销毁产生不良后果的风险较大, 所以档案数据的总量是一种持续增长态势。

3) 数据存取阶段。该阶段对应的业务场景主要是为档案利用者提供网络化的档案内容服务 (如在线查看、离线借阅等) 。数据读操作频繁, 没有写操作。数据量为馆藏可提供利用的数据量, 因馆藏数据量大, 所以该阶段数据量也相对较大, 数据增长速度快, 并且系统响应速度要求高、在线用户及并发用户数大。

(2) 数据结构复杂。档案数据涵盖了三种数据结构。一是结构化数据, 主要为档案管理系统所需固定字段 (如ID、创建日期、创建人、状态等) 和通用元数据集 (如保管期限、保密期限、关键词等) 。二是半结构化数据, 主要为档案的元数据, 数据结构随档案分类差异较大, 如发文的签发者, 合同的甲方、乙方、合同金额等。三是非结构化数据, 主要为电子档案文件, 类型包括文本、音频、视频、图片等。

二、采用传统关系型数据库架构存在的问题

通过上述特点阐述, 可以看出采用传统关系数据库架构的档案管理系统很满足档案数据的管理需要。主要有以下几方面原因:

(1) 关系型数据库扩展困难, 很难满足档案数据PB级别规模和持续高速增长的趋势。原因是由于存在类似Join这样多表查询机制, 使得数据库在扩展方面很艰难[3]。

(2) 读写慢, 很难保证PB级别数据量下系统的响应速度。原因是数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂, 使得其非常容易发生死锁等的并发问题, 所以导致其读写速度下滑非常严重[3]。

(3) 成本高, 一方面是企业级数据库的License价格很惊人, 并且随着系统的规模, 而不断上升[3]。

(4) 数据模式不匹配, 很难满足档案数据结构多样性的需要。当数据达到一定规模时, 基于结构化模式的关系型数据库架构明显不能满足无模式的非结构化和半结构化数据的管理需要。

三、混合数据库架构模式构建的关键技术

混合数据库架构模式不是将原来的传统关系型数据库架构完全抛弃, 而是对于不同阶段的档案数据选用不同模式的数据库架构进行管理。通过科学合理的融合各种数据库架构模式, 使得整个档案管理系统数据库架构在存储和性能两方面同时具有高可扩展性。关键技术之一就是无模式数据库技术。无模式数据库即各种形式的No SQL数据库, 它们的共同特点是都没有模式。No SQL领域在短短4到5年的时间里爆炸性地产生了225个数据库。nosql-database.org列出了225个这样的数据库[4]。这些No SQL数据库大部分归属四大类, 分别是键值存储数据库、列存储数据库、文档型数据库、图形数据库[5]。

(1) 文档型数据库架构技术。Mongo DB、Couch DB属于这种类型, 面向文档的数据库具有以下特征:一是即使不定义表结构, 也可以像定义了表结构一样使用。关系型数据库在变更表结构时比较费事, 而且为了保持一致性还需修改程序。然而No SQL数据库则可省去这些麻烦, 确实方便快捷。二是跟键值存储数据库不同的是, 面向文档型的数据库可以通过复杂的查询条件来获取数据。虽然不具备事务处理和JOIN这些关系型数据库所具备的处理能力, 但除此以外的其他处理基本上都能实现。这是非常容易使用的No SQL数据库[6]。

(2) 电子文件的分布式存取技术。分布式文件系统起源于Google三大学术论文《The Google File System》、《Map Reduce》、《Bigtable》, 是解决海量非结构化数据 (包括电子档案文件) 的关键技术[7]。目前包括英特尔、微软等公司均推出了面向企业应用的分布式文件系统以及开源的Hadoop分布式文件系统。

四、混合数据库架构模式设计

混合数据库架构模式的设计思路是改变目前档案管理系统以结构化数据为主体的传统关系型数据库架构, 而采用混合多种数据库架构的设计模式。具体设计内容 (如图1所示) :

(1) 归档电子文件库, 主要管理归档阶段的数据。其中, 以结构化数据为主体的系统固定字段和通用元数据库采用传统关系型数据库 (SQLDB) , 优先保证业务数据的强一致性和支持复杂的分析逻辑。数据结构不固定的其他元数据更适合采用文档数据库 (No SQLDB) , 可以很容易实现各类元数据管理方案。内容数据库主体为海量非结构化数据, 采用分布式文件系统架构, 易于扩展和维护。

(2) 电子档案保存库, 主要管理归档完结后的数据。归档完结后的档案数据的核心作用是长期保存。根据本文对该阶段数据特点分析, 固定字段和元数据采用文档数据库 (No SQLDB) , 在此, 不再区分通用元数据和其他元数据, 统一采用文档数据库 (No SQLDB) , 因为通用元数据在整个元数据集合中占比非常小。内容数据库统一采用分布式文件系统。

(3) 信息 (内容) 服务库, 主要管理作为信息 (内容) 对外提供服务的数据。这部分数据的核心作用是网络共享, 对应的业务功能与知识系统或门户类似 (如知网、维普网等) , 更适宜采用文档数据库 (No SQLDB) 和分布式文件系统。

(4) 数据接口, 主要为选用的No SQLDB和分布式文件系统软件的API。

五、结语

数据库架构设计是应用系统软件的重要基石, 对于以数据管理为核心业务的档案管理系统来说更为重要, 好的数据库架构将大大改善档案管理系统的用户体验和运维现状。在档案数据规模超PB级别并急速增长的背景下, 坚持传统关系型数据库架构或完全采用大数据架构都是比较片面的解决方案。只有让不同结构的数据在最适合的架构模式中进行管理, 通过融合关系型数据库架构、无模式数据库架构以及分布式文件系统等技术, 构建出恰如其分的混合数据库架构模式才是有效的解决方案, 充分发挥档案管理系统的作用, 为国家、社会、企业及个人的发展提供强大的知识储备。

摘要:随着Web2.0的快速发展, 无模式数据库得到了快速发展, 并逐渐由互联网应用扩展到企业应用中, 其最大的优势是对大数据量的高效处理。本文在研究档案数据特点及无模式数据库架构技术的基础上, 提出了两者结合的混合数据库架构模式, 以解决档案管理系统普遍面临的海量数据存储、分析、共享等方面的问题。

关键词:档案管理系统,无模式数据库,混合模式

参考文献

[1]ISO 14721:2012, Space data and information transfer systems--Open archival information system (OAIS) --Reference model[S].

[2]中华人民共和国国家档案局官网.全国档案事业发展“十二五”规划[EB/OL].http://saac.gov.cn, 2011-01-14.

[3]chj.CSDN博客网.云计算背后的秘密:No SQL诞生的原因和优缺点[EB/OL].http://blog.csdn.net, 2013-07-19.

[4]Stefan Edlich.Info Q.No SQL的现状[EB/OL].http://infoq.com/cn/, 2013-02-25.

[5]百度百科.No SQL词条[EB/OL].http://baike.baidu.com.

[6]佐佐木达也.No SQL数据库入门[M].北京:人民邮电出版社, 2011.14.

【混合架构】推荐阅读:

企业架构05-24

统一架构06-23

发展架构06-28

模块架构07-01

集成架构07-03

架构师07-11

存储架构07-25

分层架构07-28

信息架构08-10

通讯架构08-14

上一篇:急性化脓性肩关节炎下一篇:真情管理