基础架构原理论文

基础架构原理论文（共7篇）

基础架构原理论文 篇1

计算机软件设计的过程, 就是在逻辑关系的引导下, 实现软件内容的重新确定, 进而形成对应的基础架构, 这是软件运行的前提和基础, 甚至会影响到后期软件系统的维护和管理工作。由此积极探讨计算机软件开发的基础架构原理, 是很有必要的。

1 计算机软件开发的概况

1.1 计算机软件开发的概况

计算机性能的不断提升, 使得人机交互效益得到不断展现, 越来越多的行业开始尝试以计算机软件开发的方式, 实现自身运营模式的信息化转变, 由此以对应需求为基础的软件开发行业得到了快速的发展。计算机软件开发具备以下的特点:持续性特点, 就是软件开发是一个循环往复的完善过程, 在计算机逻辑基础上, 计算机软件的缺陷是一直存在的, 只有不断的采取措施去修正, 才能够更好的发挥计算机软件的性能;针对性比较强, 往往都是针对于某一行业或者领域而开展的计算机软件开发工作, 其开发工作的目的性更强, 对于效益的追求也是更加强烈的。

1.2 计算机软件开发基础架构的重要性分析

当前计算机软件开发过程中, 使用量比较多的基础架构, 就是三层结构体系, 其分别可以归结为:其一, 表示层;其二, 逻辑层;其三, 数据层。在上述三个层次的基础上, 可以使得软件的人机交互界面展现出良好的性能, 使得逻辑关系和计算机语言之间得以分离, 这样在后期维护和修改的时候, 单独的对人机交互模式进行调整, 就可以使得软件开发的节奏变得更加快捷。由此可见选择合理的计算机软件开发基础架构, 对于软件性能的最大化发挥, 对于软件后期的维护和管理工作质量提升而言, 都是有很大帮助的。

2 计算机软件开发的基础架构原理分析

2.1 从计算机软件开发基础架构需求的角度来看

无论是开发设计怎样的软件, 都需要在明确开发目的的基础上进行, 也就是需要对于软件的需求进行全面分析。不同的企业, 归属的领域不同, 所需要展现的功能也是很有差异性的, 此时企业都会提出对应的软件开发需求。在此过程中, 计算机软件开发者与信息企业之间会展开大量的协商工作, 对于软件的功能进行分析, 结合企业业务运行特点, 实现计算机软件开发方案的敲定。为了做好需求分析方面的工作, 需要特别注意以下几个方面的工作:建立完善的软件企业与需求企业之间的沟通机制, 保证在软件需求分析的过程中, 能够充分的了解企业组织的业务特点和规律, 保证软件开发需求能够更加明确。

2.2 从计算机软件开发基础架构编写的角度来看

计算机软件开发基础架构需求分析结果得出之后, 就需要进行实际的软件编写工作, 从当前的实际情况来看, 多数使用的是C语言, 这种语言的特点为:语言结构结构比较好, 编写操作比较快捷, 是当前程序员使用频率比较多的语言模式。在实际的软件编写的过程中, 会依照对应的功能划分, 实现不同模块的敲定, 保证不同模块都能够发挥自己的功能, 此时需要建立对应的函数模式, 使用这样的主函数对于各个模块进行调节和改善, 这样可以保证结构能够更好的维护。当前一个计算机软件的开发工作, 都是有多个程序员来共同完成的, 这样可以尽可能的保证软件编写工作的高效性。

2.3 从计算机软件开发基础架构测试的角度来看

在计算机软件开发基础架构编写工作完成之后, 就需要对于软件的不同功能实现测试, 实现对于软件测试阶段的管理和控制, 是保证软件性能发挥的关键所在, 这也是将对应计算机软件投入使用之前必然要进行的工作。在此过程中, 需要关注以下几个方面的内容:其一, 输入特定的参数, 对于软件的运行情况进行记录, 验差运行情况与理论情况之间差异性;其二, 使用白盒子和黑盒子的方式去进行测试, 同样对于软件测试的效果进行记录, 由此实现实际计算机软件开发工作的顺利开展;其三, 除了测试工作之外, 还应该做好计算机软件开发基础架构的维护和管理工作, 定期对于软件的性能发挥进行检查, 并且推出全新的版本, 进而实现软件自身的修复, 这样可以使得其自身的性能得到全面提升。

3 计算机软件开发基础架构选择的基本原则

计算机软件开发基础架构的选择, 关系到计算机软件效能的发挥, 牵涉到各行各业信息化的快速发展和进步。在选择计算机软件开发基础架构的时候, 需要关注以下几个方面的内容:其一, 树立软件设计目标意识, 在需求分析的基础上, 对于不同的基础框架进行选择;其二, 使用先进的逻辑语言和编程技术, 对于计算机软件架构进行合理的编写和操作, 由此才能够保证基础架构开发工作的高效性;其三, 依照软件目标功能和结构选择之间的关系分析, 选择合适的结构, 进而使得软件开发行为朝着有目的性的方向发展和进步;其四, 注重计算机软件开发团队的塑造, 处理好不同模板开发之间的关系, 保证计算机软件基础结构选择得更加科学和合理。

4 结语

综上所述, 计算机软件开发过程并不简单, 其中不仅仅涉及到专业领域的知识, 还关注到计算机软件基础结构的原理, 处理好这两者之间的关系, 才能够保证计算机软件开发的基础架构工作朝着更加高效的方向发展和进步。从当前计算机软件开发基础架构原理的运用实践来看, 其基础架构选择还存在很多不合理的情况, 此时就需要采取对应的措施来改善和调整, 相信随着在此方面实践经验的积累, 计算机软件开发的基础架构将会展现出更加大的效能。

摘要：计算机软件开发行业的发展得益于当前信息技术的快速发展和信息受众不断增加, 当然计算机软件开发也需要遵循特定的规律, 依照其基础架构原理来进行操作, 才能够保证计算机软件开发朝着有效性的方向发展。且计算机软件设计的过程, 就是在逻辑关系的引导下, 实现软件内容的重新确定, 进而形成对应的基础架构, 这是软件运行的前提和基础, 甚至会影响到后期软件系统的维护和管理工作。由此积极探讨计算机软件开发的基础架构原理, 是很有必要的。文章由此入手, 积极探究计算机软件开发的概况, 进而分析计算机软件开发的基础架构原理。

关键词：计算机软件开发,基础架构原理,信息技术

参考文献

[1]林雪海, 吴小勇.计算机软件开发的基础架构原理研究[J].电子制作, 2016 (Z1) :65-66.

[2]吴丽影.计算机软件开发的基础架构原理分析[J].电子制作, 2015 (06) :69-70.

[3]张旭.关于计算机软件开发的基础架构原理探究[J].赤峰学院学报 (自然科学版) , 2015 (09) :25-26.

基础架构原理论文 篇2

计算机软件技术领域的稳定发展,能够为社会经济发展提供稳定的软件更新和创新支持,是保证社会经济稳定快速发展的重要基础,所以对计算机软件系统开发的基础构架进行原理分析,对计算机软件的开发进行普遍性的认识和探究,能够帮助计算机软件设计人员认识到计算机软件开发过程中的普遍特点,对计算机软件开发活动有更加深刻的认识,在计算机软件开发活动中有更好的发挥。

1 计算机软件开发简述

1.1 计算机软件开发的概念

计算机软件是在计算机系统发展到一定程度后,必然会出现的一种计算机组成部分,在最初的计算机应用活动中因为计算机能力的单一、设计目的的单一,是不需要软件系统的,要将计算机应用到哪一个领域就专门设计一款计算机,但是随着计算机性能和人机交互能力的提升,计算机的应用领域逐渐扩大,计算机的应用数量也极大的增长,再进行那种专门设计的计算机应用是极为不智的行为,所以为了满足计算机的不同应用需求,计算机的硬件部分开始和软件部分发生分离,计算机硬件系统就是计算机的能力实现部分,至于相应的计算机能力应用部分则针对使用者的不同需求进行针对性的设计,并可以由使用者选择性的安装,这样一来计算机系统在不同应用领域的适应性就有了极大的提升,也直接导致了当前计算机系统在社会经济发展中的广泛应用。

在计算机软件的开发活动中,软件开发可以分为两种开发概念,一种是先进行软件的开发,在软件开发工作完成之后再为软件的应用寻找市场,这种软件开发模式在一些娱乐软件的开发活动中比较常见。另一种软件开发模式是针对计算机市场的实际需求,进行针对性的软件开发工作的软件开发模式。

1.2 计算机软件开发的特点

可以说计算机软件技术是伴随着计算机技术的出现而出现的,计算机软件技术在这短短几十年间和计算机技术一样得到了极大的发展,现在已经形成了一门独立的学科,但是计算机软件技术仍然不断出现,已经存在的软件自身也在不断的维护更新,由此可以看出,计算机软件开发的一个显著特点就是持续性,当前市面上的计算机软件已经相当多了,但是随着社会经济的发展,总会有新的软件应用需求出现,所以计算机软件系统的创新是一个持续不断的过程,而且已经成型的常用计算机软件系统也需要持续不断的更新,以保证自身的安全性和稳定性,例如我们的计算机系统中常见的Windows操作系统,作为一种软件系统每隔一段时间就会发布最新的补丁对自身的系统进行完善。

计算机软件系统的另一特点是随着社会经济的发展而逐渐显现出来的,那就是计算机软件系统的针对性,在当前的社会经济发展过程中社会化大生产成为社会经济发展的主要形式,专业化成为市场竞争主体追求的目标,所以在计算机软件设计领域,软件设计的专业性也开始成为软件设计工作的一个突出特点。

1.3 计算机软件开发的发展

在计算机出现以后,为将计算机优秀的计算能力进行有效的利用,使用者与计算机系统的信息交互成为计算机发展亟待解决的问题,当代计算机之所以能够按照使用者的要求执行各种任务,是因为计算机系统的CUP将电路的通与不通两种状态和数学中的二进制有效的联系起来,使用者要想让计算机系统明白自己的指令,就必须通过二进制数字下达命令,这种命令是极为复杂的在人机交互方面有明显的缺陷,所以计算机软件研究人员在其基础上研发了高级计算机语言,通过英语简化语言的方式,来实现使用者与计算机之间的信息交互,当前主流的VF和VB两种可视化编程语言的出现,使得很多对计算机软件设计没有深刻认识的人,也可以进行一些简单的计算机软件设计。由此可以看出计算机软件开发正向着简单化的方向发展。

2 计算机软件开发中基础构架原理分析

2.1 计算机软件开发中基础构架的需求分析

当前的计算机软件开发活动针对性越来越强,所以在软件开发活动开始之前要进行详细的软件需求分析,尤其是在面对企业进行软件开发工作时,因为企业的运行管理都是具有自身的特殊性的,所以相应的软件技术需求也会比较特殊,面对这样的计算机软件开发形势,软件设计公司要对企业的软件功能需求进行细致的了解,明确了企业的软件应用需求之后,再进行针对性的软件开发工作,需求分析是软件开发工作的第一环节,也是最重要的环节。一旦软件设计公司对企业主体的软件功能需求有理解上的错误,就会导致软件设计工作出现方向性的错误,导致软件设计工作失败。

所以在软件设计工作中设计公司和需求企业要排出专人对软件的设计需求进行面对面的讨论,设计公司的设计人员要对软件设计上的一些专业问题对企业代表进行详细的解释,保证在软件功能上不会出现分歧和误解,保证软件设计工作的方向性。同时在软件设计公司内部,软件需求的分析人员和软件设计人员之间也要加强沟通,当前很多软件设计公司的需求分析人员都是将用户的设计需求记录下来,直接交给软件的开发人员,开发人员根据自己的理解对软件进行开发工作,所以很难保证软件开发的正确方向性,经常会出现开发人员理解错误的现象。

2.2 计算机软件开发中基础购机的编写工作

在计算机软件系统的需求分析工作完成之后,就要进入到软件系统的实际设计环节了,在这一环节中软件设计人员使用最多的设计语言是C语言,由于这种软件设计的高级语言结构性和基础架构比较好,因此被很多程序编辑人员采用,虽然软件编辑领域出现了VF等可视化的编辑语言,但是由于软件设计工作的特殊性,软件编辑人员还是愿意使用C语言进行软件系统的编辑。在实际的软件编辑工作中,由于一些软件系统的功能过于复杂,造成了软件系统本身的庞体性,大量的数据编辑工作由一个编辑人员完成是不可能的,所以在实际的软件编辑工作中,被编辑软件常常会按照逻辑顺序被分为几个模块,然后在这些模块的之上建立一个主函数对模块进行管理,在软件系统要实现某项功能时,主函数就会对不同的软件系统模块进行调用,以实现软件系统的正常运行,同时这种软件系统的模块化设计也极大的提高了软件设计工作的效率,软件系统的不同模块可以由不同的程序设计人员来分别进行设计,这种多个工作面同时开展设计的工作方式,能够极大的提高软件设计工作的效率。

2.3 计算机软件开发中基础构架的测试和维护

计算机软件系统是计算机系统的管理系统,计算机系统会根据软件系统的要求进行各种动作,所以计算机软件系统在设计完成之后是不能马上投入应用的,因为新系统中可能存在的系统漏洞,会在运行中严重危害计算机系统的正常运行,所以在新的软件系统设计完成之后,要进行科学系统的测试,传统的测试方法是对软件系统进行指定数据的输入,对计算机软件系统运行之后产生的数据结果进行对比,如果结果和设计结果相同那么就可以认定计算机软件系统是正确、完整的,但是这种数据输入的测试方式有一定的局限性,因为输入的测试数据有一定的特殊性,并不能代表所有的数据。在这种测试形势下,测试软件的开发成为软件系统测试的必要环节,测试软件能够模拟软件系统在正常运行中可能会出现的数据现象,对软件系统面对各种极端情况的反应能够进行可量化的测试。

同时软件系统在完成设计投入应用之后,因为应用企业的需求变化和应用环境的变化会产生一些应用的问题,针对这些问题软件设计企业要进行针对性的定期维护,通过系统更新和补丁的形式对软件系统的运行进行维护。

3 计算机软件开发的基础构架选择

3.1 计算机软件开发中基础构架的重要性

基础架构的设计,是计算机软件系统开发的核心内容,由于计算机软件系统设计就是将计算机语言利用特定的逻辑进行组合,从而达到能够执行一定任务的能力。所以在计算机软件设计活动中,对软件的基础构架设计就是对计算机软件系统逻辑的设计,是计算机系统能够合理运行的关键,当前的计算机软件设计活动应用最多的基础结构是三层结构体,通过表示层、逻辑层、数据层三个层面进行软件的设计开发,在实际的软件开发活动中,可以将这三个区域进行分开设计,在计算机软件系统的维护活动中,也可以对三个区域进行分别维护,极大的提高了软件的可维护性和扩展性。

3.2 计算机软件开发中基础构架的选择

计算机软件开发活动中,软件的基础架构对软件性能和可维护性都有极大的影响,所以在软件设计活动中要对基础构架进行慎重的选择。这一选择一定要跟根据计算机软件系统的特点进行选择,从计算机软件系统的功能需求出发,结合软件系统功能实现的特点,对现有的基础结构原理进行分析,最后选择或者针对性的开发一个最佳的基础架构。

4 结论

计算机软件的开发活动对社会经济的安全稳定运行有着极大的影响,所以在计算机软件的开发活动中,一定要从软件的实际应用需求出发,结合软件设计的应用特点,对计算机软件系统的基础构架进行慎重的选择,保证计算机软件系统能够在社会经济发展中发挥积极的作用。

摘要：随着我国经济的快速发展和计算机软件技术的推广普及,计算机软件开发开始受到社会经济各个领域的广泛关注,计算机软件技术作为一种时代性鲜明的时代技术,其应用已经渗透到社会经济发展的各个领域,可以说当前世界经济的飞速发展,计算机软件技术起到了关键性的作用,所以社会经济要想保证在计算机软件系统的支持下保持发展的速度,对计算机软件开发的基础构建原理进行探究总结是一种必然。

基础架构原理论文 篇3

所谓风险导向内部审计模式,简而言之,就是以“风险”来引导内部审计工作的方向,包括确定审计计划、重点、范围和频率,分配审计资源等等。目前,主要发达国家企业和组织都普遍实行风险导向审计模式。在国际注册内部审计师协会发布的《内部审计专业实务框架》中,强调内部审计活动“应当制定以风险为基础的计划”,“应该在风险评估结果的基础上开展审计项目”,“应协助组织识别和评价重大风险问题,帮助组织改进风险管理与控制系统”,是从不同层面提出了“风险评估”之于内部审计的重要性和作用。

运用风险评估需要理清“风险”的概念。对于风险导向内部审计中“风险”的概念,一种认识是理解为审计风险,即审计人员在审计过程中由于受某些不确定因素的影响而使审计结论与客观事实在一定程度上相背离,从而受被审单位及有关负责人指控并遭受某种损失的可能性。以“审计风险”引导内部审计,审计人员应立足于对审计风险的分析和评价,并以此为出发点,制定审计计划,实施审计行为。另一种观点认为,“风险”不是单纯意义的“审计风险”,而是指更广意义上组织面临的所有内外部风险。以“组织风险”引导内部审计,审计人员应通过对审计对象面临的风险进行评估后确定审计计划、审计重点、审计策略。从内部审计的目标和职能分析,后一种理解更符合内部审计的职能特征。内部审计应服务于组织目标的实现,因此组织面临的风险也就是内部审计应该关注的;审计需要对组织所处的宏观社会经济环境、战略目标和措施、影响组织目标实现的主要业务活动和关键环节进行深入了解,提高风险管理与组织整体目标的契合度。内部审计如果仅仅关注于审计风险,就不可能真正有效发挥内部审计职能,无法体现与组织目标的趋同。

二、风险量化评估模型

从内部审计的历史发展来看,风险评估并不是一个新鲜事物。现代风险导向审计的开拓者—美国毕马威会计师事务所审计与鉴证研究中心主任Timothy B.Bell博士和伊利诺伊大学香槟分校会计系主任IraSolomon教授认为,风险评估的定位在财务报表审计中至少已经存在了100年(吴俊峰,2009)。无论是账项基础审计模式还是制度基础审计模式,审计人员在运用职业判断时,都会有意识、无意识的、不同程度的对审计对象的风险进行评估。只是这种风险评估是不规范、不系统的,与审计的经验、能力有重要关系,缺乏科学、合理的标准和规范的方法。现代风险导向内部审计所要解决的一个重要问题,就是通过建立风险量化评估模型,使风险评估过程更加规范和系统,评估方法、程序更加科学。

一般来说,运用风险评估技术需要理解几个基本概念:

1. 固有风险。

是指管理当局没有采取任何措施来改变风险的可能性和影响的情况下,一个主体所面临的风险。如《企业内部控制基本规范》要求,“企业开展风险评估,应当准确识别与实现控制目标相关的内部风险和外部风险,确定相应的风险承受度”。不同企业或组织面临的风险是不一样的,比如对一国中央银行而言,按照风险来源分析,面临的风险主要包括市场风险、信用风险、流动性风险、操作风险、法律风险和声誉风险等。

2. 可能性和影响。

这是评估风险程度的两个组成要素。可能性表示一个给定事项将会发生的概率,影响代表了它的后果,这两者都能够根据大小、程序划分为不同的级别,实务工作中常用“风险矩阵”来表示风险可能性和影响程度之间的关联程度。如下表所示,矩阵中风险由低到高分为4个等级(IV级为最高风险),不同的风险等级用不同颜色表示。

3. 剩余风险。

是指风险应对之后所残余的风险;一旦风险应对已经就绪,接下来就要考虑剩余风险。风险管理目标之一就是使剩余风险水平处于组织能够承担的风险限度之内,包括整体风险承受能力和业务层面的可接受风险水平。

以上三个因素构成了风险量化与评估的基本框架,它们之间存在如下关系:

(1)固有风险=风险发生可能性×影响程度

(2)剩余风险=固有风险—风险应对有效性

上述关系不应理解为单纯的算术关系,而只是表明了相互逻辑关系。如果对风险进行量化,则需要设定具体的公式或模型,现以中国人民银行风险量化评估模型为例予以说明。下面的表格中对我国中央银行“紧急贷款管理”的风险进行了分析,根据风险矩阵对风险事项从影响程度和可能性进行评估,每一类风险设置一定权重。通过固有风险评估、风险应对有效性评估后,根据剩余风险的量化公式,计算出剩余风险的级别为1.9。

以上风险量化评估模型总体上遵循“固有风险识别、评估→风险应对有效性评估→剩余风险评估”的思路。在风险的分类上,按照风险来源将中国人民银行面临的固有风险划分为市场风险、信用风险、流动性风险、操作风险、法律风险和声誉风险共六类。风险量化采用风险因素权重加总法计算,也就是将各风险因素的风险级别乘以相应的权重,得出“积”;将所有风险因素各自的“积”相加,得出审计对象的风险值。从内部审计实务看,运用风险量化与评估的框架具有以下特点:一是对风险的分析、评价更加系统,改变了以往较为模糊的风险引导审计的状况;二是审计流程、思路清晰,便于操作并提高审计工作效率;三是审计结论提供的信息更加关注组织风险,使审计报告的使用者能够清晰了解和掌握审计对象的风险状况,便于作出决策。

三、风险评估结果的应用

现代风险导向内部审计的基本特征,是审计人员在审计过程中自始至终都以组织风险分析为导向,根据量化的分析水平排定审计项目优先次序,依据风险确定审计范围与重点,对组织风险管理、内部控制和治理程序进行评价,进而提出建设性意见和建议,协助组织管理风险。在风险评估中,职业判断是灵魂,从风险评估所要达到的目的看,不过于强调评估个体风险估值的准确性、精准性,而应注重评估对象整体风险排序的合理性。也就是说,对一个特定风险事项而言,由于评估人员经验、能力、风险偏好的差异,具体的风险赋值可能是不一样的,但对评估对象整体而言,只要所有风险事项最终的风险排序是准确的,风险评估就可以认为是有效的,这样就科学解决了风险评估由于大量运用主观判断而导致评估结果的不确定性所引发的缺陷。

在审计计划阶段,内审部门应对影响组织目标实现的风险因素进行评估,根据风险的重要性、风险优先次序拟定中长期审计规划,安排年度审计工作,包括选择审计对象、确定审计范围、分配审计资源等。审计计划的制定应紧密结合组织风险管理目标,确定关键风险、高风险领域作为年度审计计划优先安排的项目。基本思路是,风险小的业务减少审计频率,风险大的业务增加审计频率,追加审计资源,优先把高风险业务作为审计项目规划的重点;确保审计频率和程度与审计对象的业务性质、复杂程度、风险状况和管理水平相一致,克服传统审计较为模糊的风险引导审计概念,导致审计不足或审计过度的问题。比如,实务中有的组织根据剩余风险水平设置如下审计频率标准:

在审计业务的实施过程中,审计人员要根据风险评估的情况确认需要强调的领域,决定是否需要开展进一步的审计。审计人员用于检测、证实风险的技术与方法,应能够反映出风险的重大性与发生的可能性;应根据审计证据和形成的审计结论,对固有风险和风险应对有效性进行适当调整和修正。在审计报告阶段,为了让管理层充分理解风险的程度,应该对审计情况进行分类汇总,披露剩余风险状况,根据组织风险偏好和可容忍水平,提出对风险管理的建议,以降低风险。在跟踪改善阶段,要根据风险状况制定跟踪审计计划,并在后续审计时重新评估剩余风险。在审计报告阶段和后续审计阶段(如果需要)所评估的剩余风险结果,都将作为下一轮风险评估的参考依据。

四、审计的风险评估与管理当局风险评估的关系

风险导向型内部审计所指的风险评估,是基于审计所必须掌握的、了解审计对象面临风险的类别和重点,用以拟定审计计划、部署审计策略、提高审计效率所应用的方法,是审计本身的需要,侧重于分析结果,确认风险的排序。管理当局在风险管理框架(和内部控制框架)内所实施的风险评估,是基于组织目标而实施的,包括目标设定、事项识别、风险评估、风险应对在内的一系列风险管理组成要素,侧重于识别风险并制定有效风险应对措施。

从内部审计在风险管理中的地位和作用来看,作为内部控制和风险管理的确认者,管理当局往往需要内部审计的专业技术和方法,也可能直接将风险评估的部分任务安排给内审部门。此时,审计人员的风险评估也就不是单纯审计本身的需要,而是为推动组织风险管理发挥咨询、服务作用。在这一过程中内审部门可能扮演参与者、组织者、协调者等多重角色,此时审计人员的风险评估既能够为风险导向审计服务,也是组织风险管理的工具。但即使是这样,审计人员参与风险评估,仍然与其在风险管理中角色有紧密联系,须“有所为而有所不为”。审计人员可以对风险事项进行分类,可以利用专业能力评估风险管理流程的设计和运行效果,提出改善建议等;但不便设定组织的风险偏好水平,也不能强加风险管理程序,决定风险响应策略,更不能为风险管理的绩效负责。

参考文献

[1]中央银行内审部门风险导向审计模式.中国人民银行内审司“确立风险导向审计模式”课题组.中国金融.2012年第9期

[2]风险导向内部审计基本理论及程序构建.徐元玲.会计之友.2008.12

[3]我国风险导向内部审计的应用研究.石丽娟、杨静静.中国证券期货.2010.10

[4]企业内部控制基本规范.财政部等五部委.2008年颁布

[5]风险导向内部审计基本问题研究.吴俊峰.西南财经大学博士论文.2009

[6]从审计模式及其思想的演进辨析风险导向审计应有的内涵.陈志强.审计研究.2006.3

[7]公共部门内部控制—最高审计机关国际组织内部控制概念的更新.王戍/译.中国内部审计.2005.12

[8]基于风险导向的内部审计原理及其应用.王敏、黄瑛.财经理论与实践.2006.5

[9]风险导向内部审计若干理论问题探讨.郑小荣.审计与经济研究.2006.(1)

[10]论风险导向的内部审计理论与实务——通过解读IIA2001版.内部审计实务标准.看内部审计的风险导向.王晓霞、孙坤、张宜霞.审计研究.2004(2)

医疗云平台的基础架构 篇4

在IT技术飞速高速的互联网时代, 最新的IT运用模式被逐步应用在各行各业, 这种模式就是云计算。云计算是一种商业计算模型, 它将各种复杂的业务或者任务分布在大量的IT设备组成的资源池中, 使得各种业务系统能够根据需要获取计算能力、存储空间、软件支持及各类信息服务。提供资源的主机、存储、网络、软件及服务称为“云”, 对于云端客户来说, “云”中的资源是无限扩展的, 并且可以获得, 按需使用, 随时扩展, 按需付费。当前各行各业都逐步建立自己的“云”, 如天翼云、阿里云、医疗云等。

医疗云是指在云计算平台支持下提供各种医疗服务, 构建医疗的信息化软硬件环境, 共享医疗数据资料, 促进医护人员高级思维能力和群体智慧发展, 提高医疗质量。也就是充分利用云计算平台带来的云服务为医疗提供资源共享的便利条件。

当前, 卫生系统信息机构为了解决中小型医疗机构信息化建设存在的问题, 如采购招标过程长、软硬件成本高、上线周期长、系统维护难等难题, 逐步推进医疗云平台的建设, 除了基础硬件资源外, 将以云HIS、云EMR、云LIS、云PACS、供应链云平台、云HRP、掌上办公、云HCRM、云培训等为核心产品, 构成多元化的云服务模式, 以此为基础构建医疗云平台。

2 云计算的分类及层次

云计算根据使用范围划分, 分为公有云、私有云和混合云。公有云是对外企业、社会和公共用户提供服务的云平台;私有云是为平台所有企业或者机构内部提供本单位内部服务的云平台;混合云是提供以上两种服务的云平台。

从提供服务的类型来分, 云计算分为三个层次, 即Iaa S、Paa S、Saa S三种。

Iaa S全称为Infrastructure as a Service, 即“基础设施即服务”。Iaa S以硬件设备虚拟化为基础, 组成硬件资源池, 具备动态资源分配及回收能力, 为应用软件提供所需的服务。硬件资源池并不区分为哪个应用系统提供服务, 资源不够时, 整体扩容。

Saa S全称为Software as a Service, 即“软件即服务”。严格来讲, Saa S构建于Iaa S之上, 部署于云上的Saa S应用软件的基本特征是具备多用户能力, 便于多个用户群体通过应用参数的不同设置, 共同使用该应用, 且产生的数据均存储在云端。非严格的Saa S也可独立于Iaa S, 这样牺牲是硬件的利用率, 用户感知不到, 如HIS (医院信息管理系统) 。

Saa S与一般网络应用的区别在于:不同的用户通过不同的设置实现不同的功能, 而一般网络应用几乎都按照同样的实例运行, 几乎无法进行灵活的配置和调整。

Paa S全称为Platform as a Service, 即“平台即服务”。层次介于Iaa S和Saa S之间, 是最难实现, 一旦实现后会带来巨大效益的一种形式。Paa S同Saa S, 严格来讲也基于Iaa S, 它在硬件之上提供一个中间层, 主要表现形式为接口、API、BO (业务对象) 或SOA模块等, 它并不直接面向最终用户, 更多的使用者是开发商, 开发商应用这些接口, 可快速开发出灵活性、扩展性强的Saa S应用, 提供给最终用户。非严格的Paa S也可独立于Iaa S, 同样牺牲硬件效率, 如部分中间件产品。

随着这几年医院整合和兼并, 许多三甲医院规模不断扩大, 有的三甲医院拥有几家分院, 信息化建设的投入不断增加迫使医院建立自己的私有云, 这些大多是Iaa S。

同时, 随着医疗服务社区化的政策逐步落实, 社区卫生服务中心、乡镇医院、养老院和小型医院数量在逐年增加, 这些医院规模小、数量多, 信息化的投入对这些医院来说显然是一笔不小的开支, 基于Saa S服务模式为这些医院解决了信息化投入高的问题。基于Saa S的医疗云具有以下特色:在线服务、按需租用;零成本、零维护;终身免费升级优化;轻量化、傻瓜化;提供强大的安全保障;具备全方位业务能力, 形成端到端的医疗服务生态链。这种医疗云面向中小医院、基层医疗机构、连锁诊所、供应商及其他第三方机构, 提供“一站式”IT软硬设施租赁式、即开即用的基于云的各项医疗服务, 持续引领医疗服务和业务创新, 有力推动中小型医疗机构信息化建设全面迈入云端。

3 医疗云的的基础构架

以Iaa S为例, 介绍医疗云的基础构架。

图1为某三甲医院云平台的基础架构, 平台提供了功能完整、标准开放、方便集成的基础设施服务, 管理离散的硬件经过改造成为管理虚拟化的共享资源池。根据资源池提供的服务类型, 可以分为计算资源池、存储资源池、网络资源池和灾备资源池。随着应用系统负载变化, 动态改变资源分配的规模, 以快速适应应用系统的扩容需求, 实现“弹性”资源分配能力。

随着医疗系统数据规模和业务量快速增长, 应用需求呈现多样化, 对业务功能、系统关联、信息利用、数据质量、信息服务水平、信息化工作机制等, 提出更高要求和更深入的需求。按照组织架构和业务应用的特点, 以资源区为单位进行基础资源的划分, 参照现有业务应用系统的特点, 兼顾未来业务发展的需要, 将各项业务应用划分到资源区。考虑到不同应用对底层硬件需求的不同, 对应到Iaa S平台反映出不同的技术架构形态, 可将Iaa S平台主要分为虚拟化计算资源区、存储整合资源区和灾备资源区 (即灾备资源池) 。Iaa S层平台服务主要包括虚拟化计算资源池、数据库服务器资源池、统一存储资源池和灾备资源池。

4 结语

在互联网时代, 技术与商业的变革总是相互呼应。医疗信息化变革的时代云计算兴起, 医疗云将为中国基层医疗机构提供一个借助信息化提升医疗行业管理能力的蓝本。

摘要：在医疗信息化变革的时代必然要建立医疗云平台, 笔者首先介绍什么是云计算与医疗云, 结合医疗云分析了云计算的层次和分类, 最后就医疗云平台的基础架构建设进行了阐述。

关键词：医疗信息化,云平台,IaaS

参考文献

[1]周晓冰.浅谈云计算的本质[J].中国医学装备, 2014 (3) .

[2]黄永华.如何构建私有云[J].电子科技, 2015 (3) .

[3]张苍松.云计算的发展与展望[J].科技信息, 2014 (12) .

智能基础架构管理如何降低能耗 篇5

为此, 能源管理软件可以和智能布线基础设施结合使用, 使IT和基建人员了解、优化并控制整个企业基础设施的电力, 从而对电力设备产生潜在影响。

康普的智能布线解决方案 (SYSTIMAX i Patch智能配线架) 填补了实时网络管理工具与连接网络设备的传统无源结构化布线基础设施之间缺少的中间环节。

智能布线解决方案深入了解物理层, 通过帮助IT专业人士和网络管理人员确保网络效率, 采用的方法包括提供准确的容量管理报告、生成实时警报以检测、定位和解决网络中未经授权的更改、实时自动发现并追踪连接至网络之设备的物理位置、采用支持更改管理的电子工单应对更改。

智能布线解决方案具备墙面插座和网络设备实际位置的交换机端口实时映射功能。该功能通过结合综合布线信息实现, 这些信息来自智能布线硬件以及收集于管理网络交换机的网络设备IP信息。

智能布线解决方案能够全面掌握连接至每个交换机端口的任何物理位置。布线信息一旦改变, 该系统就能实时检测到, 并自动更新由管理软件维护的布线信息。

交换机端口与墙面插座间的实时映射信息能让IT管理人员有效地将能源管理应用于网络设备。通过确定某些位置应当何时供电, 或是何时处于闲置状态并可以断电, 智能布线解决方案和能源管理可共同优化能耗。例如, 可以采用一个配置文件, 当晚上7点所有员工均下班回家以后, 切断办公楼公共区域的电源, 次日早7点再重新供电。这些系统可运行的范围十分广泛, 如整幢大楼、具体的楼层、单个房间, 甚至每个墙面的电源插座。

此类功能可依赖位置而实现, 因此这些系统可以选择性排除部分位置, 或单独为某些房间、办公室或办公桌制定具体方案。智能布线解决方案使IT经理可以直接通过软件界面上的大楼布局图选择位置, 并决定要采用该能源管理方案的具体位置。有时也可制定一次性的方案, 管理那些偶尔使用的房间, 比如会议室或培训室。

此外, 智能布线解决方案还能追踪网络连接变化、灵活执行能源管理, 可在交换机端口与墙面插座间建立新连接时自动启动。

俗话说, 知识就是力量。如果您对于办公室环境的运作方式一知半解, 那么将会造成显而易见的不利影响。举个例子, 假如操作人员决定增加对电力、热能和空间的使用需求, 那么智能布线解决方案就能让你对此引发的结果一目了然, 从而帮助你做出更合理地使用各项设备的决定。

企业的IT总成本实际上很难界定, 除非采用智能布线系统令其可见并加以控制。智能监控系统能够提供对降低运营成本和能耗至关重要的关键数据。

物联网校园平台的基础架构 篇6

目前, 物联网已有部分应用进入了高校的信息平台, 如“一卡通”、智能电表、校园安防系统等, 但是这些应用都是一个个孤独的、分散的信息孤岛, 没有形成一个有效的整体, 而相互之间的数据也没有完整的结合在一起, 没有构建一个完整的物联网整体系统[2]。

针对物联网的技术特点和现在校园信息化网络存在的不足, 物联网平台的搭建是非常有必要的, 本文通过对校园物联网的研究, 设计了一种基于物联网的信息平台架构, 希望可以为校园物联网平台运行和管理提供更好的模式和体系架构的探索性研究, 同时可以带动物联网技术的研究及其在其它重要领域的广泛应用。

1 平台搭建环境

整个环境力求高效简洁开源, 所以选择LAMP组合。即是用Linux作为操作系统, Apache作为Web服务器, MySQL作为数据库, PHP (部分站点也使用Perl或Python) 作为服务器端脚本解释器。由于这四个软件都是开放源代码软件, 因此使用这种方式不用花一分钱就可以创建起一个稳定、免费的站点系统。MySQL加PHP的配对在互联网上的应用相比LAMP来说更为常见。

服务器上选择Ubuntu Server 12.04 LTS 64bit。Web服务器选择Apache的原因是它的源代码开放、有一支开放的开发队伍、支持跨平台的应用 (可以运行在几乎所有的Unix、Windows、Linux系统平台上) 以及它的可移植性等方面。数据选择MySql开源数据库。MySQL是一种关联数据库管理系统, 关联数据库将数据保存在不同的表中, 而不是将所有数据放在一个大仓库内, 这样就增加了速度并提高了灵活性。MySQL的SQL语言是用于访问数据库的最常用标准化语言。PHP是一个应用范围很广的语言, 特别是在网络程序开发方面。一般来说PHP大多在服务器端运行, 通过运行PHP的代码来产生网页提供浏览器读取, 此外也可以用来开发命令行脚本程序和用户端的GUI应用程序。PHP可以在许多不同种的服务器、操作系统、平台上运行, 也可以和许多数据库系统结合。最重要的是PHP可以用C、C++进行程序的扩展[3]。

2 平台模块构成

整个平台分为3大部分:基础信息、设备信息和校园管理。如图1所示。

2.1 基础信息

基础信息是整个平台的基础, 它包含了地址信息、用户信息、系统安全等部分。

地址信息包括了学校的校区、教学楼、教室、寝室楼、寝室等信息, 里面的主要信息是学校的基本环境情况, 便于确定设备安装地址以及管理范围。如:教室信息里面就应该包括教室大小、教室容纳学生人数、教室课程安排情况等。

用户信息包括了学生信息和教师信息, 里面的主要信息是学生和教师的基本信息情况, 用来确定用户身份及权限。并且通过专用接口和校园网对现有学工、学籍等系统实现数据交换, 保持数据一致性。

系统安全主要是针对平台安全认证授权有着详细的设置, 根据不同角色赋予不同权限。

2.2 设备信息

设备是整个平台正常工作的基石, 在设备信息部分中, 主要是包括设备安装及设备查询两部分。

设备安装主要包括所有具有物联网工作设备的安装情况, 用于统计校内物联网点数及物联网设备正常工作情况。

设备查询主要是包括具体物联网设备的工作情况, 用来对某一个物联网设备的工作状况、使用情况的查询。

2.3 校园管理

校园管理部分是平台的实际操作部分也是平台的核心部分。在这部分中, 通关物联网的技术。我们可以具体对某一个物联网应用设备进行管理。如灯光管理, 在教室里面的灯, 我们可以在平台终端根据不同的季节来调整它自动开灯和关灯的时间。

3 用户界面及数据库设计

本层是直接展示给最终用户的进行操作的接口, 设计原则是简单易用, 不会造成使用上的困惑, 尽量减少误操作的可能性。在前端构架上采用HTML5+jQuery+Twitter Bootstrap CSS的组合, 充分利用现有最新技术, 提高响应速度以及多设备的不同屏幕大小适应性。

数据库是服务器端的核心, 数据库设计的合理与否对系统的制作有着至关重要的影响。系统的一大基本功能就是检索, 主要包括用户信息检索、教师课表检索、教室课表检索、空闲教室检索、设备状况检索等。

本系统使用MySQL数据库, 与Apache服务器和PHP语言形成黄金组合, 在该作品网站建设中充分体现了其体积小、速度快、总体成本低, 尤其是开放源码这一特点。

将采集到的信息存放在数据库中, 对数据进行处理并用于查询, 得到用户最终满意的结果。数据库的详细设计如图2所示。

4 自动处理系统与信息采集网关

自动处理系统设计用于紧急事件以及突发情况, 可以根据预先设定的紧急预案流程, 自动处理事件。例如收到火警信息:一旦系统侦测到某火警点报警, 立即告警并发送所处大楼疏散信号, 启动疏散引导系统, 提示关闭防火隔离门。

在底层构建实时信息采集系统, 通过通讯网关, 连接至Internet上的各个设备 (无线3G或者有线方式) , 采用TCP/IP协议, 稳定可靠。

实时信息采集系统在后台定时自动请求各个设备状态, 如果设备无响应, 或者返回错误状态, 系统主动上报, 反映至管理平台, 有助于快速排错, 使系统稳定运行。也可以在管理平台手动直接采集设备实时信息, 提高诊断准确率, 以及了解设备运行状态。

5 处理流程

下面通过监测控制校园路灯为例, 介绍平台对终端的控制流程。

在实际工作中, 当路灯突然出现故障不能亮启的时候, 传感器接收到电流的异常变化, 这时候它就发出一个异常变化的信号并且连同自己的网络地址通过校园网送达学校的物联网平台。

而在平台中, 平台判断异常变化的情况给出结论显现出来, 这时操作员根据给出的结论来对路灯进行处理。

登陆平台之后, 进入[校园管理]=〉[路灯管理]界面。校园网内所有路灯都显示在页面。第一列是路灯编号;第二列是路灯的地址, 便于发现问题之后找到问题路灯, 进行维护;第三列是当前路灯状态, 表示正常工作, 而则表示路灯需要维护;第四列可以对正常的路灯进行开关控制, 而异常的路灯则给出诊断按钮, 用于诊断异常信息。

5.1 开关控制

当需要控制路灯开关的时候, 点击控制栏的开或关按钮, 平台找到所需控制设备的ID号, 确定网络地址, 根据协议往目标地址发出控制指令。目标设备获得指令之后做出相应控制, 成功之后返回成功信息。平台获得成功信息之后刷新界面, 显示控制成功提示信息。

5.2 异常诊断

针对异常备我们提供了诊断功能, 点击控制栏诊断按钮, 平台找到所需控制设备的ID号, 确定网络地址, 根据协议往目标地址发出诊断指令。目标设备获得诊断指令之后开始探测设备状态, 完成之后返回设备状态信息。平台获得信息之后刷新界面, 显示设备诊断信息。

6 结束语

传统的校园网络平台只是单纯的平台来访问学校的应用系统和资源。而基于物联网技术的智能平台, 除了传统意义上的平台访问更具有了智能管理模式, 人们使用平台通过网络对终端设备进行控制。终端设备也可以通过网络发终端数据发送给平台。这样就达到了物与物、物与人、人与人通过网络管理的功能。

参考文献

[1]钱志鸿, 王义君, 等.物联网技术与应用研究[J].电子学报, 2012年第5期.

[2]李卢一, 郑燕林, 等.物联网在教育中的应用[J].现代教育技术, 2010年第2期.

应用系统的基础设施架构 篇7

某个应用部署在主机里, 还是部署在开放平台里;

某些应用如果部署在主机里, 是部署在同一个分区内 (同一个耦合体—Sysplex、同一个逻辑分区—Lpar、同一个交易分区—CICS) , 还是部署在不同的分区;

某些应用如果部署在开放平台里, 是部署在同一个服务器里, 还是部署在不同的服务器里;

某些应用部署在本地, 还是部署在异地 (远程) ……

下面, 我们来探讨银行基础设施宏观架构里最让架构师们纠结的问题。这些问题, 涉及服务器的部署和网络部署。至于整个基础设施架构的规划, 还会涉及一些下层的更具体的问题, 不在本文讨论的范围内。

一、银行应用系统基础设施的发展历史

(一) 史前阶段

中国银行业的电子化进程最早可以追溯到上世纪70年代中期。当时, 真正算得上用计算机处理银行业务的, 有中国银行在个别网点上用的进口小型计算机, 以及人民银行北京分行与清华大学合作、上海分行与复旦大学合作研制的国产计算机。当然, 从现在的观点看, 这些计算机的处理能力和存储容量还远不如现在的个人电脑的百分之一, 甚至不如20世纪80年代初带硬盘的个人电脑IBM/XT, IBM/AT。那时候银行计算机的应用, 仅仅用于柜台的记账, 计算机都是单机使用, 无所谓架构。

(二) 起步阶段

上世纪70年代末, 当时人民银行第一次在全国范围内有组织、有计划、较大规模地引进一批国外的计算机系统, 用于处理银行的柜台业务。20世纪80年代初, 人民银行为北京、上海、天津、广州、南京、西安6个城市采购的6套中型机, 及为其他十多个城市采购的10多套小型机陆续到货安装。当然, 从目前的技术观点看, 这批机器的性能还是不如现在的一台普通电脑。但比起原来用的机器, 已好了百倍。这批机器采用的是当时最新的技术概念, 用当时最新的技术手段制造出来。其设计原理, 已与现代的计算机无质的区别。这批计算机的引进, 使国内金融行业的计算机应用水平有了质的飞跃。正是这批机器, 产生了中国银行业现代化的计算机应用;正是这批机器, 培养了中国首批属于自己的既熟练银行业务又懂计算机的技术人员队伍。

这批机器及其升级机器一开始主要用在单机处理银行的柜台业务。先是处理“对公业务”, 后来又用来处理“对私业务”。而这两类业务分别放在机器的不同分区 (CICS) , 各自拥有自己的文件系统, 独立运行, 互不干扰。所以, 不需要特别考虑基础设施架构的问题。

(三) 发展阶段

上世纪80年代中后期, 随着微型计算机的出现和发展, 微机和小型机的银行应用系统纷纷投产。微机和小型机在中国金融业的应用得到了很大的发展。

原来的大机 (相对微机与小型机, 此时业界通常称之为主机) 的处理能力、存储容量也有了极大的提高, 银行在主机上的应用也有了非常大的发展。主机不光只是处理“对公业务”、“对私业务”, 也开始处理卡业务、国际业务等。但各类不同的业务基本上还是各自独立运行。

此时, 计算机通常都是单机运行。微机直接放置在营业点里, 主机与小型机放置在机房并通过专线直连网点。主机的联网网点数已经上百个。

由于计算机的应用已经很多, 系统设计人员要开始考虑各种应用间的关系。但在此阶段, 尽管有了多种机器, 由于电子化的投入要考虑当时银行的财力, IT规划和设计人员对基础设施的选择空间不大, 只能根据应用投产的范围及业务量, 选择合适的机器。

(四) 普及阶段

上世纪90年代, 银行计算机应用无论从广度和深度都得到极大的发展。银行要实现银行网点前台业务的全覆盖。银行的中、后台业务, 以及内部管理业务, 也开始进入计算机处理时代。随着银行业务向广度发展, 银行在全国建立了各级的计算中心。随着银行业务向深度发展, 一些银行地方分行的中心机房, 服务器从原来的几台, 发展到几十台、几百台。上世纪90年代末, 各大银行纷纷建立总行的计算机数据中心。总行中心除了几台主机外, 开放平台服务器发展到几百台、上千台。管理这么多品牌各异、性能各异、应用各异的服务器, 其工作量和难度可想而知。数据中心的管理人员开始怀念上个年代, 机房里基本只有一到两台大机的年代。

从业务发展的需求来看, 随着银行业务计算机应用的发展, 带来了大量的新业务发展。如通存通兑、电子结算、业务联动等。所有这些新应用, 大多同时涉及原来一些相对独立的业务。如代企业发工资和个人缴纳公共事业费, 就同时涉及原来的对私应用系统和对公应用系统。如信用卡透支的转账还款, 就涉及原来的信用卡系统和对私系统。原来独立运行的系统, 如何在一个交易里进行信息沟通、数据同步, 是摆在系统设计人员面前的新课题。另外, 业务的通存通兑、异地实时结算等业务, 也涉及分布在不同地域的计算机。要实现异地、跨系统的银行服务, 增加了银行应用系统的复杂性。异步处理的流程, 为银行计算机应用的可靠性也带来挑战。

为了解决上述问题, 银行系统设计人员提出了综合应用系统的概念, 并将其付诸实现。

所谓综合系统, 有两方面的概念。一是把原来在逻辑上相互独立的应用系统放在一个逻辑系统内, 如对公、对私、信用卡系统都放在一起。那么, 原来跨应用系统的应用就可以在一个系统内同步、可靠地完成。二是通过计算中心集中, 让一个计算中心覆盖更广泛的地域范围。这样, 在一个数据中心覆盖的范围内, 原来异地结算的动作变成是同一机器内部的动作, 也完全可以同步、可靠地完成。综合系统极大地简化了程序的复杂度。

在上世纪90年代, 综合系统是一个非常时髦的词。有人将其口号化为:“一机打尽”、“一网打尽”。综合系统也是各银行应用系统追求的目标。银行在这个阶段追求的是一种大统一的计算机基础设施架构。这是一个从分散到集中的过程。集中, 是对分散的一种否定。

(五) 信息化阶段

时间来到21世纪。在这个世纪的头5年, 各银行都在走大集中的路。特别是国内几个最大的银行, 基本都完成了“一网打尽”的目标。从银行IT基础设施架构看, 总行建立了全行性的数据中心, 所有核心银行的数据处理都集中到总行。分布在各省的数据中心基本都陆续变为网络节点和数据的中转站。对于已经集中在一个数据中心内的各省银行数据, 完全解决了异地数据同步更新的技术问题, 从而极大地推进了一些跨地域业务的发展及其电子化。

另一方面, 在大集中的过程, 随着全新的银行综合应用系统投产, 应用的集中也有了进展。许多新的应用系统, 都力图把核心银行的所有功能部署在主机上。尽管对核心银行的定义和内涵各有不同的解读。

银行计算机应用基础设施上述两方面的发展, 部分实现了银行IT人员的梦想。大集中后, 银行的计算机应用从电子化跨进信息化。

在银行计算机应用信息化的进程里, 银行的业务发展方向从外延进入到内涵, 从追求数量变为追求质量。银行计算机应用的发展也不再是单单追求广度, 更重要的是追求深度。

银行计算机应用信息化, 使银行的整个计算机应用系统的应用不单涵盖了对银行客户的前、中、后台服务, 并为银行客户提供了大量新兴服务如B2B, B2C, C2C, 金融代理、金融衍生产品等电子业务服务。还涵盖了银行的风险控制、内部管理、内部办公、信息挖掘与决策等一系列的内部应用。所有这些应用, 一方面种类繁多, 另一方面与时俱进、发展迅速。如何考虑这些应用的基础设施架构, 是摆在架构师们面前的新问题。如果还是坚持架构大集中的观点, 把这类应用也部署在主机上, 一是成本高, 二是灵活性不足。并且, 很多这类应用还涉及外购的应用平台, 而这些平台大多要么本身是运行在开放平台, 要么是一些专用平台。

信息化对基础设施架构的影响是, 银行机房的服务器一方面根据管理人员的要求及架构师的设想, 通过不断地把应用往主机迁移, 服务器纵向扩容, 在集中、在减少。但另一方面, 随着各种新兴应用的快速增长, 服务器也在快速增长。并且, 服务器增长的速度远高于减少的速度, 而增加的服务器几乎100%都是开放平台服务器。大银行的中心机房服务器数量动辄以千计算, 这是对基础设施架构分散—集中发展的否定之否定。

基础设施架构的发展方向究竟如何, 上述情况是否正常, 所有人都在问。

二、面向服务的IT基础设施架构

在新一代的IT架构里, 应用系统应该是面向服务的, 基础设施架构也应该是面向服务的。基于面向服务的基础设施架构, 是如何面对原来困扰架构师们的一些问题呢?

(一) 问题解构

前面说到, 宏观的基础设施架构涉及3个问题:主机与开放平台、是否共用服务器、本地还是远程。

在银行的计算机应用发展历程中, 大型计算机主机 (Mainframe) 一直处于核心地位。特别在大型银行计算机应用系统里, 主机一直是不可替代的, 其处理的对象往往是核心银行业务。

随着计算机技术的发展, 开放平台的处理能力和可靠性与主机的差距越来越少。而在其他方面, 如应用成本、灵活性、方便性等, 可能比主机有更好的性价比。并且, 当前的主机供应商只剩一家, 而开放平台还基本保持多家竞争的态势。总体来说, 开放平台的技术发展要快于主机, 也让用户有更多的选择。

随着主机的许多好概念在开放平台上实现, 开放平台的一些优点也被主机采用。主机目前也叫服务器, 可以支持各种开放平台的操作系统和数据库。可以说, 主机与开放平台在双向靠近。银行的应用也在计算机技术的发展中朝着大量使用开放平台的方向发展。

在介绍SOA概念的时候, 一个非常重要的概念是松耦合。松耦合既包含了应用模块之间的松耦合, 还包含了应用与应用平台之间、应用与编程语言、数据库、硬件之间的松耦合。应用系统的宏观应用架构不应该强求规定哪一项服务必须部署在哪种机器里, 也不应强求规定该服务是在本地还是远程, 更不应该与服务是否部署在相同的服务器相关。可以说, 一个现代的系统架构师, 在按SOA概念设计宏观应用架构时, 如果首先考虑的是服务部署在主机还是部署在开放平台上, 部署在本地还是异地、是否部署在相同的服务器里, 那他根本不是一个称职的SOA系统架构师。

在面向服务的计算机应用环境中, 一方面, 系统设计应该考虑大多数的应用既可以部署在主机, 也可以部署在开放平台;既可以部署在同一台服务器里, 也可以部署在不同的服务器;既可以部署在本地, 也可以部署在远程。另一方面, 基础设施的宏观架构基本上与机器是大机还是开放平台无关, 与机器在本地还是在远程无关。在这个架构中, 一方面, 从硬件的角度, 我们把大机和开放平台都当作某种服务器, 都是可以提供一种或多种服务的服务载体。另一方面, 从面向服务的概念来看, 如果应用间已经是以服务的方式关联, 那么与之相关的应用是否在相同的服务器里, 是在本地还是远程, 面向服务的应用本身是可以不需要关心的。这方面的功能应该留给流程控制逻辑和路由控制逻辑去解决, 留给服务交付—系统的企业总线去解决。至于应用最终如何部署, 应该让具体的基础设施架构师根据处理能力、数据容量、数据流量、安全性、价格、管理等各方面因素去进行详细分析、设计和定案。

(二) 基础设施云

基础设施架构发展到今天, 从分散到集中, 又从集中到分散。与任何事物发展一样, 这种否定之否定, 其实有它内在的原因, 是符合事物发展规律的。从分散到集中, 应用耦合度增加, 应用交互更容易, 系统管理更简单、运行更可靠。从集中再到分散, 是为了解决应用过度耦合, 解决大规模系统向更进一步发展的瓶颈问题。否定之否定不是简单地回到从前, 而是螺旋向上。虽然在水平方向好像在同一经纬度, 但在垂直方向已经是一个更高的高度。从分散到集中, 是应用的集中;从集中到分散, 是服务的分散。

当前, 云计算是一个非常热门的话题, 全世界都在搞云计算。其实, 原来中国大银行的集中系统就是一种云计算的模型, 只不过不是完全开放的公众云。使用银行系统的银行客户与银行员工, 他们不需要知道他们的服务要求被送到哪里, 也不需要关心处理他们服务要求的计算机的具体形态:有多大的处理能力, 有多大的数据容量。在一些银行, 为了成本核算, 早就在内部实现按业务量、按数据量进行收费。

随着社会网络技术的发展, 网络带宽迅速提高, 流量成本不断下降, 网络安全技术日趋成熟, 极大地推动银行的基础设施架构进一步向“云”方向发展。银行从运行成本、战略安全等方面考虑, 也不可能把所有处理能力和存储能力都由一台或几台服务器承载, 或放在同一个机房、同一个地方。随着银行计算机基础设施架构也面向服务, 对基础设施的要求已经不需要再受“大机还是开放平台”、“本地还是远程”所约束。基础设施架构的“云”发展就可行并顺理成章。在“云”架构建设上, 一开始, 是渠道多点接入, 两地三中心的灾备。然后, 考虑多中心的双活、考虑多中心的负载均衡, 最后, 考虑服务分散, 服务灾备。逐步走向完全的“云架构”。

(三) 基础设施架构的举例

下面, 是一个银行宏观基础设施架构的举例。在图1中, 每一个方框代表一种服务。服务对承载服务的服务器没有特别的限定, 多个服务也可以部署在一台物理服务器里。对服务器部署在本地还是远程也没有特别的限定。

对于部署在大机和大型服务器上的服务, 它可能提供超过一种的基本服务或者提供某种综合的服务。对于提供多种基本服务的服务器, 从物理上, 它是一个服务器, 但我们可以从概念上或者逻辑上认为它是多个服务器。