大型网站架构之架构模式

上节讲了《大型网站架构之架构演变》,今天讲下架构的模式,什么是模式呢?每一个模式描述了一个再我们周围不断重复发生的问题及问题解决方案的核心,这样你就能一次次重用该方案而不必去做重复的工作,可见模式的关键在于可重复性。

网站架构模式的目标:面临高并发访问,海量数据处理,高可靠运行等问题和挑战,我们在实践中提出很多解决方案,主要为了实现网站的高性能、高可用、易伸缩、可扩展、安全等架构目标。

网站架构模式具体方案如下:

1、分层

分层是一种常见的架构模式,将系统在横向维度上切分为几个部分,每个部分负责单一的职责,然后通过上层对下层的依赖和调用完成整个系统工作。一般大型网站系统都分为下面3层:

  • 应用层:负责具体业务和视图展示;
  • 服务层:为应用层提供服务支持;
  • 数据层:提供数据存储访问服务;

分层架构的挑战:必须合理规划层次边界和接口;

分层架构的约束:禁止跨层次调用及逆向调用(数据层不允许调用服务层,服务层不允许调用应用层)

2、分割

分层是横向切分,分割则是纵向切分,将不同的功能和服务分割开,包装成高内聚低耦合的模块单元,这样做的好处在于:

  • 有助于软件开发和维护;
  • 便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力;

3、分布式

对于大型网站,分层和分割的目的都是为了便于分布式部署,将不同的模块部署在不同的服务器上,通过远程调用协同工作,分布式意味着我们可以使用更多的计算机完成同一个任务,计算机物理机越多,CPU,内存,存储资源就越多,能处理的并发访问和数据量也就更大,但是分布式也会带来一些问题:

  • 分布式服务意味着通过网络调用,会对性能造成影响;
  • 服务器越多,服务器宕机的概率就越大,使网站的可用性降低;
  • 数据在分布式环境下保持数据一致性也就比较困难;
  • 分布式下的事务也难以保证;
  • 分布式管理增了开发和维护的难度,切记不要为了分布式而分布式;

分布式的常见几种方案:

  • 分布式应用和服务:将分层和分割后的应用和服务模块分布式部署,可以改善网站性能和并发性,加快开发和发布的速度,减少数据库连接资源消耗,使不同的应用复用共同的服务,便于业务扩展;
  • 分布式静态资源:网站的静态资源例如js,css,图片等资源独立分布式部署,并采用独立的域名,即动静分离;静态资源分布式部署可以减轻应用服务器的负载压力,通过域名独立加快浏览器并发加载的速度;
  • 分布式数据和存储:大型网站需要处理以P为单位的海量数据,单台计算机无法提供如此大的存储空间,这些数据需要分布式存储;
  • 分布式计算:目前网站普遍使用Hadoop和MapReduce分布式计算框架进行批处理计算,其特点就是移动计算而不是移动数据,将计算程序分发到数据所在的位置,以加速计算和分布式计算;
  • 分布式配置:网站线上服务器配置实时更新;
  • 分布式锁:分布式环境下实现并发和协同工作;
  • 分布式文件:支持云存储的分布式文件系统;

4、集群

对于用户访问集中的模块,我们还需要考虑将其集群化,多台服务器部署相同应用构成一个集群,通过负载均衡器将请求分发给集群中不同的服务器处理。集群模式可以很好的扩展,当有更多用户访问时,只需要向集群中添加一台新的服务器加入集群即可,同时因为一个应用由多台服务器提供服务,当某台服务器发生故障时,负载均衡器或者系统的失效转移机制会将请求转发到集群中其他的服务器上,所以我们在配置集群时,至少需要2台以上服务器构成一个集群,目的就是为了提供系统的可用性。

5、缓存

将数据存放在距离计算最近的位置,加快处理速度。大型网站架构设计一般在下面几个方面使用缓存设计:

  • CDN:即内容分发网络,部署在距离终端用户最近的网络服务商,用户网络请求总是先到达他的网络服务商那里,在这里缓存一些静态资源,就可以以最快的速度返回资源给用户;
  • 反向代理:属于网站前端部分,部署在网站的前端,当用户请求到达网站的时候,最先访问到的就是反向代理服务器,这里缓存网站的静态资源,无需将请求继续转发给应用服务器就能直接返回给用户;
  • 本地缓存:在应用服务器本地缓存一些热点数据(段时间内经常被访问的数据),应用程序可以在本机内存中直接访问数据,而无需访问数据库;
  • 分布式缓存:将数据缓存在一个专门的分布式缓存集群中,应用程序通过网络通信获取缓存的数据;

使用缓存有2个前提条件:

  • 数据访问热点不均衡,某些数据会被更频繁的访问,这部分数据就该放入缓存;
  • 数据在某个时间段内有效,不会很快过期,否则缓存失效的数据就会因为失效而产生脏读,影响结果的正确性;

使用缓存的优势:加快数据访问速度以及减轻后端应用和数据存储的负载压力;

6、异步

大型网站的一个重要目标是降低软件的耦合性,系统解耦合的手段除了前面提到的分层、分割和分布式等,还有一个异步,业务之间的消息传递不是同步调用,而是将业务操作分成多个阶段,每个阶段之间通过共享数据的方式异步的进行协作;

  • 在单一服务器内部可以通过多线程共享内存队列的方式实现异步,业务前执行的线程将数据写入队列,后续线程从队列中读取数据进行处理;
  • 在分布式系统中,多个服务器集群通过分布式消息队列实现异步,分布式消息队列可以看做是内存队列的分布式部署;

异步架构是典型的生产者和消费者模式,此外异步消息队列还有如下特性:

  • 提高系统可用性:消费者服务器宕机时,数据会堆积在消息队列中,生产者服务器可以继续处理业务请求,不影响系统整体运行,当消费者服务器恢复正常后可以继续处理消息队列中的数据;
  • 加快网站响应速度:处在业务处理前端的生产者服务器在处理完业务请求后,可以将数据写入消息队列,不需要等待结果直接返回,减少响应延迟;
  • 消除并发访问高峰:使用消息队列将突发的高峰访问请求数据放入消息队列中,等待消费者依次处理,不会对整个网站负载造成太大的压力;

7、冗余

网站需要24小时为用户提供服务,想要保证在服务器宕机的情况下,不影响网站的运行,不丢失数据,就需要将一定程度的服务器冗余运行,数据冗余备份,这样,当某台服务器宕机时,可以将其上面的服务和数据访问转移到其他冗余的服务器上。

数据库除了定期备份,存档保存,实现冷备份之外,为了保证在线业务高可用,还需要对数据库进行主从分离,实时同步实现热备份。

为了抵制一些非人为的天灾,一般还需要对整个网站数据中心进行备份,全球范围内部署灾备数据中心,网站程序和数据实时同步到多个灾备中心。

8、自动化

主要包括自动化代码管理、自动化测试、自动化安全检测、自动化部署等实现发布过程自动化;此外还需要对服务器进行自动化监控、自动化报警、自动化失效转移(将失效的服务器从集群中隔离出去)、自动化失效恢复(重启服务之后同步数据保证数据的一致性)、自动化降级(通过拒绝部分请求及关闭一些不重要的服务将系统负载降至一个安全的水平)以及自动化分配资源(将空闲资源分配给重要的服务,扩大部署规模)。

9、安全

主要从下面几点考虑

  • 通过密码手机校验码进行身份验证;
  • 登录,交易等操作对网络通信进行加密;
  • 防止机器人程序滥用网络资源攻击网站,使用验证码进行识别;
  • 对常见的XSS攻击、SQL注入进行编码转换等处理;
  • 对垃圾信息。敏感信息进行过滤;
  • 对交易转账等重要操作根据交易模式和交易信息进行风险控制;

10、总结

原文地址:https://www.cnblogs.com/arvins/p/8608611.html

时间: 2024-10-06 08:30:55

大型网站架构之架构模式的相关文章

云计算视频教程:Linux大型网站高并发架构及自动化运维

随着互联网技术的不断进步和发展,对运维人员提出了更高的要求和挑战,如何才能将运维工作自动化,提升工作的效率?让大家学完后可以具备企业真正的大型网站搭建能力以及自动化运维的实战能力.在企业中运用zabbix监控企业数据,第一时间了解服务的运行状态,通过nginx+lvs+keeplived在企业中根据公司业务做七层负载以及四层负载. 下面给大家分享一下Linux大型网站高并发架构及自动化运维的学习内容: 01-初识ansible 02-ansible-Ad-Hoc-重点模块学习 03-ansibl

Mysql在大型网站的应用架构演变

原创文章,转载请注明: 转载自http://www.cnblogs.com/Creator/本文链接地址: Mysql在大型网站的应用架构演变 写在最前: 本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变 可扩展性 架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍一下,常用的扩展手段有以下两种Scale-up :  纵向扩展,通过替换为更好的机器和资源来实现伸缩,提升服务能力Scale-out : 横向扩展,  通过加节

Mysql在大型网站的应用架构演变(转)

原文: Mysql在大型网站的应用架构演变 本文已经被多处转载,包括CSDN推荐以及码农周刊等等,阅读数超过5w+,回流到我博客流量的还是比较少,不过这不重要, 后续会分享更多技术,尽量试图把自己理解的东西描述出来(很多时候自己的理解是90分,可是描述出来就只有60分了) CSDN的转载 :http://www.csdn.net/article/2014-06-10/2820160 伯乐在线的转载: http://blog.jobbole.com/70844/ 当然还有大量转载没有写明出处的..

大型网站图片服务器架构的演进(转)

在主流的Web站点中,图片往往是不可或缺的页面元素,尤其在大型网站中,几乎都将面临“海量图片资源”的存储.访问等相关技术问题.在针对图片服务器的架构扩展中,也会历经很多曲折甚至是血泪教训(尤其是早期规划不足,造成后期架构上很难兼容和扩展). 本文将以一个真实垂直门户网站的发展历程,向大家娓娓道来. 构建在Windows平台之上的网站,往往会被业内众多技术认为很“保守”,甚至会有点.很大部分原因,是由于微软技术体系的封闭和部分技术人员的短视造成的(当然,主要还是人的问题).由于长期缺乏开源支持,所

大型网站图片服务器架构的演进

在主流的Web站点中,图片往往是不可或缺的页面元素,尤其在大型网站中,几乎都将面临“海量图片资源”的存储.访问等相关技术问题.在针对图片服务器的架构扩展中,也会历经很多曲折甚至是血泪教训(尤其是早期规划不足,造成后期架构上很难兼容和扩展). 本文将以一个真实垂直门户网站的发展历程,向大家娓娓道来. 构建在Windows平台之上的网站,往往会被业内众多技术认为很“保守”,甚至会有点.很大部分原因,是由于微软技术体系的封闭和部分技术人员的短视造成的(当然,主要还是人的问题).由于长期缺乏开源支持,所

大型网站--负载均衡架构

负载均衡 (Load Balancing) 负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽.增加吞吐量.加强网络数据处理能力.提高网络的灵活性和可用性. 大型网站负载均衡的利器 全局负载均衡系统(GSLB) 内容缓存系统(CDN) 服务器负载均衡系统(SLB) DNS域名解析的基本过程 最初的负载均衡解决方案(DNS轮询) 优点 基本上无成本,因为往往域名注册商的这种解析都是免费的: 部署方便,除了网络拓扑的简单扩增,新增的Web服务器只要增加一个公网I

一个大型网站图片服务器架构的演进

本文将以一个真实垂直门户网站的发展历程,向大家娓娓道来. 构建在Windows平台之上的网站,往往会被业内众多技术认为很"保守",甚至会有点.很大部分原因,是由于微软技术体系的封闭和部分技术人员的短视造成的(当然,主要还是人的问题).由于长期缺乏开源支持,所以很多人只能"闭门造车",这样很容易形成思维局限性和短板.以图片服务器为例子,如果前期没有容量规划和可扩展的设计,那么随着图片文件的不断增多和访问量的上升,由于在性能.容错/容灾.扩展性等方面的设计不足,后续将会

转:大型网站图片服务器架构的演进

在主流的Web站点中,图片往往是不可或缺的页面元素,尤其在大型网站中,几乎都将面临"海量图片资源"的存储.访问等相关技术问题.在针对图片服务器的架构扩展中,也会历经很多曲折甚至是血泪教训(尤其是早期规划不足,造成后期架构上很难兼容和扩展). 本文将以一个真实垂直门户网站的发展历程,向大家娓娓道来. 构建在Windows平台之上的网站,往往会被业内众多技术认为很"保守",甚至会有点.很大部分原因,是由于微软技术体系的封闭和部分技术人员的 短视造成的(当然,主要还是人的

谈谈用ASP.NET开发的大型网站有哪些架构方式(成本)

在上篇文章里(http://www.cnblogs.com/ms0017/archive/2011/07/26/2117676.html),列举了国内外用ASP.NET开发的大型网站有哪些.最后提到了用.NET开发的大型网站和LAMP/JAVA平台的成本比较.其实在很多时候,收费的不一定就比免费的成本更高.因为开发一个网站要使用哪个平台的技术更合适,需要考虑很多种情况(除了开发技术本身,还要考虑人工,开发效率,时间,后续的支持,维护等等),要综合计算成本才行.微软平台本身虽然是收费的,但总体的成

大型网站IT技术架构

1.Varnish 反向代理服务器(外网client向内网server请求资源) 模式: 代理缓存,外网client在varnish找不到请求的资源,varnish会向上游的apache请求资源,然后传给client,并同时缓存该资源: 旁路缓存,外网client在varnish找不到请求的资源,varnish将client的请求路由到上游的apache,client取得资源后将该资源返回给varnish: 最近公司做活动推广,流量暴增,后端服务器压力山大,导致用户的请求响应时间延长,客户因此抱