构架一个网站平台服务器大概要什么配置和多少钱？

1

Amazon:Linux,Oracle,C++,Perl,Mason,Java,Jboss,Servlets2

Digg:MySQL-数据库Linux-操作系统平台PHP-服务器端开发Lucune-后台搜索引擎APC加速器-PHP脚本缓冲MCache-后台共享缓冲服务3

eBay:Java,Oracle,WebSphere,HorizontalScaling,Sharding,MixofWindowsandUnix4

Flickr:PHP-脚本语言MySQL-数据库Shards框架-关系数据库水平分割解决方案框架Memcached-用于缓存层的内存对象缓存反向代理中的Squid代理服务器-用于超文本标记语言html和图像Linux(RadHat)-操作系统Smarry模板Perl-脚本语言PEAR开源类库，它提供在线网站技术分析（只能对网页进行分析，网站内部架构是其所不能窥探

模块化结构的思想是一个很久的概念，但也正是成熟的思想造就了Nginx的巨大优越性。

我们知道Nginx从总体上来讲是有许多个模块构成的。习惯将Nginx分为5大模块分别为：核心模块，标准HTTP模块，可选HTTP模块，邮件服务模块和第三方模块。

这5个模块由上到下重要性一次递减。

（1）核心模块；

核心模块是Nginx服务器正常运行必不可少的模块，如同操作系统的内核。它提供了Nginx最基本的核心服务。像进程管理、权限控制、错误日志记录等；

（2）标准HTTP模块；

标准HTTP模块支持标准的HTTP的功能；

（3）可选HTTP模块；

可选HTTP模块主要用于扩展标准的HTTP功能，让Nginx能处理一些特殊的服务；

（4）邮件服务模块；

邮件服务模块主要用于支持Nginx的邮件服务；

（5）第三方模块；

第三方模块是为了扩展Nginx服务器应用，完成开发者想要的功能；

Nginx中的模块命名有自己的习惯

一般以Ngx_作为前缀，——module作为后缀，中间使用一个或者多个英文单词描述模块的工能，例如Ngx_core_module表示该模块提供Nginx的核心功能等；

具体各个模块中包含哪些模块可以自己去源码中查询，这里略过；

从架构设计上说，Nginx服务器是与众不同的。其一在于它的模块化设计；其二也是更重要的一点在于它对与客户端请求的处理机制上；

web服务器和客户端是一对多的关系，Web服务器必须有能力同时为多个客户端提供服务。一般来说完成并行处理请求工作有三种方式：

1多进程方式；

2多线程方式；

3异步方式；

这里简单说明一下这三种方式：

（1）多进程方式

多进程方式指，服务器每当收到一个客户端时。就有服务器主进程生成一个子进程出来和客户端建立连接进行交互。指导连接断开。该子进程就结束了。

多进程方式的优点是设计简单，各个子进程相对独立，处理客户端请求时彼此不受干扰；缺点是操作系统生成一个子进程需要进行内存复制等操作，在资源和时间上会产生一定的开销；当有大量请求时，会导致系统性能下降；

（2）多线程方式

多线程方式指每当服务器接收到一个请求后，会由服务器主进程派生出一个线程出来和客户端进行交互。由于操作系统产生出一个线程的开销远远小于一个进程的开销。故多线程方式在很大程度上减轻了Web服务器对系统资源的要求。但同时由于多个线程位于一个进程内，可以访问同样的内存空间。所以需要开发者自己对内存进程管理，增大了难度。

（3）异步方式

异步方式适合多进程和多线程完全不同的一种处理客户端请求的方式。这里有几个概念我们需要熟悉一下： 同步，异步，阻塞，非阻塞 ；

在网络通信中同步和异步是描述通信模式的概念。

同步：发送方发送完请求后，需要等待接收到接收方发回的响应，才能发送下一个请求；所有请求在服务端得到同步，发送方和接收方的步调是一致的；

异步 ：和同步机制相反，在异步机制中，发送方发出一个请求后，不等接收方响应这个请求，就继续发送下一个请求；所有来自发送方的请求形成一个队列，接收方处理完成后通知发送方；

在进程处理调度方式上用阻塞与非阻塞。在网络通信中主要指套接字socket的阻塞和非阻塞，而socket的实质就是IO操作。

阻塞 ：调用结果返回之前，当前线程从运行状态被挂起，一直等到调用结果返回之后，才进入就绪状态，获取CPU后继续执行。

非阻塞 ：和阻塞方式正好相反，如果调用结果不能马上返回，当前线程也不会马上返回，而是立即返回执行下一个调用。

因此就衍生出4中方式：同步阻塞，同步非阻塞，异步阻塞，异步非阻塞

这里简单解释一下异步非阻塞：发送方向接收方发送请求后，不用等待响应，可以继续其他工作；接收方处理请求时进行的IO操作如果不能马上得到结果，也不必等待，而是马上返回去去做其他事情。当IO操作完成以后，将完成状态和结果通知接收方，接收方再响应发送方。

与此同时Nginx服务器处理请求是怎样的呢？？？

Nginx服务器的一个显著的优势就是能够同时处理大量的并发请求。它结合多进程机制和异步机制。异步机制使用的是异步非阻塞方式。（Master-Worker)。

每个工作进程使用异步非阻塞方式，可以处理多个客户端请求。当某个工作进程接收到客户端的请求以后，调用IO进行处理，如果不能立即得到结果，就去处理其他的请求；而客户端在此期间也无需等待响应，可以去处理其他事情；当IO返回时，就会通知此工作进程；该进程得到通知，暂时挂起当前处理的失误去响应客户端请求。

也就是：

Nginx采用异步非阻塞方式来处理请求，处理请求具体到系统底层就是读写事件（所谓阻塞调用方式即请求事件还没准备好，线程只能一直去等，等事件准备好了再处理；而非阻塞即事件没准备好，马上返回ENGAIN,告诉你事件还没准准备好，而在这期间可以先去做其他事，再回头看看事件准备好了吗，时不时会看，需要的开销也是不小的）

异步可以理解为循环处理多个准备好的事件，不会导致无谓的资源浪费，当有更多的并发数只会占用更多的内存而已;

从上面我们可以知道，Nginx服务器的工作进程调用IO后，就取进行其他工作了；当IO调用返回后，会通知工作进程。 但IO调用时如何把自己的状态通知给工作进程的呢？？

一般解决这个问题有两种方法：

（1）让工作进程在进行其他工作的过程中间隔一段时间就去检查一下IO的状态，如果完成就响应客户端，如果未完成，继续工作。

（2）IO调用在完成后能主动通知工作进程。

当然最好的就是用第二种方法了；像select/poll/epoll等这样的系统调用就是用来支持第二种解决方案的。这些系统调用也常被称为事件驱动模型。他们提供了一种机制就只让进程同时处理多个并发请求，不用关心IO调用的具体状态。IO调用完全由事件驱动模型来管理。

Nginx中的事件驱动模型

就是用事件驱动处理库（多路IO复用），最常用的就是select模型，poll模型，epoll模型。

关于这三个模型的详解在这里可以看到：https://segmentfaultcom/a/1190000003063859

通过这个上面的简单讲解，再加上服务器的架构的了解，可以对Nginx有一个简单的了解，希望对之后的源码剖析有帮助。

大致上Nginx的架构就是这样：

1Nginx启动后，会产生一个主进程，主进程执行一系列的工作后会产生一个或者多个工作进程；

2在客户端请求动态站点的过程中，Nginx服务器还涉及和后端服务器的通信。Nginx将接收到的Web请求通过代理转发到后端服务器，由后端服务器进行数据处理和组织；

3Nginx为了提高对请求的响应效率，降低网络压力，采用了缓存机制，将 历史 应答数据缓存到本地。保障对缓存文件的快速访问；

##工作进程##

工作进程的主要工作有以下几项：

接收客户端请求；

将请求一次送入各个功能模块进行过滤处理；

IO调用，获取响应数据；

与后端服务器通信，接收后端服务器处理结果；

数据缓存

响应客户端请求；

##进程交互##

Nginx服务器在使用Master-Worker模型时，会涉及到主进程和工作进程的交互和工作进程之间的交互。这两类交互都依赖于管道机制。

1Master-Worker交互

这条管道与普通的管道不同，它是由主进程指向工作进程的单向管道，包含主进程向工作进程发出的指令，工作进程ID等；同时主进程与外界通过信号通信；

2worker-worker交互

这种交互是和Master-Worker交互是基本一致的。但是会通过主进程。工作进程之间是相互隔离的，所以当工作进程W1需要向工作进程W2发指令时，首先找到W2的进程ID，然后将正确的指令写入指向W2的通道。W2收到信号采取相应的措施。

相比于传统的网络编程方式，事件驱动能够极大的降低资源占用，增大服务接待能力，并提高网络传输效率。 关于本文提及的服务器模型，搜索网络可以查阅到很多的实现代码，所以，本文将不拘泥于源代码的陈列与分析，而侧重模型的介绍和比较。使用 libev 事件驱动库的服务器模型将给出实现代码。 本文涉及到线程 / 时间图例，只为表明线程在各个 IO 上确实存在阻塞时延，但并不保证时延比例的正确性和 IO 执行先后的正确性；另外，本文所提及到的接口也只是笔者熟悉的 Unix/Linux 接口，并未推荐 Windows 接口，读者可以自行查阅对应的 Windows 接口。阻塞型的网络编程接口几乎所有的程序员第一次接触到的网络编程都是从 listen()、send()、recv()等接口开始的。使用这些接口可以很方便的构建服务器 /客户机的模型。我们假设希望建立一个简单的服务器程序，实现向单个客户机提供类似于“一问一答”的内容服务。图1 简单的一问一答的服务器 /客户机模型我们注意到，大部分的 socket接口都是阻塞型的。所谓阻塞型接口是指系统调用（一般是 IO接口）不返回调用结果并让当前线程一直阻塞，只有当该系统调用获得结果或者超时出错时才返回。实际上，除非特别指定，几乎所有的 IO接口 (包括 socket 接口 )都是阻塞型的。这给网络编程带来了一个很大的问题，如在调用 send()的同时，线程将被阻塞，在此期间，线程将无法执行任何运算或响应任何的网络请求。这给多客户机、多业务逻辑的网络编程带来了挑战。这时，很多程序员可能会选择多线程的方式来解决这个问题。多线程服务器程序 应对多客户机的网络应用，最简单的解决方式是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。 具体使用多进程还是多线程，并没有一个特定的模式。传统意义上，进程的开销要远远大于线程，所以，如果需要同时为较多的客户机提供服务，则不推荐使用多进程；如果单个服务执行体需要消耗较多的 CPU 资源，譬如需要进行大规模或长时间的数据运算或文件访问，则进程较为安全。通常，使用 pthread_create () 创建新线程，fork() 创建新进程。 我们假设对上述的服务器 / 客户机模型，提出更高的要求，即让服务器同时为多个客户机提供一问一答的服务。于是有了如下的模型。图2 多线程服务器模型 在上述的线程 / 时间图例中，主线程持续等待客户端的连接请求，如果有连接，则创建新线程，并在新线程中提供为前例同样的问答服务。 很多初学者可能不明白为何一个 socket 可以 accept 多次。实际上，socket 的设计者可能特意为多客户机的情况留下了伏笔，让 accept() 能够返回一个新的 socket。下面是 accept 接口的原型： int accept(int s, struct sockaddr addr, socklen_t addrlen); 输入参数 s 是从 socket()，bind() 和 listen() 中沿用下来的 socket 句柄值。执行完 bind() 和 listen() 后，操作系统已经开始在指定的端口处监听所有的连接请求，如果有请求，则将该连接请求加入请求队列。调用 accept() 接口正是从 socket s 的请求队列抽取第一个连接信息，创建一个与 s 同类的新的 socket 返回句柄。新的 socket 句柄即是后续 read() 和 recv() 的输入参数。如果请求队列当前没有请求，则 accept() 将进入阻塞状态直到有请求进入队列。 上述多线程的服务器模型似乎完美的解决了为多个客户机提供问答服务的要求，但其实并不尽然。如果要同时响应成百上千路的连接请求，则无论多线程还是多进程都会严重占据系统资源，降低系统对外界响应效率，而线程与进程本身也更容易进入假死状态。 很多程序员可能会考虑使用“线程池”或“连接池”。“线程池”旨在减少创建和销毁线程的频率，其维持一定合理数量的线程，并让空闲的线程重新承担新的执行任务。“连接池”维持连接的缓存池，尽量重用已有的连接、减少创建和关闭连接的频率。这两种技术都可以很好的降低系统开销，都被广泛应用很多大型系统，如 websphere、tomcat 和各种数据库等。 但是，“线程池”和“连接池”技术也只是在一定程度上缓解了频繁调用 IO 接口带来的资源占用。而且，所谓“池”始终有其上限，当请求大大超过上限时，“池”构成的系统对外界的响应并不比没有池的时候效果好多少。所以使用“池”必须考虑其面临的响应规模，并根据响应规模调整“池”的大小。 对应上例中的所面临的可能同时出现的上千甚至上万次的客户端请求，“线程池”或“连接池”或许可以缓解部分压力，但是不能解决所有问题。 总之，多线程模型可以方便高效的解决小规模的服务请求，但面对大规模的服务请求，多线程模型并不是最佳方案。下一章我们将讨论用非阻塞接口来尝试解决这个问题。使用select()接口的基于事件驱动的服务器模型 大部分 Unix/Linux 都支持 select 函数，该函数用于探测多个文件句柄的状态变化。下面给出 select 接口的原型： FD_ZERO(int fd, fd_set fds) FD_SET(int fd, fd_set fds) FD_ISSET(int fd, fd_set fds) FD_CLR(int fd, fd_set fds) int select(int nfds, fd_set readfds, fd_set writefds, fd_set exceptfds, struct timeval timeout) 这里，fd_set 类型可以简单的理解为按 bit 位标记句柄的队列，例如要在某 fd_set 中标记一个值为 16 的句柄，则该 fd_set 的第 16 个 bit 位被标记为 1。具体的置位、验证可使用 FD_SET、FD_ISSET 等宏实现。在 select() 函数中，readfds、writefds 和 exceptfds 同时作为输入参数和输出参数。如果输入的 readfds 标记了 16 号句柄，则 select() 将检测 16 号句柄是否可读。在 select() 返回后，可以通过检查 readfds 有否标记 16 号句柄，来判断该“可读”事件是否发生。另外，用户可以设置 timeout 时间。 下面将重新模拟上例中从多个客户端接收数据的模型。图4使用select()的接收数据模型 上述模型只是描述了使用 select() 接口同时从多个客户端接收数据的过程；由于 select() 接口可以同时对多个句柄进行读状态、写状态和错误状态的探测，所以可以很容易构建为多个客户端提供独立问答服务的服务器系统。图5使用select()接口的基于事件驱动的服务器模型 这里需要指出的是，客户端的一个 connect() 操作，将在服务器端激发一个“可读事件”，所以 select() 也能探测来自客户端的 connect() 行为。 上述模型中，最关键的地方是如何动态维护 select() 的三个参数 readfds、writefds 和 exceptfds。作为输入参数，readfds 应该标记所有的需要探测的“可读事件”的句柄，其中永远包括那个探测 connect() 的那个“母”句柄；同时，writefds 和 exceptfds 应该标记所有需要探测的“可写事件”和“错误事件”的句柄 ( 使用 FD_SET() 标记 )。 作为输出参数，readfds、writefds 和 exceptfds 中的保存了 select() 捕捉到的所有事件的句柄值。程序员需要检查的所有的标记位 ( 使用 FD_ISSET() 检查 )，以确定到底哪些句柄发生了事件。 上述模型主要模拟的是“一问一答”的服务流程，所以，如果 select() 发现某句柄捕捉到了“可读事件”，服务器程序应及时做 recv() 操作，并根据接收到的数据准备好待发送数据，并将对应的句柄值加入 writefds，准备下一次的“可写事件”的 select() 探测。同样，如果 select() 发现某句柄捕捉到“可写事件”，则程序应及时做 send() 操作，并准备好下一次的“可读事件”探测准备。下图描述的是上述模型中的一个执行周期。图6 一个执行周期 这种模型的特征在于每一个执行周期都会探测一次或一组事件，一个特定的事件会触发某个特定的响应。我们可以将这种模型归类为“事件驱动模型”。 相比其他模型，使用 select() 的事件驱动模型只用单线程（进程）执行，占用资源少，不消耗太多 CPU，同时能够为多客户端提供服务。如果试图建立一个简单的事件驱动的服务器程序，这个模型有一定的参考价值。 但这个模型依旧有着很多问题。 首先，select() 接口并不是实现“事件驱动”的最好选择。因为当需要探测的句柄值较大时，select() 接口本身需要消耗大量时间去轮询各个句柄。很多操作系统提供了更为高效的接口，如 linux 提供了 epoll，BSD 提供了 kqueue，Solaris 提供了 /dev/poll …。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。 其次，该模型将事件探测和事件响应夹杂在一起，一旦事件响应的执行体庞大，则对整个模型是灾难性的。如下例，庞大的执行体 1 的将直接导致响应事件 2 的执行体迟迟得不到执行，并在很大程度上降低了事件探测的及时性。图7 庞大的执行体对使用select()的事件驱动模型的影响 幸运的是，有很多高效的事件驱动库可以屏蔽上述的困难，常见的事件驱动库有 libevent 库，还有作为 libevent 替代者的 libev 库。这些库会根据操作系统的特点选择最合适的事件探测接口，并且加入了信号 (signal) 等技术以支持异步响应，这使得这些库成为构建事件驱动模型的不二选择。下章将介绍如何使用 libev 库替换 select 或 epoll 接口，实现高效稳定的服务器模型。使用事件驱动库libev的服务器模型 Libev 是一种高性能事件循环 / 事件驱动库。作为 libevent 的替代作品，其第一个版本发布与 2007 年 11 月。Libev 的设计者声称 libev 拥有更快的速度，更小的体积，更多功能等优势，这些优势在很多测评中得到了证明。正因为其良好的性能，很多系统开始使用 libev 库。本章将介绍如何使用 Libev 实现提供问答服务的服务器。 （事实上，现存的事件循环 / 事件驱动库有很多，作者也无意推荐读者一定使用 libev 库，而只是为了说明事件驱动模型给网络服务器编程带来的便利和好处。大部分的事件驱动库都有着与 libev 库相类似的接口，只要明白大致的原理，即可灵活挑选合适的库。） 与前章的模型类似，libev 同样需要循环探测事件是否产生。Libev 的循环体用 ev_loop 结构来表达，并用 ev_loop( ) 来启动。 void ev_loop( ev_loop loop, int flags ) Libev 支持八种事件类型，其中包括 IO 事件。一个 IO 事件用 ev_io 来表征，并用 ev_io_init() 函数来初始化： void ev_io_init(ev_io io, callback, int fd, int events) 初始化内容包括回调函数 callback，被探测的句柄 fd 和需要探测的事件，EV_READ 表“可读事件”，EV_WRITE 表“可写事件”。 现在，用户需要做的仅仅是在合适的时候，将某些 ev_io 从 ev_loop 加入或剔除。一旦加入，下个循环即会检查 ev_io 所指定的事件有否发生；如果该事件被探测到，则 ev_loop 会自动执行 ev_io 的回调函数 callback()；如果 ev_io 被注销，则不再检测对应事件。 无论某 ev_loop 启动与否，都可以对其添加或删除一个或多个 ev_io，添加删除的接口是 ev_io_start() 和 ev_io_stop()。 void ev_io_start( ev_loop loop, ev_io io ) void ev_io_stop( EV_A_ ) 由此，我们可以容易得出如下的“一问一答”的服务器模型。由于没有考虑服务器端主动终止连接机制，所以各个连接可以维持任意时间，客户端可以自由选择退出时机。图8 使用libev库的服务器模型 上述模型可以接受任意多个连接，且为各个连接提供完全独立的问答服务。借助 libev 提供的事件循环 / 事件驱动接口，上述模型有机会具备其他模型不能提供的高效率、低资源占用、稳定性好和编写简单等特点。 由于传统的 web 服务器，ftp 服务器及其他网络应用程序都具有“一问一答”的通讯逻辑，所以上述使用 libev 库的“一问一答”模型对构建类似的服务器程序具有参考价值；另外，对于需要实现远程监视或远程遥控的应用程序，上述模型同样提供了一个可行的实现方案。 总结 本文围绕如何构建一个提供“一问一答”的服务器程序，先后讨论了用阻塞型的 socket 接口实现的模型，使用多线程的模型，使用 select() 接口的基于事件驱动的服务器模型，直到使用 libev 事件驱动库的服务器模型。文章对各种模型的优缺点都做了比较，从比较中得出结论，即使用“事件驱动模型”可以的实现更为高效稳定的服务器程序。文中描述的多种模型可以为读者的网络编程提供参考价值。

C/S

架构

C/S

架构是一种典型的两层架构，其全程是Client/Server，即客户端服务器端架构，其客户端包含一个或多个在用户的电脑上运行的程序，而服务器端有两种，一种是数据库服务器端，客户端通过数据库连接访问服务器端的数据；另一种是Socket服务器端，服务器端的程序通过Socket与客户端的程序通信。

C/S

架构也可以看做是胖客户端架构。因为客户端需要实现绝大多数的业务逻辑和界面展示。这种架构中，作为客户端的部分需要承受很大的压力，因为显示逻辑和事务处理都包含在其中，通过与数据库的交互（通常是SQL或存储过程的实现）来达到持久化数据，以此满足实际项目的需要。

C/S

架构的优缺点

优点：

1C/S架构的界面和操作可以很丰富。

2安全性能可以很容易保证，实现多层认证也不难。

3由于只有一层交互，因此响应速度较快。

缺点：

1适用面窄，通常用于局域网中。

2用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户。

3维护成本高，发生一次升级，则所有客户端的程序都需要改变。

B/S架构

B/S架构的全称为Browser/Server，即浏览器/服务器结构。Browser指的是Web浏览器，极少数事务逻辑在前端实现，但主要事务逻辑在服务器端实现，Browser客户端，WebApp服务器端和DB端构成所谓的三层架构。B/S架构的系统无须特别安装，只有Web浏览器即可。

B/S架构中，显示逻辑交给了Web浏览器，事务处理逻辑在放在了WebApp上，这样就避免了庞大的胖客户端，减少了客户端的压力。因为客户端包含的逻辑很少，因此也被成为瘦客户端。

B/S架构的优缺点

优点：

1）客户端无需安装，有Web浏览器即可。

2）BS架构可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强。

3）BS架构无需升级多个客户端，升级服务器即可。

缺点：

1）在跨浏览器上，BS架构不尽如人意。

2）表现要达到CS程序的程度需要花费不少精力。

3）在速度和安全性上需要花费巨大的设计成本，这是BS架构的最大问题。

4）客户端服务器端的交互是请求-响应模式，通常需要刷新页面，这并不是客户乐意看到的。（在Ajax风行后此问题得到了一定程度的缓解）

按服务器的处理器架构（也就是服务器CPU所采用的指令系统）划分把服务器分为CISC架构服务器、RISC架构服务器和VLIW架构服务器三种。 CISC的英文全称为“Complex Instruction Set Computer”,即“复杂指令系统计算机”，从计算机诞生以来，人们一直沿用CISC指令集方式。早期的桌面软件是按CISC设计的，所以，微处理器（CPU）厂商一直在走CISC的发展道路，包括Intel、AMD，还有其他一些已经更名的厂商，如TI（德州仪器）、Cyrix以及VIA（威盛）等。在CISC微处理器中，程序的各条指令是按顺序串行执行的，每条指令中的各个操作也是按顺序串行执行的。顺序执行的优点是控制简单，但计算机各部分的利用率不高，执行速度慢。CISC架构的服务器主要以IA-32架构（Intel Architecture,英特尔架构）为主，而且多数为中低档服务器所采用。

如果企业的应用都是基于NT平台的应用，那么服务器的选择基本上就定位于IA架构（CISC架构）的服务器。如果企业的应用主要是基于Linux操作系统，那么服务器的选择也是基于IA结构的服务器。如果应用必须是基于Solaris的，那么服务器只能选择SUN服务器。如果应用基于AIX（IBM的Unix操作系统）的，那么只能选择IBM Unix服务器（RISC架构服务器）。 台式服务器也称为“塔式服务器”。有的台式服务器采用大小与普通立式计算机大致相当的机箱，有的采用大容量的机箱，像个硕大的柜子。低档服务器由于功能较弱，整个服务器的内部结构比较简单，所以机箱不大，都采用台式机箱结构。这里所介绍的台式不是平时普通计算机中的台式，立式机箱也属于台式机范围，这类服务器在整个服务器市场中占有相当大的份额。

优点：塔式服务器它的外形以及结构都跟我们平时使用的立式PC差不多，由于服务器的主板扩展性较强、插槽也多出一堆，所以个头比普通主板大一些，因此塔式服务器的主机机箱也比标准的ATX机箱要大，一般都会预留足够的内部空间以便日后进行硬盘和电源的冗余扩展。

由于塔式服务器的机箱比较大，服务器的配置也可以很高，冗余扩展更可以很齐备，所以它的应用范围非常广，应该说目前使用率最高的一种服务器就是塔式服务器。

缺点：目前常见的入门级和工作组级服务器基本上都采用这一服务器结构类型，不过由于只有一台主机，即使进行升级扩张也有个限度，所以在一些应用需求较高的企业中，单机服务器就无法满足要求了，需要多机协同工作，而塔式服务器个头太大，独立性太强，协同工作在空间占用和系统管理上都不方便，这也是塔式服务器的局限性。不过，总的来说，这类服务器的功能、性能基本上能满足大部分企业用户的要求，其成本通常也比较低，因此这类服务器还是拥有非常广泛的应用支持。 机架式服务器的外形看来不像计算机，而像交换机，有1U（1U=175英寸）、2U、4U等规格。机架式服务器安装在标准的19英寸机柜里面。这种结构的多为功能型服务器。

优点：作为为互联网设计的服务器模式，机架服务器是一种外观按照统一标准设计的服务器，配合机柜统一使用。可以说机架式是一种优化结构的塔式服务器，它的设计宗旨主要是为了尽可能减少服务器空间的占用，而减少空间的直接好处就是在机房托管的时候价格会便宜很多。

很多专业网络设备都是采用机架式的结构（多为扁平式，就像个抽屉），如交换机、路由器、硬件防火墙这些。机架服务器的宽度为19英寸，高度以U为单位（1U=175英寸=4445毫米），通常有1U，2U，3U，4U，5U，7U）几种标准的服务器。机柜的尺寸也是采用通用的工业标准，通常从22U到42U不等；机柜内按U的高度有可拆卸的滑动拖架，用户可以根据自己服务器的标高灵活调节高度，以存放服务器、集线器、磁盘阵列柜等网络设备。服务器摆放好后，它的所有I/O线全部从机柜的后方引出（机架服务器的所有接口也在后方），统一安置在机柜的线槽中，一般贴有标号，便于管理。

缺点：机架式服务器因为空间比塔式服务器大大缩小，所以这类服务器在扩展性和散热问题上受到一定的限制，配件也要经过一定的筛选，一般都无法实现太完整的设备扩张，所以单机性能就比较有限，应用范围也比较有限，只能专注于某一方面的应用，如远程存储和Web服务的提供等 在一些高档企业服务器中由于内部结构复杂，内部设备较多，有的还具有许多不同的设备单元或几个服务器都放在一个机柜中，这种服务器就是机柜式服务器。

对于证券、银行、邮电等重要企业，则应采用具有完备的故障自修复能力的系统，关键部件应采用冗余措施，对于关键业务使用的服务器也可以采用双机热备份高可用系统或者是高性能计算机，这样的系统可用性就可以得到很好的保证。 刀片式服务器是一种HAHD（High Availability High Density，高可用高密度）的低成本服务器平台，是专门为特殊应用行业和高密度计算机环境设计的，其中每一块“刀片”实际上就是一块系统母板，类似于一个个独立的服务器。在这种模式下，每一个母板运行自己的系统，服务于指定的不同用户群，相互之间没有关联。不过可以使用系统软件将这些母板集合成一个服务器集群。在集群模式下，所有的母板可以连接起来提供高速的网络环境，可以共享资源，为相同的用户群服务。当前市场上的刀片式服务器有两大类：一类主要为电信行业设计，接口标准和尺寸规格符合PICMG（PCI Industrial Computer Manufacturer's Group）1x或2x，未来还将推出符合PICMG 3x 的产品，采用相同标准的不同厂商的刀片和机柜在理论上可以互相兼容；另一类为通用计算设计，接口上可能采用了上述标准或厂商标准，但 尺寸规格是厂商自定，注重性能价格比，属于这一类的产品居多。刀片式服务器目前最适合群集计算和IxP提供互联网服务。

优点：刀片服务器适用于数码媒体、医学、航天、军事、通讯等多种领域。其中每一块“刀片”实际上就是一块系统主板。它们可以通过本地硬盘启动自己的操作系统，如Windows NT/2000、Linux、Solaris等等，类似于一个个独立的服务器。

在这种模式下，每一个主板运行自己的系统，服务于指定的不同用户群，相互之间没有关联。不过可以用系统软件将这些主板集合成一个集群服务器。在集群模式下，所有的主板可以连接起来提供高速的网络环境，可以共享资源，为相同的用户群服务。在集群中插入新的“刀片”，就可以提高整体性能。而由于每块“刀片”都是热插拔的，所以，系统可以轻松地进行替换，并且将维护时间减少到最小。值得一提的是，系统配置可以通过一套智能KVM和9个或10个带硬盘的CPU板来实现。CPU可以配置成为不同的子系统。一个机架中的服务器可以通过新型的智能KVM转换板共享一套光驱、软驱、键盘、显示器和鼠标，以访问多台服务器，从而便于进行升级、维护和访问服务器上的文件。

1、c/s、b/s是当下两种服务器架构模型。

2、c/s架构是指客户端/服务器的架构，需要同时编写两套代码，即客户端一套，服务端一套，所以开发起来速度较慢，日后的维护工作量也较大。

3、b/s架构是指浏览器/服务器构架，只需要编写服务器端的代码即可，开发完成了，就可以将应用部署到一些中间服务器上来发布自己的运用，拿web应该用来说，这些服务器有IIS、jboss、weblogic、websphere、tomcat等等。

4、客户端与服务器交互时，服务器会根据客户端的不同请求进行相应的业务处理，之后将结果返回对客户端。

以上只是简单的描述了下c/s、b/s架构，更详细说明楼主可以网上找些相关资料了解。

有问题欢迎提问，！

从系统架构来看，目前的商用服务器大体可以分为三类，即对称多处理器结构(SMP：SymmetricMulti-Processor)，非一致存储访问结构(NUMA：Non-UniformMemoryAccess)，以及海量并行处理结构(MPP：MassiveParallelProcessing)。

一、SMP(SymmetricMulti-Processor)

所谓对称多处理器结构，是指服务器中多个CPU对称工作，无主次或从属关系。各CPU共享相同的物理内存，每个CPU访问内存中的任何地址所需时间是相同的，因此SMP也被称为一致存储器访问结构(UMA：UniformMemoryAccess)。对SMP服务器进行扩展的方式包括增加内存、使用更快的CPU、增加CPU、扩充I/O(槽口数与总线数)以及添加更多的外部设备(通常是磁盘存储)。

SMP服务器的主要特征是共享，系统中所有资源(CPU、内存、I/O等)都是共享的。也正是由于这种特征，导致了SMP服务器的主要问题，那就是它的扩展能力非常有限。对于SMP服务器而言，每一个共享的环节都可能造成SMP服务器扩展时的瓶颈，而最受限制的则是内存。由于每个CPU必须通过相同的内存总线访问相同的内存资源，因此随着CPU数量的增加，内存访问冲突将迅速增加，最终会造成CPU资源的浪费，使CPU性能的有效性大大降低。实验证明，SMP服务器CPU利用率最好的情况是2至4个CPU。

二、NUMA(Non-UniformMemoryAccess)

由于SMP在扩展能力上的限制，人们开始探究如何进行有效地扩展从而构建大型系统的技术，NUMA就是这种努力下的结果之一。利用NUMA技术，可以把几十个CPU(甚至上百个CPU)组合在一个服务器内。

NUMA服务器的基本特征是具有多个CPU模块，每个CPU模块由多个CPU(如4个)组成，并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为CrossbarSwitch)进行连接和信息交互，因此每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要差别)。显然，访问本地内存的速度将远远高于访问远地内存(系统内其它节点的内存)的速度，这也是非一致存储访问NUMA的由来。由于这个特点，为了更好地发挥系统性能，开发应用程序时需要尽量减少不同CPU模块之间的信息交互。利用NUMA技术，可以较好地解决原来SMP系统的扩展问题，在一个物理服务器内可以支持上百个CPU。比较典型的NUMA服务器的例子包括HP的Superdome、SUN15K、IBMp690等。

但NUMA技术同样有一定缺陷，由于访问远地内存的延时远远超过本地内存，因此当CPU数量增加时，系统性能无法线性增加。如HP公司发布Superdome服务器时，曾公布了它与HP其它UNIX服务器的相对性能值，结果发现，64路CPU的Superdome(NUMA结构)的相对性能值是20，而8路N4000(共享的SMP结构)的相对性能值是63。从这个结果可以看到，8倍数量的CPU换来的只是3倍性能的提升。

三、MPP(MassiveParallelProcessing)

和NUMA不同，MPP提供了另外一种进行系统扩展的方式，它由多个SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。其基本特征是由多个SMP服务器(每个SMP服务器称节点)通过节点互联网络连接而成，每个节点只访问自己的本地资源(内存、存储等)，是一种完全无共享(ShareNothing)结构，因而扩展能力最好，理论上其扩展无限制，目前的技术可实现512个节点互联，数千个CPU。目前业界对节点互联网络暂无标准，如NCR的Bynet，IBM的SPSwitch，它们都采用了不同的内部实现机制。但节点互联网仅供MPP服务器内部使用，对用户而言是透明的。

在MPP系统中，每个SMP节点也可以运行自己的操作系统、数据库等。但和NUMA不同的是，它不存在异地内存访问的问题。换言之，每个节点内的CPU不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程一般称为数据重分配(DataRedistribution)。

但是MPP服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前一些基于MPP技术的服务器往往通过系统级软件(如数据库)来屏蔽这种复杂性。举例来说，NCR的Teradata就是基于MPP技术的一个关系数据库软件，基于此数据库来开发应用时，不管后台服务器由多少个节点组成，开发人员所面对的都是同一个数据库系统，而不需要考虑如何调度其中某几个节点的负载。