1.1消息中间件
    中间件(middleware)是基础软件的一大类，属于可复用的软件范畴。中间件在操作系统软件，网络和数据库之上，应用软件之下，总的作用是为处于自己上层的应用软件提供运行于开发的环境，帮助用户灵活、高效的开发和集成复杂的应用软件。中间件是位于平台(硬件和操作系统)和应用之间的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。也许很难给中间件一个严格的定义，但中间件应具有如下的一些特点：
 满足大量应用的需要Ø
 运行于多种硬件和OSØ平台
 支持分布计算，提供跨网络、硬件和OS 平台的透明性的应用或服务的交互支持标准的协议Ø
 支持标准的接口Ø
IDC 对中间件的定义为：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件定位于客户机服务器的操作系统之上，管理计算机资源和网络通信。因而中间件是指一类软件，是基于分布式处理的软件，最突出的特点是其网络通信功能。也可认为中间件是位于平台和应用之间的通用服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，可以有符合接口和协议的多种实现。
面向消息的中间件：
MOM 指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM 中间件产品有IBM 的MQSeries、BEA 的MessageQ 等。

主要特点：
    通讯程序可在不同的时间运行程序不在网络上直接相互通话，而是间接地将消息放入消息队列，因为程序间没有直接的联系。所以它们不必同时运行。消息放入适当的队列时，目标程序甚至根本不需要正在运行；即使目标程序在运行，也不意味着要立即处理该消息。对应用程序的结构没有约束在复杂的应用场合中，通讯程序之间不仅可以是一对一的关系，还可以进行一对多和多对一方式，甚至是上述多种方式的组合。多种通讯方式的构造并没有增加应用程序的复杂性。程序将消息放入消息队列或从消息队列中取出消息来进行通讯，与此关联的全部活动，比如维护消息队列、维护程序和队列之间的关系、处理网络的重新启动和在网络中移动消息等是MOM 的任务，程序不直接与其它程序通话，并且它们不涉及网络通讯的复杂性

1.2 消息中间件的传递模型
消息中间件一般有两种传递模型：点对点模型（PTP）和发布-订阅模型（Pub/Sub）。

1.2.1 点对点模型（PTP）
    点对点模型用于消息生产者和消息消费者之间点到点的通信。消息生产者将消息发动到由某个名字标识的特定消费者。这个名字实际上对应于消息服务中的一个队列（Queue），在消息传动给消费者之前它被存储在这个队列中。队列可以是持久的，以保证在消息服务出现故障时仍然能够传递消息。

1.2.2 发布-订阅模型（Pub/Sub）
    发布-订阅模型用称为主题（topic）的内容分层结构代替了PTP 模型中的惟一目的地，发送应用程序发布自己的消息，指出消息描述的是有关分层结构中的一个主题的信息。希望接收这些消息的应用程序订阅了这个主题。订阅包含子主题的分层结构中的主题的订阅者可以接收该主题和其子主题发表的所有消息。

1.3 海量用户支撑
系统软集群
    为了使得多台系统能表现的如同一台服务器系统一样，那么就必须具备一个基本条件，就是这么多台服务器系统，每台单独运行，都能提供完全一致的服务，否则，不同的服务器提供不一致的服务，又如何对外表现出完全一致的表现呢？这里，最简单的例子是Web服务器，我们可以设置Web服务器，使多个Web服务器中保存的网页文件内容完全一致，这样，无论访问哪个服务器，只要使用同样的URL就能得到同样的结果。
    因此，在这个阶段要保证内容的一致性，就需要使用诸如服务器之间的同步镜像、网络存储系统NAS或SAN，数据库的同步复制等等技术。

1.3.1 实现：任务调度
    当所有的服务器都具备一致性的表现，接下来的任务就是将任务按照一定的方式分配给这
些服务器，这就是任务调度。
    实现任务调度首先需要要将任务尽可能的按照小粒度分割，每个粒度应该是能够在不同服务器部分上单独执行的最小单位。粒度划分的越小，任务分割得越平均，因而整体效果就越好。但粒度的划分是有一定条件的，粒度越小，粒度之间的关联就越紧密，例如在SMP多处理器的计算机系统中，任意一个线程都可以在任一个处理器上执行，因此执行粒度可以划分为线程，但是线程之间是共享内存的，这已经在理论上提出，并在并行计算机上实现，但在不同服务器之间目前还是不现实的。
    由于大多数网络服务都是基于TCP网络连接的，因此最简单的考虑，可以按照TCP连接划分任务粒度，这适合包括Web服务，数据库连接等绝大多数情况。实现任务调度的方式有很多种，一种方法是在系统内部完成，所有的服务器能够自我协调，完成任务调度，这种方法要涉及所有的服务器，依赖于具体的应用系统，因而更为复杂。另一种方法是不在服务器之间实现调度，而依赖于外部的任务调度设备执行调度。
    无论那种任务调度方式，最大的问题就是害怕任务调度本身带来的额外消耗或性能瓶颈，因此使用硬件设备和单一的高效率系统，作为外部任务调度设备，成为了集群的首选方案。

1.3.2 外部任务调度：负载平衡和虚拟服务器
     使用外部任务调度设备对任务按照网络连接进行分配，这种情况通常被称为网络服务器的负载平衡。外部的任务调度设备有很多种，例如基于BSD/OS的F5，CISCO的LocalDirector，以及一些七层交换机，例如Foundry的交换机等等。目前，除了一些基于硬件交换机设备之外，完全软件的实现中最为流行的就是LVS，Linux Virtual Server，作为一个开放源代码的项目，他得到了Linux社区的大力支持，并用于大部分Linux集群设备中。LVS是由国防科技大学的章文松提出的一个开放源代码项目，事实上这也是国内Linux开发工作中最被国际认可的一个工作，这也标志着国内在这个方向上的研究并不次于国际同行。
    LVS中最为优秀的特点是实现了策略路由的观念，它允许一个TCP连接由任务分配设备分配给后端服务器中之后，后端服务器使用不同的路由，不再经过任务分配器，而是直接返回给客户，这种方式需要后端服务器也是Linux设备，因此不是简单的任务调度。

1.3.3 服务器负担：容错与监
     任务调度的关键是将所有的任务平均的分配给所有的服务器，如果不能做到合理的分配，就能出现部分服务器上的拥塞现象，此时还可能有后台服务器类型差异造成的处理能力的不一致等情况。
    为了达到这个任务分配的目的，必须使用一种方法来获得服务器状态，这里就有不同的几种方法。最简单的方法是按照当前服务器的任务数量来衡量服务器负荷，通常就是按照网络连接的数量来衡量，这种方法应该是比较模糊的，因此不同的连接对服务器造成的压力是不同的，例如一个静态网页的处理和一个后台CGI程序的处理，服务器负担就绝对不同。
     一些负载均衡设备通过测量设备对网络连接响应时间来判断服务器的负荷，这基本上能够反映一些情况，但也并非绝对如此，因为优秀的服务器对于基本的网络响应是迅速的，但对于后面的处理过程则受系统负荷的影响。因此，一些系统甚至引入了客户／服务器机制，在后台服务器中安装代理来完成探测系统性能的任务。
    当任务调度设备能够精确的了解服务器负荷的时候，它显然就能够达到了解后台服务器的可用性，就是说任务调度设备能够检测出某些后台服务器不能正确运行，从而避开这个服务器，将任务分配给其他设备，达到容错的目的。

1.3.4 共享数据：会话管理
     还是以Web访问为例，对于普通的网页，不同的HTTP连接就可以认为是不同的任务。但是，对于更复杂的应用，例如需要用户登录，并根据不同用户提供不同服务的情况呢？此时，如果仍然还是要把不同的HTTP连接看作不同的任务，那么这些连接之间实际上还是有一定关系的，事实上每个用户从登录到退出，可以被看作一个完整的HTTP会话。
    由于这些会话必须保存的数据比较少，例如仅仅是用户名和简单的一些秘密设置，任务调度的时候可以不考虑这些会话，那么就可能发生这样的情况，同一个会话的不同HTTP连接可能在不同的后台服务器上进行处理，因此这就需要进行这些服务器之间的数据共享。数据共享可以通过多种方式，通过共享的存储空间，通过独立的服务程序，通过数据库，甚至通过共享网络间内存等等。
    虽然任务调度程序可以不理会这种会话，不同服务器之间可以共享，但如果能够支持会话功能，使得同一个会话可以被同一个服务器所处理，这样会带来效率上的提高。因此，一些任务调度设备提出了“粘滞”的概念，能够根据Cookie或其他标记判断会话，并导向同一个服务器。

1.3.5 相关技术
     虽然目前用于解决网络服务的集群技术，在技术层次上比较简单，事实上只是应用了此前并行计算技术研究的一些简单方面，但在实用化方面的作用还是很明显的。但在理论上，目前所使用网络服务器集群技术还是有很大的挖掘之处，例如，目前的任务调度的粒度是基于TCP连接的，如何更细化。目前，在并行计算领域，人们使用PVM和MPI，允许运行在不同计算机上的多个进程进行协同，在进程之内可以进行任务调度，粒度被切割到更细致的计算单元，如果能将这些概念应用于集群系统，必然能更好的解决对大负载任务的处理任务，缩减处理时间。
    此外，目前一旦任务调度设备将任务分配给一个服务器，那么这个任务就一定在这个服务器上运行，直到完成。有时，人们需要将一个任务从一个服务器透明的迁移到另一个服务器正常执行，目前，在Linux上的Mosix能达到这个目标。事实上，PVM、MPI、Mosix等等技术，都是构建用于计算目的的Linux集群计算机的有效工具。用于处理计算的Linux集群计算机是由多台Linux节点构成的超级计算机，主要用来处理计算任务，他们处理的任务通常要比用于网络服务的集群计算机更为复杂，使得节点之间的I/O非常频繁，造成了相当多的额外负荷（例如一个进程从一个节点迁移到另一个节点上的网络负荷）。

1.4 网络适应性
    计算机连接的方式叫做“网络拓扑结构”（Topology）。网络拓扑是指用传输媒体互连各种设备的物理布局，特别是计算机分布的位置以及电缆如何通过它们。设计一个网络的时候，应根据自己的实际情况选择正确的拓扑方式。每种拓扑都有它自己的优点和缺点。

网络拓扑的分类如下：
1.4.1 星型结构
星型结构是指各工作站以星型方式连接成网。网络有中央节点，其他节点（工作站、服务器）都与中央节点直接相连，这种结构以中央节点为中心，因此又称为集中式网络。它具有如下特点：结构简单，便于管理；控制简单，便于建网；网络延迟时间较小，传输误差较低。但缺点也是明显的：成本高、可靠性较低、资源共享能力也较差。

1.4.2 环型结构
环型结构由网络中若干节点通过点到点的链路首尾相连形成一个闭合的环，这种结构使公共传输电缆组成环型连接，数据在环路中沿着一个方向在各个节点间传输，信息从一个节点传到另一个节点。
环型结构具有如下特点：信息流在网中是沿着固定方向流动的，两个节点仅有一条道路，故简化了路径选择的控制；环路上各节点都是自举控制，故控制软件简单；由于信息源在环路中是串行地穿过各个节点，当环中节点过多时，势必影响信息传输速率，使网络的响应时间延长；环路是封闭的，不便于扩充；可靠性低，一个节点故障，将会造成全网瘫痪；维护难，对分支节点故障定位较难。

1.4.3 总线型结构
总线结构是指各工作站和服务器均挂在一条总线上，各工作站地位平等，无中心节点控制，公用总线上的信息多以基带形式串行传递，其传递方向总是从发送信息的节点开始向两端扩散，如同广播电台发射的信息一样，因此又称广播式计算机网络。各节点在接受信息时都进行地址检查，看是否与自己的工作站地址相符，相符则接收网上的信息。
总线型结构的网络特点如下：结构简单，可扩充性好。当需要增加节点时，只需要在总线上增加一个分支接口便可与分支节点相连，当总线负载不允许时还可以扩充总线；使用的电缆少，且安装容易；使用的设备相对简单，可靠性高；维护难，分支节点故障查找难。

1.4.4 分布式结构
分布式结构的网络是将分布在不同地点的计算机通过线路互连起来的一种网络形式，分布式结构的网络具有如下特点：由于采用分散控制，即使整个网络中的某个局部出现故障，也不会影响全网的操作，因而具有很高的可靠性；网中的路径选择最短路径算法，故网上延迟时间少，传输速率高，但控制复杂；各个节点间均可以直接建立数据链路，信息流程最短；便于全网范围内的资源共享。缺点为连接线路用电缆长，造价高；网络管理软件复杂；报文分组交换、路径选择、流向控制复杂；在一般局域网中不采用这种结构。

1.4.5 树型结构
树型结构是分级的集中控制式网络，与星型相比，它的通信线路总长度短，成本较低，节点易于扩充，寻找路径比较方便，但除了叶节点及其相连的线路外，任一节点或其相连的线路故障都会使系统受到影响。

1.4.6网状拓扑结构
在网状拓扑结构中，网络的每台设备之间均有点到点的链路连接，这种连接不经济，只有每个站点都要频繁发送信息时才使用这种方法。它的安装也复杂，但系统可靠性高，容错能力强。有时也称为分布式结构。

1.4.7 蜂窝拓扑结构
蜂窝拓扑结构是无线局域网中常用的结构。它以无线传输介质（微波、卫星、红外等）点到点和多点传输为特征，是一种无线网，适用于城市网、校园网、企业网。
在计算机网络中还有其他类型的拓扑结构，如总线型与星型混合。总线型与环型混合连接的网络。在局域网中，使用最多的是总线型和星型结构。