系统架构设计理论与原则

一、无共享架构

1、无共享架构

无共享架构是一种分布式计算架构,这种架构中不存在集中存储的状态,系统中每个节点都是独立自治的,整个系统中没有资源竞争,这种架构具有非常强的扩张性,目前在web应用中被广泛使用。

无共享架构的一个重要实践指导原则就是避免在互联系统中使用Session,因为实践已经证明,在一个集群分布式计算环境中,若Session状态维护在各个节点服务器上,为了保证状态一致性,节点间Session数据需要互相拷贝同步,严重影响性能,我们需要尽可能的改造现有架构不要使用Session。

2、对比

shared-nothing、shared-memory、shared-disk是并行系统最常使用的模式。
shared-memory:多个cpu共享同一片内存,cpu之间通过内部通讯机制进行通讯
shared-disk:每一个cpu使用自己的私有内存区域,通过内部通讯机制直接访问所有磁盘系统
和shared-memory、shared-disk相比,shared-nothing优势明显,在针对多用户并行访问的时候,通过横向扩充资源,能够大大减少响应时间,提升整体吞吐量和效率。

3、分片

shared noting需要确立一种分片策略,使得依据不同的分片策略,减少资源竞争。

三种基本的分片策略结构:

(1)功能分片 根据多个功能互相不重叠的特点进行分片,这种方式已经在ebay取得巨大成功。缺点也很明显,即技术人员需要深入理解应用领域,才能更好地分片;

(2)键值分片 在数据中找到一个可以均匀分布到各个分片中的键值。

(3)查表 在集群中有一个节点充当目录角色,用于查询哪个节点拥有用户要访问的数据。缺点在于这个表可能成为整个系统的瓶颈及单点失效点;

二、负载均衡

负载均衡(Load Balance),顾名思义,是把服务的并发请求均衡地负载到后端多个具有相同能力的服务进行处理分担,以廉价有效透明的方式扩展网络设备或服务的带宽,增加吞吐量,增强服务的整体处理能力,提供服务的灵活性和可用性。

常见的典型的负载均衡应用场景:

(1)、web集群:将大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间。

(2)、MapReduce:单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给?户,系统处理能?得到大幅度提高。

负载均衡算法

负载均衡算法是负载均衡设备(包括虚拟设备或相关软件)在执行负载均衡调度,选择具体处理的后端服务的时候使用的调度和分发的逻辑。负载均衡的算法只是规定了调度和分发的逻辑,在不同的负载均衡方案中都可能使用相同和(或)类似的算法,它只是负载均衡方案的一部分。

常见的主流负载均衡算法包括:

(1)轮询算法:Round Robin/Weight Round Robin Scheduling

轮询算法通过依次轮叫的方式依次将请求调度不同的后端服务器(Real Server)。通常可以分为普通轮询和加权轮询两种方式。算法的优点是简洁且无状态。

算法简单表示为:i = ( i + 1 ) mod n

(2)Hash算法: 随机数Hash,Sources Hashing Scheduling

Hash算法,又叫取余算法。一般是对请求报文中的某项数据(key,一般常用客户端来源IP)计算Hash值,然后按机器数量(n)取模。

算法简单表示为:idx = Hash(key) % n

Hash算法中,Key的选择常用实践如下:

a、请求时间或随机数 特点是简单,具有一定分散性,但不稳定,一般用于要求不高的负载均衡场景。

b、来源IP

特点是简单。如果客户的分布比较广,这种方式分散性较好。但如果较多的客户请求来源于同一IP(公司网络通过路由器上网),分散效果较差。

大多负载均衡设备都支持这种算法,著名的nginx和LVS等软件也支持。

(3)一致性Hash算法:Consistency Hash Scheduling

一致性Hash算法最常用于分布式缓存(如memcached、redis等)的定位,但同时也可以在系统或程序中用于负载均衡,该算法本来的意义就在于分散负载和快速定位。

(4)最少连接或请求数: (Weight)Least Connection/Request Scheduling

最小连接调度是一种动态调度算法,它通过服务器当前所活跃的连接数来估计服务器的负载情况。

算法主要逻辑是,调度设备或服务记录后端服务器接受请求的计数,每次请求总是发给计数最小的服务器处理。

(5)最大空闲:Most idle First(基于监控CPU,内存,带宽等综合评估) (6)、平均最快响应:平均最快响应 (7)、最少流量:Least Traffic Scheduling

还有一种常见的就是基于会话的负载实现,但是严格来说Session(一般用于WEB)不能算是算法。Session实现负载均衡的主要过程为:首次请求记录用户的SessionID,然后再通过轮询等算法选择后端服务器,如果用户后续使用同一SessionID发起请求,则无需再选择服务器,直接转发给前面根据SessionID找到的对应的后端服务器。

负载均衡模式

负载均衡模式主要是指在整体方案中选择从服务网络的哪个层次或哪个产品来实现负载均衡方案。

1、外部模式(RR-DNS)

RR-DNS,即DNS轮询模式,它的原理是利用DNS服务器支持同一域名配置多个独立IP指向,然后轮询解析指向IP实现多次访问的调度和分发,实现负载均衡。

它的主要特点为:

a、负载均衡实现与后端服务完全没有关系,有DNS在本地解析指向实现轮询调度。这个方面来看性能最佳效率最高。

b、DNS服务无法检测到后端服务器是否正常,在TTL失效前,会一直指向失效的服务器,这就要求在实践生成中,必须解决后端服务器的高可用问题。

c、一般的第三方DNS服务提供商都支持该功能,但如果更新频率高或附带更新逻辑,一般会在系统内自键DNS服务,然后在注册为公共DNS服务。

2、应用层模式

正向代理:用户通过代理服务访问internet, 把internet返回的数据转发给用户。正向代理对于整个网络请求,它的角色实际是客户端,代理客户对外的访问请求。 反向代理:接受internet上用户的请求,转发给内部的多台服务器处理,完成后转发后端服务器的返回给对应的用户。反向代理对于整个网络请求,它的角色实际是服务器,代理接受(accept)所有用户的请求。

反向代理应用模式:常见的反向代理应用模式,比如通过 Apache, nginx等Web服务器软件实现WEB应用的负载均衡和高可用。利用反向代理软件实现负载均衡是性价比较高的模式。

三、高可用性系统设计

系统高可用性的常用设计模式包括三种,包括:

1、主备(Active-Standby)

工作原理:主机工作,备机处于监控准备状况;当主机宕机时,备机接管主机的一切工作,待主机恢复正常后,按使用者的设定以自动(热备)或手动(冷备)方式将服务切换到主机上运行。一般需要人工干预才能回复初始状态。

2、互备(Active-Active)

工作原理:两台主机(A标记为主,B标记为备)同时运行各自的服务工作且相互监测情况,当任一台主机(A)宕机时,另一台主机(B,启用并标记为主)立即接管它的一切工作,保证工作实时可用

3、集群(Cluster)

工作原理:多台具有相同能力的服务同时对外提供透明服务,所有服务之间都是Active-Active关系,并分担处理服务请求,一般通过总控节点或集群软件(例如zookeeper等)进行高可用的控制。

时间: 2024-10-24 15:30:26

系统架构设计理论与原则的相关文章

架构设计理论与原则

1,考量成本,先硬后软原则

电商峰值系统架构设计--转载

1.1 系统架构设计目录 摘要:双11来临之际,<程序员>以“电商峰值系统架构设计”为主题,力邀京东.当当.小米.1号店.海尔商城.唯品会.蘑菇街.麦包包等电商企业,及商派.基调网络等服务公司,分享电商峰值系统架构设计的最佳技术实践. 自2009年11月11日,淘宝商城(现名天猫)拉开网购狂欢节的序幕,各大电商的促销浪潮此起彼伏.此时的电商大战不仅是价格之争,更是技术的较量.如何设计电商峰值系统来更好地满足用户蜂拥而至的访问,如何在海量数据处理中实时发现有效信息并转化为商机,成为众多电商企业密

迈向大数据架构师 - 架构师转型方法与架构设计理论

迈向大数据架构师 - 架构师转型方法与架构设计理论课程学习地址:http://www.xuetuwuyou.com/course/233课程出自学途无忧网:http://www.xuetuwuyou.com课程摘自<大数据系统架构分析师成长之路>:http://www.xuetuwuyou.com/course/200 1.课程目标通过本课程的学习,让学员了解到什么是系统架构师,什么大数据系统架构师,两者的区别与联系,程序员与架构师的不同,程序员如何向架构师转型,一个架构师工作日常及必须修炼的

数字资产交易平台开发的架构设计理论架构

数字资产交易平台开发的架构设计理论架构架构和设计,这是整个系统的灵魂步骤.一个架构不过关,到后面的问题可能是毁灭性的(相同业务量,相近的硬件,你的系统只跑两年就很卡,人家跑五年没事,很可能就是架构没做好);系统设计不过关,必定走不久,未来业务变化,可能又要换系统...所以想要稳定的系统就要找靠谱的开发商,138.2311-8291源中瑞科技. 1)业务流程设计(可能涉及到业务流程重组,最费事又可能最反复,也是风险最高的地方); 2)系统架构设计(cs还是bs?有没有app?私有部署还是公有云部署

机票实时搜索系统架构设计

机票实时搜索系统架构设计 ? 不同的业务场景,不同的特征 ? 结合特征去进?设计和优化 ? 通?!=最优 ? 量体裁? 分布式系统的CAP理论 首先把分布式系统中的三个特性进行了如下归纳:    ● 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值.(等同于所有节点访问同一份最新的数据副本) ● 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求.(对数据更新具备高可用性) ● 分区容错性(P):以实际效果而言,分区相当于对通信的时限要求.系统如果不能

Unity3D手游开发日记(2) - 技能系统架构设计

我想把技能做的比较牛逼,所以项目一开始我就在思考,是否需要一个灵活自由的技能系统架构设计,传统的技能设计,做法都是填excel表,技能需要什么,都填表里,很死板,比如有的技能只需要1个特效,有的要10个,那么表格也得预留10个特效的字段.在代码里面也是写死一些东西,要增加和修改,就得改核心代码,如果我要把核心部分做成库封装起来,就很麻烦了. 能不能做成数据驱动的方式呢? 改技能文件就行了,即使要增加功能,也只需要扩展外部代码,而不用改核心代码, 我是这么来抽象一个技能的,技能由一堆触发器组成,比

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有许多细分行业的IM,比如淘宝阿里旺旺.网易泡泡.YY语音.......恰巧公司产品也要开发一款基于我们自己行业的类IM系统,很有幸我担当了这个产品的架构师,核心代码编写.实现者.下面我近年来从技术上我对IM系统(即时消息的传输,不包括语音,视频,文件的传输)的理解和设计分享出来,浅薄之见,望大家别见笑,欢迎给出批评意见. 一.网络传输协议的选择 目前我知晓的所有IM系统传输即时消息无外乎使用UDP.TCP.基于TCP的http这几种协议中的一种或几种

秒杀系统架构设计

秒杀活动的用户量可能是网站平时正常访问量的数百甚至上千倍,网站如果为了秒杀时的最高并发量而设计部署,就需要比正常运营多的多的服务器,而这些服务器在绝大部分时候都是用不着的,浪费惊人.所以秒杀业务不能使用正常网站的业务流程,也不能与正常网站业务共用服务器,必须设计部署专门的秒杀系统. 秒杀系统所面对的技术挑战: 1.对现有业务造成冲击 2.高并发下的应用.数据库负载 3.突然增加的网络及服务器带宽 4.直接下单 秒杀规则是到点了才能下单,而下单页面也只是一个普通的url,如果得到这个url则不用等

petshop4.0 具体解释之中的一个(系统架构设计)

前言:PetShop是一个范例,微软用它来展示.Net企业系统开发的能力.业界有很多.Net与J2EE之争,很多数据是从微软的PetShop和Sun的PetStore而来.这样的争论不可避免带有浓厚的商业色彩,对于我们开发者而言,没有必要过多关注.然而PetShop随着版本号的不断更新,至如今基于.Net 2.0的PetShop4.0为止,整个设计逐渐变得成熟而优雅,却又非常多能够借鉴之处.PetShop是一个小型的项目,系统架构与代码都比較简单,却也凸现了很多颇有价值的设计与开发理念.本系列试