6.2.3 实践中的系统架构设计（1）

http://book.51cto.com  2010-04-21 10:59  何小朝  电子工业出版社   我要评论(0)
6.2.3  实践中的系统架构设计
在实践中，为客户或某个应用进行系统架构设计或提供建议，往往是对常见几种架构的选择或根据用户需求对它们进行组合。但在具体的设计中，上述每一种常见架构都会衍生出许多不同的实例。
对用户的需求设计或选择不同的架构，往往不是出于满足功能的需求，而是为了满足或达到最佳性能考虑。下面本书将会介绍几个从实践中抽象出来的较常用的架构组成部分的选择依据。它们都不是完整的架构，但却在架构设计中经常遇到。
1. 两层、三层还是四层
● 普通常识
如果采用专用“胖客户端”设计，用VB、VC、PowerBuilder、Java Application等手段制作前台界面，并与数据库直接交流，则毫无疑问，我们的软件是最简单的两层C/S架构。
现在您要为某企业设计一个可处理网上业务的门户网站，无论你采用J2EE、.Net或PHP等工具或技术，一般的常识是：
1. 如果涉及复杂的业务逻辑，则一般在Web SERVER与数据库服务器之间，会设计专门的应用服务器层（若采用J2EE技术，则可以考虑采用EJB及其容器来实现该层）。则除去浏览器以外，我们的设计架构将会有Web服务器、应用服务器及数据库服务器三级服务，为四层架构；
2. 如果不涉及复杂的业务逻辑，绝大多数Web请求都是数据库操作，则一般由Web SERVER上部署的程序直接访问数据库，即我们的设计架构将会有Web服务器及数据库服务器两级服务，为三层架构；
这里首先要纠正一个观点。例如对J2EE的开发者而言，对上述第2种情况，他们可能采用了JSP+Servlet+JavaBean+DB的程序结构，则他们认为自己的架构是四层，这个观点是不正确的。如果没有使用专业中间件（如WebLogic）的EJB容器，JSP、Servlet及JavaBean都是在Web Server服务器上运行的，所以其实只有Web服务器层及数据库服务器两级服务，应该还是三层架构。包括现在较流行的Struts、Spring、Hibernate、JSF等J2EE的框架技术，无论您的程序结构最终是JSP+BB(Bean)+Spring代理+Hibernate DAO+DB还是JSP+Servlet+DB，其实质都是三层架构，其间的区别只在于程序结构的优化上，而不存在实质性的架构优势的区别。
以上是大多数软件工作者在日常设计中的基本原则，这自然是正确的。而本书在这里则要对上述第二种情况做进一步探讨，以为广大软件设计者参考。
● 深一步探讨
在上述第2种情况中，我们要设计的系统没有复杂业务逻辑，只有大量的数据库请求操作。对这种应用需求，目前在国内，绝大多数的开发者都自然遵循了上述原则，采用三层C/S架构（即B/S）来实现，加之现今J2EE的流行与各种程序框架（Structs、JSF等）对这种开发模式的强大支持（一般直接采用J2EE框架提供的固定模板模式就可以很方便地搭建这样的系统），使该软件模式几乎占了这一类系统开发的80%以上的比例。
但对一个资深的设计者来讲，只了解这些是不够的。对一个中小企业的门户网站或仅供企业内部使用的一些基于Web的应用系统开发，一般可以如上述那样在开发工具与框架模式的支持下直接构建，但对于具有以下性质的门户网站开发，则不能这么简单的处理：
■ 对数据安全性要求高；
■ 各种应用系统之间数据交流频繁；
■ 直接针对互联网客户；
■ 访问量巨大，并发要求高。
与具有复杂的业务逻辑就要考虑引入基于EJB的应用服务层一样，设计者此时同样要考虑在Web服务器与数据库服务器之间加入一层的必要性，我们可以将其称为代理层服务，即设计为四层架构，如图6-9所示：
 
之所以叫代理层，是因为该层不处理任何业务逻辑（与上面第1种情况中的应用服务器层完全不同），只是代理执行Web服务器上的请求并向其返回结果。
代理层存在的原因有几下几点：
■ 一般重要企业的核心数据不可以能被处于网络上非军事区的、面向公众的Web服务器直接访问；
■ 多一层的设计无疑增加的系统的可缩放性，大大提高系统并发性能；
■ 将以前两层设计中对请求的完全同步处理改变为伪异步处理，大大提高处理大量并发请求的能力；
■ 可以方便地与其他应用系统进行数据或业务交流，如图6-9所示。
代理层一定是一个多线程/多进程的服务，它可以以下几种方式实现：
■ 在J2EE技术体系内，代理层可以是JMS消息容器（如IBM MQ、Java MQ、WebLogic、JBOSS等），而Web服务器与代理层则可以通过JMS消息机制交流；
■ 自开发多线程/多进程的消息服务器。采用这种方式具有较大的灵活性，Web展示层不必受到开发语言的限制(例如，如果采用JMS机制，则Java/JSP的选择不可避免)，可选择JSP、PHP、PERL、ASP、C/C++等任何一种语言来构建Web层。笔者自开发的产品“消息服务器AMS”便是该项应用的典型，详细内容可参见 www.alder.com.cn产品部分。
2. 四层以上的多层体系
除了最普通的两层/三层及较复杂的四层结构外，实践中，多层结构的单点应用系统一般到四级服务（五层）还是可以见到的，但再多的分层已经很少见，并且意义已经不是很大。所以本小节专门介绍一下四级服务（五层）的体系结构。
按上面所述的分层标准，四级服务（五层）体系中应该共包括四组两层客户机/服务器模式，如图6-10所示：
 
将一个系统设计为四级服务（五层）体系，一般不会再是单纯为了提高可缩放性、性能或系统安全性，主要可能是基于以下几种考虑：
■ 中间层一与中间层二一般要分别处理两种不同的业务逻辑，并且大多情况下无法合成为一个服务；
■ 中间层一与中间层二的业务必须分布在两个不同的物理区域来处理；
■ 中间层一为中间层二的预处理，即请求必须经过中间层一的处理后，然后交给中间层二进行实际的业务逻辑处理。
从图6-10可以看出，中间层一也有可能与数据库服务器交流（如图6-10中虚线所示），这完全根据其所需要处理的业务逻辑的需要而定，所以，四级服务（五层）体系中，数据库层不一定非要严格设定为只能被中间层二访问，限制客户端对其的访问已经完全可以满足多层体系对企业数据安全的要求了。
以一个电信行业的门户网站为例，其体系结构一般可设计为四级服务（五层），如图6-11所示：
 
在该例中，数据处理服务器具有以下责任：
■ 接受所有Web服务器发来的请求；
■ 处理用户登录，用户数据查询，用户数据修改等功能；
■ 转发所有有关电信业务处理的请求给电信业务服务器。
电信业务服务器具有以下责任：
■ 完成业务相关一级的用户认证；
■ 处理电信业务相关的请求。这种请求的处理一般都是通过与其他业务系统交流来实现的，例如用户的请求如果与计费系统相关的话，则需要将请求再转发到计费系统去处理（电信行业的计费系统往往是另外一个独立的业务系统）。
以上电信行业四级服务（五层）体系中，除与数据库服务器的交流以外，各个客户机/服务器组之间一般采用消息机制来实现通信，如JMS或行业自定义的消息协议，实践中很多企业都采用基于XML的消息体定义。
3. 服务器集群
在多层C/S架构中，每一层可能会有多个服务器协同工作的需求。这些需求一般可以总结为以下几个方面：
■ 上一层的请求太多，一个服务器无法满足需求；
■ 即使一台服务器崩溃掉以后，可以由其他服务器继续负责应用程序的运行；
■ 要求不同的服务器负责处理不同性质的请求。
因此需要根据某种机制将请求分配到多个服务器上去分布执行，即负载均衡或任务分发。
以上述基于Web的三层结构为例，首先在Web层，绝大多数的Web服务器都具有群集（Cluster）的功能，如Apache群集。这样，就可以将大量的HTTP请求均衡地分配到一个群集服务器上去执行。
多服务器协作（群集）有很多模式，总的来讲，一般可分为以下几类：
■ 对等模式；
■ 主从模式（Master/Slave）；
■ N+1。
以下我们分别介绍这两种模式。
● 对等模式
对等模式的服务器集群中，每一台服务器的地位与作用都是完全相同的，它们之间没有主次关系，也没有职能不同的情况，如图6-12所示：
 
在对等模式中，对具体将任务分配到哪台服务器上执行的选择一般由其上一层的服务根据某种算法与规则来决定，比较常用的规则有以下四种。
（1）Round-Robin：这即是指上一层服务器将任务按照服务器1，服务器2，……，服务器n，然后再回到服务器1的首尾相接的环的顺序依次分配。该算法中，每次上一层服务器只需要记得最后一次被分配任务的集群服务器的顺序号即可。
（2）随机算法：采用随机数算法（如Rand函数），从N个服务器中每次任选一个服务器。
（3）优先级：对集群服务器动态设定优先级：即最开始时，大家的优先级都是一样的，当给某一台服务器分配一个任务后，其优先级就减少一级。以后再分配任务时，就在优先级最高的一组集群服务器中按照其他规则选择一个。
（4）综合算法：即对以上算法的综合。很明显，优先级算法需要和其他算法结合才可使用。
对等模式主要用于负载均衡的需求，其大多用于自开发应用中，最大的优势是上一层服务器可自行选择需要的服务器。
● 主从模式（Master/Slave）
在主从模式的服务器集群模式中，有一台服务器为主服务器，其他的服务器则为从服务器，其地位与作用可能都有不同，如图6-13所示：
 
【责任编辑： 董书 TEL：（010）68476606】

系统 设计 架构

0

收藏

上一篇：SQL SERVER2005 数... 下一篇：10.2 云计算提升终端智能
noavatar_middle.gif
51bom

492篇文章，19W+人气，0粉丝