开篇
上篇，我们介绍了，单机软件的架构，其实不管什么软件系统，都是为了解决实际中的一些问题，软件上为了更好的解决实际的问题才会产生，那么对于单机软
件的架构则也是在不断的变化和发展，当然好的软件架构会对软件的生命周期起到决定的作用。好的软件架构，无疑会延长单机软件的生命周期，同时适应后期的不断的衍生的需求变化，.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。
