开篇
上篇,我们介绍了,单机软件的架构,其实不管什么软件系统,都是为了解决实际中的一些问题,软件上为了更好的解决实际的问题才会产生,那么对于单机软
件的架构则也是在不断的变化和发展,当然好的软件架构会对软件的生命周期起到决定的作用。好的软件架构,无疑会延长单机软件的生命周期,同时适应后期的不断的衍生的需求变化,.NET FrameWork的架构设计和体系结构设计,我相信是非常优秀的。
本篇,将会讲述大家比较常见的架构模式,客户端-服务器的模式,可以理解成C/S架构模式。现在的C/S架构已经从原来的简单的客户端-服务器的形式,变成了
更多衍生的架构模式,C/A/S,C/S/M/S。包括多层C/S的架构。本篇就将总结这些架构模式之间的细微变化和应用场景来简单说明,当然由于本人的经验和学识不够,
错误之处,还请大家多多指出。
大纲
1、开篇
2、大纲
3、C/S架构的产生
4、C/S架构的常见场景和架构模式演变
5、C/S架构总结及说明
C/S架构
C/S和B/S架构我想大家应该都还是比较了解其本质和区别的。
wiki百科的定义:
C/S(Client/Server)结构,即大家熟知的客户机和服务器结构。它是软件系统体系结构,通过它可以充分利用两端硬件环境的优势,将任务合理分配到Client端和
Server端来实现,降低了系统的通讯开销。目前大多数应用软件系统都是Client/Server形式的两层结构,C/S的优点是能充分发挥客户端PC的处理能力,很多工作可以
在客户端处理后再提交给服务器。对应的优点就是客户端响应速度快。
有不少的朋友和我争辩,未来是B/S的天下,这种C/S的架构模式,可能就会越来越少,甚至被取代,话说,我的理解是这样的,任何一种架构模式的存在,还是
那句话,都是为了目前解决不同应用场景的问题而存在的。所以关于未来是否被取代我们还不好轻易的下结论,但是有一点,如果我们回归本质去看的话,你回发现,浏览器本身就是C/S程序的,除非某一天,我们不需要浏览器,即可上网的时候,也许我将会同意你的观点。
科技发展的步伐不断的进步,C/S的传统架构可能是这样的。
这里应该比较容易理解,我们把业务逻辑都写在客户端应用程序内部,客户端这时候,就是富客户端的形式,只需要读
取信息或则是写回信息的时候访问数据库,这时候我们可以把数据库看作是服务器端。这样的方式,应该是目前很多的软件都是这么构建的吧,当然可能现阶段很多
新的软件的架构模式已经发生了变化了,不是简单的这样的结构,因为无论是应用的集成或者是后续的扩展等这样的架构方式,无疑都是需要大批量的修改程序才能
实现的,并且在性能等各方面都会有瓶颈。
对于与C/S相对应的架构B/S我们来看,一般的方式如下:
上面我给出的是一般的B/S应用的物理部署架构。
我们回归下我们上面说的浏览器本身就是个客户端软件,通过DNS域名解析服务器,向指定的web服务器发送请求,web服务器根据用户的请求,来产生HTML文
档,处理的过程中需要访问数据库,处理完毕后,返回给客户端浏览器,浏览器根据返回的信息,进行渲染呈现到浏览器客户端。我上面只是大体的介绍了下过程,
并没有把很多细节说明白。下面我们就来看看C/S架构的不断衍生和变种。
C/S架构的场景及架构模式演变
我们上节也说了,C/S架构经过不断的改进,目前已经衍生出很多的架构模式,我们下面就来回顾和分析,每种架构模式的一般应用场景。
1、客户端包含业务
客户端应用程序,内部包含了业务逻辑处理,只是在必要的时候请求和访问数据库。进行数据的持久化
操作。
这种模式的应用场景:一般应用于需要客户端提供富应用的情况,比如医院信息系统。
这种模式的代表语言:PB,VB,Delphi等。当然.NET的Winfrom应用程序,这样的也有不少。
优点:可以重复利用PC资源,降低服务器的压力,符合用户的操作习惯,用户体验较好。
缺点:安装和更新麻烦,不轻便,信息共享比较麻烦,互联网上没有办法进行访问。
2、C/A/S架构
这种结构看起来强大多了,为啥呢,客户端是轻量级的了,和浏览器差不多,不但提供了强大的用户体验和符合用户的传统软件的操作方式,同时不会像胖客
户端一样,那么重,该客户端还能支持自动升级。
应用服务器:负责处理客户端提交的复杂应用,当然后如果客户端用户量大的时候,可以通过一些措施来将请求进行任务的分发等,这个就是我们后面说的
多层了。这里应用服务器是负责处理客户端发送的请求信息处理,带有与数据库数据相关的业务逻辑操作时,客户端将请求打发送到应用服务器,应用服务器接收请
求,并进行处理。应用服务器会根据客户端的请求,访问数据库,并进行业务逻辑处理,将处理完成后的结果,返回给客户端,客户端显示结果。
这样,客户端内部只要包含必要的组件即可,所有的业务处理过程都通过应用服务器来完成。这样会大大的降低客户端的运行效率,同时为日后的用户增
长,提供了水平扩展的基础。
3、多次C/S结构
上面我们讲述了,C/A/S的已经比较强大的结构了,不但提供了类似浏览器的支持互联网访问,同时具有很好的用户体验。
下面我们来看看基于上述架构产生的新的物理架构模式。
当然,随着服务器性能的提速,我们会发现,其实并不是CPU慢,也不是内存不够用,所有的性能瓶颈,全部都是出现在IO,这个问题,不管是现在谈的任何
的逻辑架构,物理架构,或者是数据架构,一般来说,都是为了解决IO瓶颈方面的问题。我们不放仔细的考虑考虑目前的很多上市的大公司,不管是互联网的还是工
具类的。一旦数据量大,请求的响应效果,关键点就是在IO。
我们学过计算机组成原理,我们能知道内存和CPU之间有差,数量级上就有差别,硬盘和内存之间,又有数量级上的差别,所以这CPU一般来说,不进行多任务
或者大量运算的时候,瓶颈一般不会出现在这里了。
4、还是多层
当然可以是数据库集群,或者是分布式数据库存储的结构。
5、分布式应用
分布式应用部署服务器,实现业务切分的部署。
6、SOA架构
上面我们说了基本上目前的比较流行的物理架构的部署方式。
下面我们来说下,关于C/S的逻辑架构。
先说胖客户端。
慢慢演变:
再抽象。
这样还不行,因为这样在UI上,还会不太合适。所以衍生出MVC架构,一般MVC模式适用在Web上,C/S上一般不会这么采用这样的方式,目前流行的J2EE开发框架,如JSF、Struts、Spring、Hibernate等及它们之间的组合,如Struts+Spring+Hibernate(SSH)、JSP+Spring+Hibernate等都是面向MVC架构的。.NET下大家应该都
了解过ASP.NET MVC吧。
一般来说,现在的架构,都不是简单的这些模式了,都已经依托于某一集成框架,或者是应用开发平台,通过平台提供的中间件,实现多种系统的整合或者交
互,通过这些中间件提供的强大功能,使我们可以专注业务需求,而不用考虑太多的非功能性需求。
C/S架构总结
上面我们讲述了比较常见的C/S架构的模式及演变,其实逻辑架构的方面,总体来说,变化不会太大的,一般都是这些模式,关于如何分层,分层多细,那需要
看项目的具体需求和非功能的需求,包括应用部署的要求等。
随着目前互联网应用的普及和快速发展,未来生活互联网应用的天下,这个是没有任何的疑问和问题的,但是我们也能看出来未来C/S架构的发展和商机,目前
不管是任何大公司,都在推广自己的基础平台,在平台之上发展应用,通过SAAS的方式,提供方便的购买服务的商店,这样不但能够方便用户使用好的应用服务,
而且也为开发人员提供了商机,所以目前C/S架构的模式越来越多的向SOA和SAAS方向转变。
我们应该认清形式和方向,如果发展自主创新的道路,那么必须要考虑未来,架构设计则是适应未来需求和公司发展的关键,这也是目前火热的SOA架构对企业
战略影响的关键所在。大伙都知道,名词吧,大家都会说,但是实践的过程中总是困难重重,但是如果因为困难就放弃,那么相信企业也会因为困难而倒闭。在中
国,经营企业是困难的。
扯得有点多了,C/S架构的发展,未来定是上述的走基础平台,应用整合,SAAS方面的,C/S可能越来越少,但是不会被取代。目前桌面的应用软件,多数都是
这样的模式,越来越多,我相信大家都司空见惯了。现在的有远见的公司,都知道关注企业的未来发展,所以抢占手机和浏览器市场,通过用户的粘度,来维持企业
的可持续发展和商业价值空间。
商业和架构能扯上什么关系,其实仔细想想是有关联的,好的基础可以有好的发展,好的公司,如果没有可持续的眼光和基础,注定要失败,最近比较火热的一
篇口水贴,也能看出端倪,大公司为什么要打造自己的平台,是有原因的。
每个公司都想要,可惜,可能因各种原因,没有搭建起来,这个时候,就可以考虑低投入,高回报的方式,通过购买现有市面比较好一些的基础平台,不但能够
瞬间增强企业活力,同时提升企业的竞争力,最快的速度抢占市场。未来云计算是趋势,没办法的事情。当一个人说的时候,你不信,二个人说的时候你还不信,当
周围的人都信的时候,你就相信了。虽然很多人大喊云里雾里。
方案有很多,关键是看你是否抓住机会,机遇总是被有准备的人抓住。
目前,我们已完成了第一步:SAAS。
相关信息
下载信息。
如果您在使用AgileEAS.NET开发平台中有什么问题,请使用如下几种联系方式或者沟通方式。
1、电话-邮箱方式:
何戈洲:hegezhou_hot@163.com 手机:18691480181 博客:http://www.cnblogs.com/hegezhou_hot/
2、QQ交流:
308961614 -网名:H.O.T
3、QQ交流群:
185074255 新建
AgileEAS.NET快速开发平台下载
本文转自健哥的数据花园博客园博客,原文链接:http://www.cnblogs.com/hegezhou_hot/archive/2011/11/07/2238983.html,如需转载请自行联系原作者