系统架构师-基础到企业应用架构-客户端/服务器

开篇

上篇,我们介绍了,单机软件的架构,其实不管什么软件系统,都是为了解决实际中的一些问题,软件上为了更好的解决实际的问题才会产生,那么对于单机软

件的架构则也是在不断的变化和发展,当然好的软件架构会对软件的生命周期起到决定的作用。好的软件架构,无疑会延长单机软件的生命周期,同时适应后期的不断的衍生的需求变化,.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、电话-邮箱方式:

何戈洲:[email protected] 手机:18691480181 博客:http://www.cnblogs.com/hegezhou_hot/

2、QQ交流:

308961614 -网名:H.O.T

3、QQ交流群:

185074255 新建

AgileEAS.NET快速开发平台下载

 请点击图片下载。

时间: 2024-09-30 06:37:19

系统架构师-基础到企业应用架构-客户端/服务器的相关文章

系统架构师-基础到企业应用架构-业务逻辑层

一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开发方式,而目前更多的是面向对象的开发设计方式.并且我们也讲述了该如何通过设计手段去分析功能点及设计分离 点,应该如何在设计的过程中分析的角度及如何去满足设计规范与原则.首先我们通过下图来回顾下上章要点: 二.摘要 本文将已架构的方式去分析分层结构中的业务层的设计,如何写出来内聚度,高耦合的业务逻辑层

系统架构师-基础到企业应用架构-系列索引

系统架构师-基础到企业应用架构-索引 系统架构师-基础到企业应用架构系列会从,系统架构的起源.发展.架构师必备的基础知识与技能.如何把架构应用到企业应用中去.整个系列计划30篇左右,每 一篇都是自己在系统架构过程中的总结和经验,每一篇我都会抱着认真的态度去完成,宁缺毋滥的原则.希望本系列看完之后不但能够帮助看过这个系列的人对系统架 构有深刻的认识,并且能够掌握系统架构中的必备知识,应用到自己的工作中去,更可以共同提高大家的个人能力.本系列希望能够抛砖引玉,希望大家能够多提出宝 贵意见. 前篇 1

系统架构师-基础到企业应用架构-系统设计规范与原则[上篇]1

一.上章回顾 在上篇中我们讲解了几类UML2.0语言新推出的建模图形,总体来说通过这些图形能更详细的将某类信息表达出来.在这里我们简单回顾上篇讲解的内容. 上图中已经简单介绍了上章讲述的内容,具体内容请看:系统架构师-基础到企业应用架构-系统建模[下篇]. 二.摘要 本章将主要的简单介绍在系统架构中的设计模式及相应规范准则.并结合相应的代码来说明如何遵循系统架构中的一些基本的设计规范及准则.而我们将在本文介 绍几类常用的设计规范,我们先来看看结构化设计的二个基本原则: 当然既然提出了基本的准则,

系统架构师-基础到企业应用架构-服务层

一.上章回顾 上篇我们主要讲解了系统架构中的四种架构模式,并且分析了四种架构模式的实现及应用场景,那么先来回顾下架构中的业务逻辑层的使用及总结.  如果大家对图中讲述的内容不明白或者说是不深入那么可以参考上篇讲 解的内容:系统架构师-基础到企业应用架构-业务逻辑层. 二.摘要 本文将已架构的方式去分析分层结构中的服务层的设计,如何设计出来满足我们说的业务需求及设计规范的服务层将是我们的目标,可能我想大家在项目架构的 过程中可能有些同仁,没有用到该层,或者说是采用的是常用的分层结构的设计,而没有把

系统架构师-基础到企业应用架构-企业应用架构

一.上篇回顾 我们先来回顾下上篇讲解的内容,我们前面的几节分别讲述了,业务逻辑层.数据访问层.服务层.表现层,我们了解了这些分层的职责和分层之间的大概的关联 关系,本篇可能主要是简单的介绍下企业应用的几类模式,结合这几个分层直接的交互来完成系统功能的构建.我们还是先对我们学习的四个分层的职责和功能做个大 概的回顾,我们先来看看下图来回顾下我们讲述的内容. 我想通过上图,大家能回忆起我们讲述的相关内容,然后整理好自己的思路,我们本文将会针对这几个分层进行相应的模式的讲解,并且会结合实例来说明企业应

系统架构师-基础到企业应用架构-系统建模[中篇](下)

一.上章回顾 首先.我们先来回顾下,上篇讲解的内容,加深下印象.上篇我们主要讲解了3个建模图形分别是:顺序图(序列图).组件图.状态图. 具体功能描述如下图:这里不详细解释,如果不清楚请看:系统架构师-基础到企业应用架构-系统建模[中篇](上) 由于全部放在一篇中篇幅太长了,所以分开讲解. 二.摘要 本文主要讲解:UML建模图中的活动图.部署图等 上图中就是本章要讲解的内容,本质将仔细的剖析,部署图与组件图的关系与区别,活动图与状态图的关系与区别. 三.本章内容 1.上章回顾. 2.摘要. 3.

系统架构师-基础到企业应用架构-系统建模[中篇](上)

一.上章回顾 上篇文章主要简单的介绍了建模中使用的标准建模语言UML的相关内容,包括用例图与类图的使用方法及如何建模.相信大家对UML建模语言已经有了初步的认 识,还请大家谨记UML不同的建模图形的用处.比如,用例图主要用来描述系统的功能需求.类图主要用来描述实体间的关系.谨记这些就可以帮助我们在系统架构的 过程中深入的分析. 首先向大家道歉,上篇中有部分描述错误的地方,可能对大家造成一定的错误引导.  这是上篇给出的图,我描述的是组合关系. 特别更正为:  这是正确的结果.箭头指向聚合类.描述

系统架构师-基础到企业应用架构-数据访问层

一.上章回顾 上篇我们简单讲述了服务层架构模式中的几种,并且讲解了服务层的作用及相关的设计规范,其实我们应该知道,在业务逻辑层中使用领域模型中使用服务层才 能发挥出最大的优势,如果说我们在业务逻辑层还是使用非领域模型的模式话,服务层的作用仅体现在解耦作用.其实在业务逻辑层采用领域模型时,我们前面说的持 久化透明的技术,其实我们可以通过服务层来做,我们在服务层中处理领域对象信息的持久化操作.当然本篇可能不会深入讨论持久化透明的具体实现,后面会单独开 篇来讲述,我们先来回顾下上篇讲解的内容:  上图

系统架构师-基础到企业应用架构-单机软件架构

开篇 系统架构的文章系列,也是搁浅的太久了,最近也是整理了下思路,将目前未完成的内容,写完吧,也不能拖太久,就不太好了.所以就趁周末写一下,今天我 们要说的是单机应用,单击应用软件可以很复杂,也可以很简单.有些单机软件可以没有数据库,也可以有数据库,比如我们平时的一些工具类的软件,写字板,V S开发工具等,当然,目前很多的单机软件都有联网的功能,单机软件,估计大家有时候回想,单机软件不需要什么特殊的架构设计吧,其实不然,因为有的时候我 们的单机工具,可能是提供给不同的用户群体等,或者是面向不同的