服务器类型的架构

按服务器的处理器架构（也就是服务器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转换板共享一套光驱、软驱、键盘、显示器和鼠标，以访问多台服务器，从而便于进行升级、维护和访问服务器上的文件。

服务器结构探讨 -- 最简单的结构
所谓服务器结构，也就是如何将服务器各部分合理地安排，以实现最初的功能需求。所以，结构本无所谓正确与错误；当然，优秀的结构更有助于系统的搭建，对系统的可扩展性及可维护性也有更大的帮助。
好的结构不是一蹴而就的，而且每个设计者心中的那把尺都不相同，所以这个优秀结构的定义也就没有定论。在这里，我们不打算对现有游戏结构做评价，而是试着从头开始搭建一个我们需要的MMOG结构。
对于一个最简单的游戏服务器来说，它只需要能够接受来自客户端的连接请求，然后处理客户端在游戏世界中的移动及交互，也即游戏逻辑处理即可。如果我们把这两项功能集成到一个服务进程中，则最终的结构很简单：
client ----- server
嗯，太简单了点，这样也敢叫服务器结构？好吧，现在我们来往里面稍稍加点东西，让它看起来更像是服务器结构一些。
　一般来说，我们在接入游戏服务器的时候都会要提供一个帐号和密码，验证通过后才能进入。关于为什么要提供用户名和密码才能进入的问题我们这里不打算做过 多讨论，云风曾对此也提出过类似的疑问，并给出了只用一个标识串就能进入的设想，有兴趣的可以去看看他们的讨论。但不管是采用何种方式进入，照目前看来我 们的服务器起码得提供一个帐号验证的功能。
我们把观察点先集中在一个大区内。在大多数情况下，一个大区内都会有多组游戏服，也就是多个 游戏世界可供选择。简单点来实现，我们完全可以抛弃这个大区的概念，认为一个大区也就是放在同一个机房的多台服务器组，各服务器组间没有什么关系。这样， 我们可为每组服务器单独配备一台登录服。最后的结构图应该像这样：
loginServer gameServer
　| /
　| /
　client
该结构下的玩家 *** 作流程为，先选择大区，再选择大区下的某台服务器，即某个游戏世界，点击进入后开始帐号验证过程，验证成功则进入了该游戏世界。但是，如果玩家想要切换游戏世界，他只能先退出当前游戏世界，然后进入新的游戏世界重新进行帐号验证。

服务器分塔式、机架式和刀片式这三种结构来划分服务器，服务器的外形为什么会有这样的划分呢？主要原因就是具体的应用环境不同，塔式服务器长得跟我们平时用的台式机一样，占用空间比较大，一般是一些小型企业自己使用自己维护；而机架式服务器长得就像卧着的台式机，可以一台一台的放到固定机架上，因此而得名，它可以拿去专业的服务器托管提供商那里进行托管，这样每年只需支付一定的托管费，就免去了自己管理服务器的诸多不便；而刀片服务器是近几年才比较流行的一种服务器架构，它非常薄，可以一片一片的叠放在机柜上，通过群集技术进行协同运算，能够处理大量的任务，特别适合分布式服务，如作为WEB服务器。

Ceph 是一个开源项目，它提供软件定义的、统一的存储解决方案 。Ceph 是一个具有高性能、高度可伸缩性、可大规模扩展并且无单点故障的分布式存储系统 。
Ceph 是软件定义存储解决方案
Ceph 是统一存储解决方案
Ceph 是云存储解决方案

高可用性

高扩展性

特性丰富

Ceph独一无二地统一的系统提供了对象存储、块存储和文件存储功能。Ceph存储集群由几个不同的软件守护进程组成（比较重要的两个是MON和OSD），每个守护进程负责Ceph的一个独特功能并将值添加到相应的组件中。

RADOS是CEPH存储系统的核心,也称为Ceph 存储集群。Ceph的数据访问方法(如RBD,CephFS,RADOSGW，librados)的所有 *** 作都是在RADOS层之上构建的。当Ceph 集群接收到来自客户端的请求时,CRUSH算法首先计算出存储位置,最后将这些对象存储在OSD中,当配置的复制数大于1时,RADOS负责的形式将数据分发到集群内的所有节点,最后将这些对象存储在OSD中。当配置的复制数大于1时,RADOS负责数据的可靠性,它复制对象，创建副本并将它们存储在不同的故障区域中。
RADOS包含两个核心组件: OSD和MON

OSD 是Ceph 存储集群中最重要的一个基础组件，他负责将实际的数据以对象的形式存储在每一个集群节点的物理磁盘中。对于任何读写 *** 作，客户端首先向MON请求集群MAP，然后客户端旧可以直接和OSD进行I/O *** 作。
一个Ceph 集群包含多个OSD。一个典型的Ceph集群方案会为集群节点上的每个物理磁盘创建一个ODS守护进程,这个是推荐的做法。OSD上的每个对象都有一个主副本和几个辅副本,辅副本分散在其他OSD。一个OSD对于一些对象是主副本，同时对于其他对象可能是辅副本，存放辅副本的OSD主副本OSD控制,如果主副本OSD异常(或者对应的磁盘故障),辅副本OSD可以成为主副本OSD。
OSD是有一个已经存在的Linux文件系统的物理磁盘驱动器和OSD服务组成。Ceph 推荐OSD使用的文件系统是XFS。OSD的所有写都是先存到日志,再到存储

MON 负责监控整个集群的健康状况。它以守护进程的形式存在,一个MON为每一个组件维护一个独立的MAP,如OSD，MON,PG,CRUSH 和MDS map。这些map 统称为集群的MAP。MON 不为客户端存储和提供数据,它为客户端以及集群内其他节点提供更新集群MAP的服务。客户端和集群内其他节点定期与MON确认自己持有的是否是集群最新的MAP一个Ceph集群通常包含多个MON节点,但是同一时间只有一个MON。

librados是一个本地的C语言库，通过它应用程序可以直接和RADOS通信，提高性能

Ceph 块存储，简称 RBD，是基于 librados 之上的块存储服务接口。RBD 的驱动程序已经被集成到 Linux 内核（2639 或更高版本）中，也已经被 QEMU/KVM Hypervisor 支持，它们都能够无缝地访问 Ceph 块设备。Linux 内核 RBD（KRBD）通过 librados 映射 Ceph 块设备，然后 RADOS 将 Ceph 块设备的数据对象以分布式的方式存储在集群节点中

RGW，Ceph对象网关，也称做RADOS网关，它是一个代理，可以将>

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

整合公司所有业务数据，建立统一的数据中心；

提供各种报表，有给高层的，有给各个业务的；

为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；

为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；

分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；

开发数据产品，直接或间接为公司盈利；

建设开放数据平台，开放公司数据；

。。。。。。

上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；
其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；
建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。
整体架构下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：
逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：
数据采集数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：

网站日志：

作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；

业务数据库：

业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。
当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。

来自于Ftp/>
有可能一些合作伙伴提供的数据，需要通过Ftp/也可以满足该需求；

其他数据源：

比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；
数据存储与分析毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。
离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；
当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。
数据共享这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；
前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据； 和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。
另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。
数据应用

业务产品

业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；

报表

同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；

即席查询

即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；
这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。
即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。
当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。

OLAP

目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；
这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；
比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。

其它数据接口

这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。
实时计算现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。
 我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。
做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。
任务调度与监控在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始； 这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。
前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。
总结在我看来架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

服务器与PC的区别应该从硬件和软件两方面来看，根据应用的不同两者的差别很大，打个比方，PC就是那什么都会的门诊医生，但是医术不是那么精湛，而服务器就应该是某个方面的专家了，处理能力越出 \x0d\众，它“专”的就越厉害。我先从硬件上，根据各个组件说说他们的不同： \x0d\1CPU 服务器CPU的指令一般是采用的RISC（精简指令集）。根据研究，在大多数的应用中，CPU仅仅使用了很少的几种命令，于是研究人员就根据这种情况设计了该指令集，运用集中的各种命令组合来实现各种需求。这种设计的好处就是针对性更强，可以根据不同的需求进行专门的优化，处理效更高。相对应的则是CISC（复杂指令集），他的特点就是尽量把各种常用的功能集成到一块，例如我们常常听到的MMX，SSE，SSE+，3D！NOW！等等都是这种类型的。另外，服务器的CPU设计一般都要考虑它的多路功能，说白了就是好几个甚至上千上万个CPU一起工作的问题，而PC则简单多了，这种多路功能用上实在浪费，而它的价钱也的确是上面兄弟说的，不是谁都能受的了的。（补充：服务器的寻址能力很早前就是64位了；APPEL采用的指令集也是RISC，他是个另类，不过现在已经投靠INTEL了）2内存。内存在服务器上的原则也上越快越大越好，不过它对纠错和稳定提出了更高的要求，比如ECC（"错误检查和纠正"好象没人这么叫的）。我们现在使用的PC上很少有人能够用到1G的内存（玩游戏的不算），而在服务器上，这G级的内存有时也会显着捉襟见肘，记得去年国家发布银河最新超级计算机时，他的内存更是达到了1个T；相比内存的速度，人们在应用的时候更优先考虑内存的稳定和纠错能力，只有在保证了这两条，才能再考虑别的东西。 \x0d\3硬盘。硬盘性能无论是在PC上还是服务器上，性能的提升一直很缓慢，个人认为，依靠机械的发展，硬盘的发展是不可能出现质的飞跃。由于使用服务器的一般都是企业单位，里面都是保存了大量珍贵数据，这对硬盘就提出了安全稳定的要求，硬盘上出现的相关技术也基本上围绕这两个要求转。比如：数据冗余备份，热插拔等。另外，服务器硬盘必须能做到247不间断工作的要求。 \x0d\4主板这个我了解的比较少，很少看到服务器有主板的说法，不过我觉得应该提提服务器的总线设计——多路，就是多个CPU如何能够协调工作。有兴趣建议你看看 *** 作系统方面的书，看老外写的，很好！ \x0d\5显卡除了图形和3D设计（那个人家好象都叫工作站，哪位达人知道请告诉我对不对），服务器上的显卡基本上就是你只要能接上显示器能显示就行！ \x0d\接下来我说说软件，软件就主要指 *** 作系统，比如我们熟悉的NT，2000 SERVER，2003 SERVER，LINUX，SOLRAIS和UNIX等等，都是专门针对服务器设计的，比如：负载均衡，多路CPU的支持。

---