为什么采用C/S体系结构-阿里云开发者社区

开发者社区> 数据库> 正文

为什么采用C/S体系结构

简介: 为什么采用C/S体系结构 作者:余彤鹰 目 录 1. 引言2. C/S体系结构简介  2.1 C/S结构的数据库应用  2.2 非C/S结构的应用3. 是否采用C/S体系结构的讨论  3.1 当前确定的需求  3.2 潜在和不确定的需求  3.3 未来的需求  3.4 成本和资源的考虑  3.5 发布、运行与维护的考虑  3.6 性能、开发与品质保证的考虑4. 小结 1 引言   当为客户开发一个定制的数据库应用时,我们考察了采用客户/服务器体系结构(Client/Server Architecture)的必要性。

为什么采用C/S体系结构

作者:余彤鹰

目 录

1. 引言
2. C/S体系结构简介
  2.1 C/S结构的数据库应用
  2.2 非C/S结构的应用
3. 是否采用C/S体系结构的讨论
  3.1 当前确定的需求
  3.2 潜在和不确定的需求
  3.3 未来的需求
  3.4 成本和资源的考虑
  3.5 发布、运行与维护的考虑
  3.6 性能、开发与品质保证的考虑
4. 小结

1 引言

  当为客户开发一个定制的数据库应用时,我们考察了采用客户/服务器体系结构(Client/Server Architecture)的必要性。为什么要采用C/S体系结构?先进、性能、潮流等都不是问题的实质。真实答案来自对客户现在、未来和潜在需求的研究。

2 C/S体系结构简介

2.1 C/S结构的数据库应用

  最简单的C/S体系结构的数据库应用,由两部分组成,即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器,称为应用服务器,一旦服务器程序被启动,就随时等待响应客户程序发来的请求;客户程序运行在用户自己的电脑上,对应于服务器电脑,可称为客户电脑。当需要对数据库中的数据进行任何操作时,客户程序就自动地寻找服务器程序,并向其发出请求,服务器程序根据预定的规则作出应答,送回结果。

  在典型的C/S数据库应用中,数据的储存管理功能,是由服务器程序独立进行的,并且通常把那些不同的(不管是已知还是未知的)前台应用所不能违反的规则,在服务器程序中集中实现,例如访问者的权限,编号不准重复、必须有客户才能建立定单这样的规则。所有这些,对于工作在前台程序上的最终用户,是“透明”的,他们无须过问(通常也无法干涉)这背后的过程,就可以完成自己的一切工作。在客户服务器架构的应用中,前台程序可以变的非常“瘦小”,麻烦的事情,都交给了服务器和网络。在C/S体系的下,数据库真正变成了公共、专业化的仓库,受到独立的专门管理。

2.2 非C/S结构的应用

  与C/S体系形成对比,传统的数据库应用体系结构,例如基于主机-多终端的系统,或基于LAN上文件服务器运做的多用户系统,数据库是属于应用程序“私有的”,即使它也可以将数据文件放置在某台机器上供不同的用户共同访问(这种情形,称为“文件服务器”),但所有的操作、规则,都是在一个包罗万象的应用程序内部实现的。应用程序因此具有最大的复杂性,即使是原班开发人马,要想对已有功能加以扩充也是很困难的,当数据库稍具复杂性(比如有稍多相互关联的表与规则),其他的人员开发另外的程序共同操作这个数据库的数据,几乎不具可行性。

3 是否采用C/S体系结构的讨论

3.1 当前确定的需求

  在这个案例中,已经确定的需求,就是建立一个集中、统一的数据库,实现更新、查询和格式化打印输出操作。访问者分布在总公司(约30人的规模,集中办公,连结于一个小型的LAN中)和外地的子公司(同样是集中办公,连结于一个比总公司大的LAN中)。每一处典型的同时访问人数,在10人以下。两处都有机会更新数据库中的数据。理想的情况下当然是两处的数据随时保持一致,但在特别关键的信息可以随时通过电话、传真等方式直接交换的情况下,两地的信息每隔一至二天交换更新一次,是可以接受的,这也就是目前的实际情况,从业务人员的立场上,尚没有提出在这个周期上作出戏剧性的改变的要求。针对当前的已经明确的需求,作出如下讨论:

  采用C/S架构,选择适当的数据库平台,可以实现数据库数据的真正“统一”,分布于两地的数据同步完全交由数据库系统去管理,逻辑上,两地的操作者都直接访问同一个数据库。它的有效实现,有这样一些问题:

  1. 如果需要建立“实时”的数据同步,就必须在两地间建立实时的通讯连接,保持两地的数据库服务器在线运行,这需要高昂的投资和复杂的技术支持,高的维护成本。
  2. 可以根据实际的需要,采用“间歇”同步策略,通过合理分配两地的工作(这一点是现实业务中已经很好地实现的),基本可以避免分别更新数据可能对业务带来的问题。对数据库同步更新的间隔,可以天为最小单位,在这样的同步需求下,采用复杂和昂贵的“分布式数据库”管理技术[注1],是不划算的。

  在该案例中,当前需求的一个重要特征,是在LAN中的多用户操作。进一步分析该客户的要求可以得知,数据更新的频率是很低和集中于少数用户的。大量可能的并发性操作来自查询。

  对于本例的应用要求和环境,采用基于网络文件服务器开发非C/S结构的应用,也完全可以满足,虽然C/S结构下的多用户应用可以更好(比如更完善的用户共享特性,用户管理,以及更好地平衡服务器与客户机之间的负荷,大幅度降低网络传输的负荷等),但就用户立场而言,并没有采用C/S结构直接的必要性。

[注1]:应当说明,对于其他的架构的数据库体系,同样可以实现分布式的数据存储与管理,但从本例实现的角度看,比起基于C/S架构的体系,要复杂和昂贵。

3.2 潜在和不确定的需求

  在电脑应用定制开发的领域,要想真正令客户满意,就必须真正理解用户的需求,尤其是那些潜在的需求。比如,上述对数据同步更新频率的需求,是基于现在的业务方式与节奏的,一旦电脑系统投入应用,改变了整个作业的节奏,就可能提出更高的要求。此外,公司的业务量的不断发展,客户对于公司作出反映的时间的提高,都会导致对电脑系统需求的提高。

  在这个案例中,用户的应用方式和规则具有不确定性和不断改变发展的特征,但数据库描述的基本对象却具有相对稳定、有序扩充的特点,因而数据库的结构相对稳定,也就是说,基于对实体的深入分析和抽象作出的数据表是相对稳定的,随着未来的发展,多数的变化将是新表的增加及数据项的增加,而较少更改。

  针对这个特征最直接有效的策略,就是将易变的部分(应用和应用规则)和相对稳定的部分(数据和基本属性、结构)分离,这正是C/S结构数据库应用的典型模式。

  从原理和经验上看,对本案例或类似的应用,C/S结构是目前技术条件下,能较好适应不确定和变化的需求环境的比较现实的方案。它可以令我们以较低的投入,实现将易变与稳定的要素分离,快速地增添和替换“瘦小”而互相独立的前台应用,保持数据的连续性和继承性。

3.3 未来的需求

  在这个案例中,用户确认了这样的应用发展策略:由点到面,由简到繁逐步引进电脑化作业方法,稳步改进日常的业务模式,并期望于时机成熟的时候开展基于信息技术的业务流程重规划。

  具体应用的规划是:先建立简单有效的数据库应用,进一步开发更多的,更具专业性、更深入的应用项目,进而在更大的范围上应用,最终期望将客户也纳入到电脑系统的用户中来,实现客户与销售人员的远程在线查询、下单。在指导性的发展规划中,具体提出了企业内部的互连网(Intranet)和面向国际互连网(Internet)的应用远景。

  在这样的应用策略下,对电脑应用的开发,将是一个逐步完善的过程,对这样的开发环境,上一节中已经做了分析。

  cnew_s.gif (86 bytes)以目前的技术看,先建立C/S结构的局域网络应用,再向Internet/Intranet模式下数据库应用过渡,是比较现实,相对易于把握、成本较低的。即使是一次到位的开发,对于类似的环境和小型的应用而言,要想实现不同的人员,从不同的地点,以不同的接入方式(比如LAN, WAN, Internet/Intranet等)访问和操作共同的数据库,并有效地保证和管理数据的安全性、访问权限、完整性,采用C/S架构和支持C/S架构的数据平台,是必然选择。

3.4 成本和资源的考虑

  由于用户已经建立并运行着LAN、文件服务器,并运行着(并且以后也要继续运行)一些基于PC或PC LAN的应用,现行的硬件设备基本上不用大的扩充,就可以运行基于文件服务器的多用户数据库或基于应用服务器的C/S应用。

  采用C/S体系结构,客户所支出的费用项目,将增加数据库平台和对其维护的成本,和可能需要增加适合数据库平台运行的应用服务器操作系统。

  这样,从现有资源出发,不考虑开发的成本,最直接而经济的实现方案,是建立基于文件服务器的多用户系统,其次才是C/S体系结构。相比之下,主机模式无论从软硬件投资、开发成本上都是巨大的,没有什么理由替代前两种模式。

3.5 发布、运行与维护的考虑

  由于数据库用户的地理位置和数量增加的可能,需要考虑安装上的因素。C/S结构的应用至少需要设置客户和服务器两个项目,而基于文件服务器的应用,通常只需要一次性的安装和设置。现在的客户服务器开发技术,可以将客户端作成简单复制一个瘦小的执行文件就可以运行,客户端通常没有维护的要求,对服务器的安装设置则是一次性的。

  对于非C/S架构的数据库系统来说,维护方面的性能也是在应用程序的开发中决定的。这样的系统,通常都需要原设计开发者才能比较好地维护。

  C/S架构的数据库系统,由于数据库是建立在通用的平台之上,并且支持SQL这样的通用技术,对数据库的维护工作更加专业,但更为开放,这意味着维护和进一步开发对原设计开发者的依赖性可以降低。用户可以更好地适应人员的流动或服务/供应商的变更。对体系规划的合理性,和一些特殊技术的采用,例如后台服务器上的存储过程、触发器等,会影响到这个特点。出于这个理由,在C/S应用设计时,应尽可能采用规范的模式,标准化的技术。同样的努力,在其他架构中就相对难以实现或较少实际意义。

3.6 性能、开发与品质保证的考虑

  非C/S结构应用的性能,更大程度取决于应用程序的设计与实现。基于文件服务器运行的多用户系统,当数据量、用户数扩大时,性能就会严重下降,这包括巨大的网络传输量,以及难以有效地平衡工作站与服务器的负荷。因此,大的数据容量和多用户环境,通常是采纳C/S结构的一个重要理由。主机-终端模式虽然可能更具能量,但高成本和封闭性,限制了它的应用领域。

  从运行上来看,同样设计良好的系统,C/S结构引入了更多的“衔接”环节,这意味着故障的机会和资源的耗费,然而,一旦系统处于开放的网络与应用环境中,这些开销就变成是必须的。

  对于具备良好的规划能力的开发者而言,C/S结构给予规划者更大的空间和更强的支持,易于实现不同应用间的合理分离,分别调试和投入应用。前台应用和后台数据库的开发,被“强制”地分开;数据库部分的逻辑与规则,一经调试完成,就可以在将来的应用中一直保证下去;在一个动态改进或逐步扩充的开发环境,或复杂的应用环境中,这些都是提高系统可靠性有利因素。对基于文件服务器的系统而言,每次增加或修改功能,通常都意味着整个系统的升级,前后台的一体化,也就意味着每次变更都有更大的可能性造成对原有规则的破坏,并引起连锁效应。  

  以目前的技术环境而言,在C/S结构下,有更多成熟的,适合不同规模应用的开发平台与数据库平台可供选择,并普遍遵循或采用SQL等标准或技术,相对较具开放性,有更多的技术支持、开发与维护人员的来源,并且——基于技术与行业发展的趋势,将来也会有更多的发展和保障。

4 小结

  总结以上的种种分析,可以发现,对于这个特定的案例,仅就当前已确定的和希望马上实现的需求而言,可以用传统的,基于LAN的文件服务器的多用户系统实现,但考虑到用户真实需求的不确定性和不断扩充的可能等等因素,有更多的理由支持采用C/S体系结构。作为一种权宜的方案,也可以考虑先采用基于文件服务器的多用户系统,在规划和实现上,尽量为将适当时候来转换成为C/S结构打下基础。此外,如果采用C/S体系结构,还应当尽可能采用开放的,标准的技术。

  在上面的分析中,支持采用C/S的理由主要有:

  • 应用的不确定性,逐步开发和增加新应用的需要
  • 适应将来开放的异种网络环境中应用的需要
  • 用户数、数据量增长的可能性
  • 适应电脑开发、维护、供应商与相关技术人员变更的需要
  • 有利于动态规划与动态开发过程,对系统可靠性的保证

  cnew_s.gif (86 bytes)此外,从用户的现有资源的延续利用与新增投入,及开发的成本和难度看,采用C/S结构,也是比较适中、现实的选择。

  读者应当留意,这里仅仅是针对一个特定环境下小型应用案例开发策略的分析,而不是对数据库体系结构的一个完整的分析比较,更不是对技术本身的评价。

发表日期:1999-03-05
更新日期:1999-03-14   对一些阐述不清楚或易于引起误解的地方进行了修改,部分标明。


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章