6.2.3 实践中的系统架构设计

主服务器的主要任务是按照某种规则分配任务给其他从服务器，这些规则可能是有两个目标：

（1）为了实现负载均衡；

（2）为了实现将不同类型的任务分给不同的服务器去执行。

值得说明的是，在很多情况下，集群主服务器本身也可以是一个从服务器。

对目标2，我们可以以6.2.3节2.中那个“三层C/S架构”的门户网站为例来说明。假如在代理层，有两个服务器，服务器1主要完成与企业数据库交互的任务，服务器2主要通过SOAP协议与另一个应用服务器交互；则这两个服务器组成的集群如图6-14所示，其中，服务器1同时承担了主服务器与从服务器的功能。

主从模式的集群在商业化产品中应用较广，如Apache集群就是采用这种方式来实现负载均衡的。

● N+1

N+1是一种介于对等模式与主从模式之间的一种集群模式。由于在各种文献中介绍很少，所以大多技术人员对这种模式不太熟悉。但该模式在实践中也有很重要的用途，有必要被软件设计人员所了解。

N+1模式主要用于众多的集群服务器在执行任务时分别都需要与数据库服务器或磁盘存储（I/O）交互的情况，在这种情况下，可以设计只有一台服务器与数据库服务器与磁盘I/O交互（即N+1中的1），而其他服务器则完成一些内存操作为主的业务逻辑处理，如图6-15所示：

在N+1模式中，由于较耗时的数据库操作与I/O操作集中在一台服务器上异步执行，从而，其他服务器的响应速度大大提高。

之所以说N+1是对等与主从模式的结合是因为：在N+1模式中，对集群服务器的选择仍然是由上一层服务器根据某种规则决定的；同时，各种服务器的地位与任务基本相同。

是否采用N+1，主要看您所涉及的应用系统，其中该层的集群服务器的任务处理是否是以I/O与数据库操作为主。

以上几种集群模式，各有其优缺点，读者在实际的设计中，应该根据具体情况，选择合适的架构。

4. 同构系统聚合

在6.2.2节中所述SOA架构中，实践中经常会有一种设计，它是通过把多个相同或相容的服务结点连接起来以建立大的企业软件系统，成为同构系统聚合的体系。聚合体系内的各服务结点通过共同的通信协议共享信息或视图。在聚合体系中，数据或消息从任何一个服务结点出发，总能找到一个途径到达另一个服务结点。

很显然，聚合是一种特殊的多服务系统架构，建立在这种架构基础上的企业软件系统通常只需要一个统一的公共接口（interface），所以设计功能时，只需要考虑两个服务结点之间的交流即可。

一个新的服务结点如果要加入系统，只需要与系统中任何一个已经连接结点连接上即可。不难看出，这种架构中，如果一个服务结点断开，可能会导致其他服务结点同时断开，如图6-16中服务结点9断开，会使结点10，结点11，结点12失去联络，因此，一般采用这种架构的多服务软件系统，都应该设计把断线结点重新连接到系统的功能。

一些聊天室或网络上的公共会议系统，就是采用这种架构来实现的。

现在假设有多个聚合，我们在每一个聚合中选择一个主结点服务，然后把每个聚合当成一个结点，通过主服务结点将各个聚合连接起来，就形成了一个更加庞大的系统，我们称这种扩展后的聚合为联邦体系结构。联邦体系结构中的每一个聚合也可能是一个单服务结点，但重要的是它们都是同构系统。因特网的网络体系本身就是一个典型的联邦体系结构的例子。

5. 调度系统

任务调度系统是生产实践中较为特殊的一种软件系统结构。中心调度服务根据预先设定或动态产生的任务队列与优先级，根据某种调度策略，分配或执行各项任务。

最为典型的调度系统例子应该是操作系统设计中的进程调度，如我们熟悉的分时调度策略、实时调度策略等。但由于本书讨论的重点是应用软件系统设计、开发与管理，因此本节介绍的调度系统，主要是指广泛应用于运行大型信息系统机构（如银行、电信、保险公司、信息服务提供商等）的这样一种软件系统：它将信息系统每日正常运行所需要的任务，通过一般以称为作业的运载单位来包装（通常是一个进程），再通过统一的排程系统，按照一定的先后顺序，对作业进行任务调度。

在应用架构上，任务调度系统一般分为三层，分别是调度管理器、调度应用服务器、调度执行代理。通过三层架构，实现了作业任务管理、作业任务调度、作业任务执行三部分功能的分离。调度的基本功能包括任务调度所应该有的，例如管理作业间的依赖关系、配置时间点运行任务调度、作业失败自动重试、作业调度过程中的监控，以及干预等功能。高级一点的功能也可以包含作业执行节点负载均衡，并发控制等。

严格来讲，上述任务调度系统应属于多服务系统，如调度管理器可能是一个提供了Java Web界面的三层C/S结构单服务系统，调度应用服务器与调度执行代理可以分别是一个采用集群结构的单服务系统，各单服务系统之间通过建立在TCP/IP协议之上的应用层协议进行通信。

任务调度系统的特点是，除了组成其系统架构本身的各个服务器本身的工作进程、逻辑与算法以外，它还在不断地调起其他的作业进程，也就是说，调度系统本身并不直接帮助用户完成某项功能，只是有效地协调控制其他的用户自定义作业，以一定依赖关系、在指定的时间内完成超大数量的业务功能。这是笔者单独介绍调度系统架构的原因。

6. 异构系统集成

企业有很多异构系统，可能是应用程序、通信协议、操作系统、数据库、体系结构等均不相同，每个异构系统本身可能是一个多层单服务体系，现在，把各异构系统如6.2.3.5节同构系统聚合那样通过统一的通信协议连接起来，就形成了SOA架构中的另一个实例，称之为异构系统集成。

异构系统集成时，各个异构系统之间的连接可以通过两种典型方式来实现：

■ 第一种方式就是如同构系统聚合那样，采用两两连接的方式。则一个系统总是可以找到一条通路到达另一个系统，但正如同构聚合的缺点一样，一个系统的失败可能导致对其他系统的连接受阻；并且，每个应用系统除了设计请求处理与回传的功能以外，还需要设计请求转发的接口，以保证所以系统的连通。假设各系统之间的连接采用基于消息的协议，则对应了消息处理及消息转发的功能；

■ 第二种方式即是结合采用6.2.2节中介绍“企业数据交换总线”的架构模式，即所有的异构系统都先连接到“企业数据交换总线”上，由它统一负责系统之间的通信与交流。需要指出的是，各异构系统与交换总线的连接，即可以是全自动操作，也可以是有人工参与的半自动方式，这一点与同构聚合是不同的。

7. 数据存放与访问

在信息系统中，还有一种需求便是对数据的存储与访问，这包括将企业数据保存在数据库中或磁盘文件中。如果数据量小，则没有什么问题，但对于海量数据的存放与访问，则在软件架构设计中需要专门考虑。当然，对该问题，在存储领域内，也有相应的解决方案，如RAID，但那些方法与软件层面的解决方案目的与作用均不相同。本书只介绍软件层面的策略与结构设计。

其实，对数据的存放，无非是两种策略：集中存放或分散存放；对数据的访问，也无非是串行访问或并行访问两种策略。由于数据的存放方式决定了哪种访问方式更有效，因此，本书下面仅以数据存放方式为依据来分类说明这方面的问题。

● 数据集中存放

这种模式很容易理解，即将数据都集中存放一个存储服务器上。该种模式除了适用于小数据量以外，其实，对大数据量（可能达不到海量，但其容量也是很可观的）的存放，也是一个重要的模式。这主要依赖于我们对数据的使用方式。如果在应用中，数据在存储时总是局部小批量地增加，在访问时，总是局部小批量地获取与修改，则该种模式是比较合适的。典型的例子便是各个行业的生产系统。如银行与电信的核心业务系统。

● 分散存放——数据共享

该模式中，数据被分布存储到不同的存储服务器上去，但这些存储服务器对应用服务器来言却是共享的，如图6-17所示：

● 分散存放——数据非共享

对客户数据，按照某种规则分布存储到不同的存储服务器上去，但这些存储对应用服务器不是共享的。在数据访问时，则由不同的应用服务器分别在不同的存储服务器上并行进行访问，最后将结果合并返回。当然，这种模式首先要求在应用服务器一层是主从模式的集群，主服务器执行数据分散的规则，触发并行查询，并合并结果，如图6-18所示：

对后两种分散存放的模式，都是为适用于大批量数据导入及大批量数据访问与获取的目标而设计的。例如，数据库厂商为满足数据仓库的需要设计其数据存储与访问的架构，一般都是采用其中一种。如众所周知的ORACLE RAC则是采用共享磁盘方式的，而TeraData及GreenPlum等则采用后一种非共享磁盘的方式。

对集中与分散两种模式的选择，似乎较容易决定，但对于海量数据存储与访问，到底采用哪一种分散方式更有效呢？本书这里不便作出判断，但需要指出的是，非共享的分散存储，更加接近于网格的思想，有助于在同样成本的情况下获取更高的性能对需要建设海量数据中心的企业，两种分散模式都是值得考虑的架构。