系统架构:架构体系

每个公司的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等功能以协调(服务)任务调
度。

时间: 2024-08-11 03:38:11

系统架构:架构体系的相关文章

互联网支付系统整体架构详解(转)

在互联网产品运营中,有很多小伙伴或许会遇到这样的困扰:产品好不容易推出来了,流量成本节节攀升,用户的活跃度.留存度却持续下降. 因此在瞬息万变的互联网产品环境中,需要研发接入支付系统来加入商业行为的闭环,支付系统能够帮助企业更好地实现商业化,利用那些为用户而生的支付体系产品,实现用户积累.商业变现. 对于支付系统,有针对不同行业的支付系统,有支付宝,微信支付,paypal的通用网关支付,也有聚合了不同网关的聚合系统. 不论你是对支付行业感兴趣,亦或自己研发支付系统,本篇内容会对你有价值. 从产品

ARM架构与体系学习(二)——3级流水线

ARM架构与体系学习(二)——3级流水线 标签: 存储嵌入式汇编c 2012-04-18 00:44 5414人阅读 评论(4) 收藏 举报  分类: ARM7(16)  版权声明:本文为博主原创文章,未经博主允许不得转载. 看到汇编中很多关于程序返回与中断返回时处理地址都很特别,仔细想想原来是流水线作用的效果.所以,决定总结学习下ARM流水线. ARM7处理器采用3级流水线来增加处理器指令流的速度,能提供0.9MIPS/MHz的指令处理速度. PS: MIPS(Million Instruct

标准Web系统的架构分层

标准Web系统的架构分层 – 转载请注明出处 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的

标准Web系统的架构分层[转]

标准Web系统的架构分层 – 转载请注明出处 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的

逻辑架构、体系架构、整体架构、功能架构

1.(逻辑本身跟物理是对应的,逻辑架构前面还缺少一个定语,比如部署逻辑架构,偏向于系统逻辑部署,与物理部署架构关联:)即部署逻辑架构等同于网络拓扑2.(系统逻辑架构,则更偏向于系统的功能流转,与功能架构关联 )即系统逻辑架构等同于应用架构.业务架构3.(体系架构和总体架构一直认为是一个总括的名词,它应该由系统定位.功能.技术.逻辑部署.物理部署等等专注于某一方面架构共同组成 )即体系架=整体架构=设计架构,不同叫法而已.

分布式发布订阅消息系统 Kafka 架构设计[转]

分布式发布订阅消息系统 Kafka 架构设计 转自:http://www.oschina.net/translate/kafka-design 我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础.现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部

企业架构框架体系

基本概念 框架(Framework):是处理某类/某方面问题的思路/办法,通过前期大量的研究.尝试.调整.完善.验证,设计和归纳出一套通用的.可行的方法和知识的组织结构,能够帮助其它人处理类似的问题.是一个宏观.高阶的指导,但框架不是标准答案,没有直接的结果,需要在理解的基础上灵活运用. 方法论(Mehtodology):是某一个具体问题的方法和工具,方法论会对一系列具体的方法进行分析研究.系统总结并最终提出较为一般性的原则.方法论是企业架构框架的组成部分,框架的广度和高度需要多方面方法论的支持

(系统架构)标准Web系统的架构分层

标准Web系统的架构分层 1.架构体系分层图 在上图中我们描述了Web系统架构中的组成部分.并且给出了每一层常用的技术组件/服务实现.需要注意以下几点: 系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用.例如:一些简单的CRM系统可能在产品初期并不需要K-V作为缓存:一些系统访问量不大,并且可能只有一台业务服务器存在,所以不需要运用负载均衡层. 业务系统间通信层并没有加入传统的HTTP请求方式.这是因为HTTP请求-响应的延迟比较高,并且有很多次和正式请求无关的通信(这在下面的内容

业务系统技术架构的方法论

业务类系统(通常称为To B 类产品),一般包括crm,供应链,物流等.系统的架构设计非常具有挑战性. 面向用户的To C 类前台产品,无论产品经理还是用户都已经培养起了使用习惯,对功能有一定程度的理解,见过的模式足够多,能够建立起一定的产品模型,也容易找到参照物去模仿.但是业务类的系统,常常是没有参照和模仿,一些业务流程的不同,一点公司组织结构的不同,你家的CRM和他家的CRM可能完全没有参考性.所以在搭建产品架构的时候则要求产品经理非常懂业务,考验PM能力的同时,对技术架构也具备很大的挑战.