系统架构:架构体系

每个公司的IT环境，不论大小复杂度，总会有个系统架构层次。有了这个架构体系，那所有的运维事情大体都围绕着这个系统架构上的每个元素及整体关联进行运维保障工作。运维架构从某种角度可以划分为两大阵营：

 商业封闭式系统架构（IOE架构）：以使用IBM、Oracle、EMC产品为代表的一系列软硬件产品为主要元素的运维系统架构，以及围绕这个架构的人、事、物、流程标准。

 开源系统架构（非IOE架构）：以使用廉价PC服务器，开源产品技术（而非IOE）为主要元素的运维系统架构，以及围绕这个架构的人、事、物、流程标准。

基于上述两种运维架构的单位企业都很多，几乎涉及到了政府、企事业、民营的各个行业单位。有的单位使用上述其中一种运维架构为主，而还有相当多一些单位会混用上述两种运维架构。

一、商业封闭式系统架构（IOE架构）

典型的IOE架构即以IOE产品软硬件为主要平台的系统架构。这种架构中使用了大量IOE为代表的产品元素，在运维技术要求、采购成本方面相对（下述的非IOE架构）是高门槛。该架构的设备系统在性能与稳定性方面表现出色，服务对象主要面向一些特定服务对象以及特定服务为主。基于IOE架构的典型企业如：金融业、电信业，交通运输业。

IOE架构以纵向扩展为特点，通常通过增加CPU、内存、磁盘、扩展柜、冗余备件、备份设备等方式来提高处理能力及稳定性。该架构的处理能力主要取决于单台（套）设备（系统）的最大扩展能力，很难通过增加设备（系统）数量来增加处理能力，换句话说该架构很难通过扩大集群规模的方式来解决问题。虽然单方面可扩展IOE元素资源（如小型机集群、Oracle RAC、EMC扩展柜等），但其单机扩展能力毕竟是有限的，而且随着纵向扩展的规模增大，其实施技术难度、管理复杂度以及隐患风险都会正比例大幅上升。在IOE架构中，往往比较关注“点”，例如宕机通常是一种非常严重的事件。

   IOE典型的系统架构图如下图1-1示例：

图1-1          

上述即典型的IOE型系统架构。该架构一般会将相同业务系统的数据都集中在一套IOE架构中，提供集中管理的（关系型）数据库，依靠大型高端设备来提供高处理能力和扩展性，数据的保存与备份通常也会集中保存到磁盘阵列（与带库）中。

在该架构中，其服务器多使用小型机、大型机（还有以往的中型机），存储则多使用知名 品牌的中高端存储阵列、带库等设备。服务器与存储之间多使用SAN存储网络。这些服务器、存储等硬件本身往往就是双冗余的，线路连线也都是双冗余的，而且 设备性能指标往往非常好，例如一台普通中端的Power 7系列服务器可以轻松划分出若干个系统分区或者一二十个虚拟机系统。

而对于系统使用的软件，往往也是IOE相关产品。例如数据库系统往往会使用Oracle，而系统应用架构往往就是Oracle RAC或者PowerHA。

二、开源系统架构（非IOE架构）

典型开源系统架构即以开源产品为基础的系统架构。这种架构使用了大量PC服务器及非IOE的 商业产品，同时纳入了大量开源产品元素。该架构在运维技术要求、采购成本方面相对低廉，容易上手。该架构的设备系统在单机性能与稳定性方面较弱，但在大规 模集群、自主灵活与开发定制方面表现出色。该系统架构服务对象主要面向广大普通用户，基于开源系统架构的典型企业如：以BAT（百度、阿里、腾讯）为代表的众多互联网企业，以及大量中小型企业。

开源系统架构以横向扩展，分布式部署为特点。通常通过往集群中增加单机设备资源解决存储空间、性能以及稳定性问题，其集群规模可以小到两三台PC服务器组成，也可以大到上万台PC服务器集群。对于数据库的扩展也很方便，可以通过分布式MySQL集群便解决了数据库扩展性的问题。另外非结构化数据库及分布式文件系统在处理非结构化数据的存储与使用方面也很灵活方便。

当然随着开源系统横向扩展的规模增大，其实施技术难度、管理复杂度以及隐患风险同样会正比例大幅上升。在开源系统架构中，往往关注“面”，单个宕机通常不再是严重的事件。开源系统架构的难度在于海量运维，在于运维架构的开发与磨合。

开源系统架构图如下图1-2示例：

图1-2          

   上述开源系统架构中使用了CDN和反向代理以提高网站性能。

例如我们的服务器可能部署在北京，对于北京及周边用户来说访问是较快的，而对于远离北京的用户的访问则感觉较慢，因为数据传输时间比较长。对于这种情况，常常使用CDN解决，CDN将数据内容缓存到运营商（或自建CDN）的机房，用户访问时先从最近的CDN机房获取数据，这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。

对 于反向代理，则是部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将(Varnish)缓存的数据返回给用户，如果没有没有缓 存数据才会继续走应用服务器获取，也减少了获取数据的成本。当然对于海量访问请求，或者庞大集群服务中，单靠F5、LVS、或者Ngnix等反向代理往往 不能满足架构稳定需要，这个时候就需要分多层、综合运用上述负载均衡以及代理（反代理），同时可能需要引入zookeeper等功能以协调（服务）任务调 度。