大型站点技术架构(二)--架构模式

大型站点技术架构(一)--大型站点架构演化

每个模式描写叙述了一个在我们周围不断反复发生的问题及该问题解决方式的核心。

这样,你就能一次重新地使用该方案而不必做反复工作。

所谓站点架构模式即为了解决大型站点面临的高并发訪问、海量数据、高可靠执行灯一系列问题与挑战。为此。在实践中提出了很多解决方式,以实现站点高性能、高可靠性、易伸缩、可扩展、安全等各种技术架构目标。

1、分层

分词是企业应用系统中最常见的一种架构牧师,将系统在横向维度上切分成几个部分,每一个部分负责一部分相对简单并比較单一的职责,然后通过上层对下层的依赖和调度组成一个完整的系统。

在站点的分层架构中。常见的为3层。即应用层、服务层、数据层。

应用层详细负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储訪问服务。如数据库、缓存、文件、搜索引擎等。

分层架构是逻辑上的,在物理部署上。三层架构能够部署在同一个物理机器上。可是随着站点业务的发展,必定须要对已经分层的模块分离部署,即三层结构分别部署在不同的server上,是站点拥有很多其它的计算资源以应对越来越多的用户訪问。

      所以尽管分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护,但在站点的发展过程中。分层结构对站点支持高并发向分布式方向的发展至关重要

2、分隔

假设说分层是将软件在横向方面进行切分,那么分隔就是在纵向方面对软件进行切分。

站点越大,功能越复杂,服务和数据处理的种类也越多,将这些不同的功能和服务分隔开来。包装成高内聚低耦合的模块单元,不仅有助于软件的开发维护也便于不同模块的分布式部署,提高站点的并发处理能力和功能扩展能力。

大型站点分隔的粒度可能会非常小。比方在应用层,将不同业务进行分隔,比如将购物、论坛、搜索、广告分隔成不同的应用,有对立的团队负责。部署在不同的server上。

3、分布式

对于大型站点。分层和分隔的一个主要目的是为了切分后的模块便于分布式部署。即将不同模块部署在不同的server上。通过远程调用协同工作。分布式意味着可以使用很多其它的计算机完相同的工作,计算机越多,CPU、内存、存储资源就越多,能过处理的并发訪问和数据量就越大,进而可以为很多其它的用户提供服务。

在站点应用中,经常使用的分布式方案有一下几种.

分布式应用和服务:将分层和分隔后的应用和服务模块分布式部署,能够改善站点性能和并发性、加快开发和公布速度、降低数据库连接资源消耗。

分布式静态资源:站点的静态资源如JS、CSS、Logo图片等资源对立分布式部署,并採用独立的域名。即人们常说的动静分离。静态资源分布式部署能够减轻应用server的负载压力。通过使用独立域名加快浏览器并发载入的速度。

分布式数据和存储:大型站点须要处理以P为单位的海量数据。单台计算机无法提供如此大的存储空间,这些数据库须要分布式存储。

分布式计算:眼下站点普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算,其特点是移动计算而不是移动数据,将计算程序分发到数据所在的位置以加速计算和分布式计算。

4、集群

对于用户訪问集中的模块须要将独立部署的server集群化,即多台server部署同样的应用构成一个集群,通过负载均衡设备共同对外提供服务。

server集群能够为同样的服务提供很多其它的并发支持。因此当有很多其它的用户訪问时,仅仅须要向集群中增加新的机器就可以;另外能够实现当当中的某台server发生问题时,能够通过负载均衡的失效转移机制将请求转移至集群中其它的server上。因此能够提高系统的可用性

5、缓存

缓存目的就是减轻server的计算,使数据直接返回给用户。

在如今的软件设计中,缓存已经无处不在。详细实现有CDN、反向代理、本地缓存、分布式缓存等。

使用缓存有两个条件:訪问数据热点不均衡,即某些频繁訪问的数据须要放在缓存中。数据在某个时间段内有效,只是非常快过期,否在会由于数据过期而脏读。影响数据的正确性。

6、异步

使用异步。业务之间的消息传递不是同步调用,而是将一个业务操作分成多个阶段,每一个阶段之间通过共享数据的方法异步运行进行协作。

详细实现则在单一server内部可用通过多线程共享内存对了的方式处理;在分布式系统中可用通过分布式消息队列来实现异步。

异步架构的典型就是生产者消费者方式,两者不存在直接调用。

7、冗余

站点须要7×24小时连续执行,那么就得有对应的冗余机制,以防某台机器宕掉时无法訪问,而冗余则能够通过部署至少两台server构成一个集群实现服务高可用。

数据库除了定期备份还须要实现冷热备份。甚至能够在全球范围内部署灾备数据中心。

8、自己主动化

详细有自己主动化公布过程。自己主动化代码管理、自己主动化測试、自己主动化安全检測、自己主动化部署、自己主动化监控、自己主动化报警、自己主动化失效转移、自己主动化失效恢复等。

9、安全

站点在安全架构方面有很多模式:通过password和手机校验码进行身份认证。登录、交易须要对网络通信进行加密;为了防止机器人程序滥用资源,须要使用验证码进行识别;对常见的XSS攻击、SQL注入须要编码转换。垃圾信息须要过滤等。

时间: 2024-11-05 13:43:17

大型站点技术架构(二)--架构模式的相关文章

大型站点技术架构(六)--站点的伸缩性架构

大型站点技术架构(一)--大型站点架构演化 大型站点技术架构(二)--架构模式 大型站点技术架构(三)--架构核心要素 大型站点技术架构(四)--站点的高性能架构 大型站点技术架构(五)--站点高可用架构 站点系统的伸缩性架构最重要的技术手段就是使用server集群功能.通过不断地向集群中加入server来增强整个集群的处理能力. "伸"即站点的规模和server的规模总是在不断扩大. 1.站点架构的伸缩性设计 站点的伸缩性设计能够分成两类,一类是依据功能进行物理分离实现伸缩.一类是单

大型站点技术架构(七)--站点的可扩展性架构

大型站点技术架构(一)--大型站点架构演化 大型站点技术架构(二)--架构模式 大型站点技术架构(三)--架构核心要素 大型站点技术架构(四)--站点的高性能架构 大型站点技术架构(五)--站点高可用架构 大型站点技术架构(六)--站点的伸缩性架构 扩展性是指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力. 设计站点可扩展架构的核心思想是模块化,并在此基础上,减少模块间的耦合性,提供模块的复用性.模块通过分布式部署,独立的模块部署在独立的server上(集群)从物理上分离模块之间的耦

大型站点技术架构(八)--站点的安全架构

大型站点技术架构(一)--大型站点架构演化 大型站点技术架构(二)--架构模式 大型站点技术架构(三)--架构核心要素 大型站点技术架构(四)--站点的高性能架构 大型站点技术架构(五)--站点高可用架构 大型站点技术架构(六)--站点的伸缩性架构 大型站点技术架构(七)--站点的可扩展性架构 从互联网诞生起,安全威胁就一直伴随着站点的发展,各种Web攻击和信息泄露也从未停止.常见的攻击手段有XSS攻击.SQL注入.CSRF.Session劫持等. 1.XSS攻击 XSS攻击即跨网站脚本攻击(C

《大型站点技术架构》1:概述

參考自<大型站点技术架构>第1~3章 1.大型站点架构演化发展历程 (1)初始阶段的站点架构:一台server分别作为应用.数据.文件server (2)应用服务和数据服务分离:三台server分别承担上述三项工作,当中应用server要求CPU强大.数据库server需求更快的硬盘和内存,文件server须要较大的硬盘. (3)使用缓存改善站点性能:分为本地缓存以及缓存在专门的分布式server上的远程缓存. (4)使用应用server集群改善站点的并发处理能力. (5)数据库读写分离. (

大型站点技术架构阅读笔记(二)

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 原文地址:https://www.cnblogs.com/llguanli/p/8653205.html

大型站点技术架构PDF阅读笔记(一):

1.数据库读写分离: 2.系统吞吐量和系统并发数以及系统响应时间之间的关系: 3.系统负载的概念: 4.反向代理的概念: 5.使用缓存来读取数据: 6.利用cookie来记录session: 利用cookie记录session的缺点: 7.站点应用公布流程: 8.使用消息队列 9.异步调用: 10.应用的无状态性: 11.CDN的概念: 利用CDN的站点架构: 12.Hash表是怎样存储的: 13.memcache缓存:

关于大型站点技术演进的思考(四)--存储的瓶颈(4)

假设数据库须要进行水平拆分,这事实上是一件非常开心的事情,由于它代表公司的业务正在迅猛的增长,对于开发者而言那就是有不尽的项目能够做,尽管会感觉非常忙.可是人过的充实,心里也踏实. 数据库水平拆分简单说来就是先将原数据库里的一张表在做垂直拆分出来放置在单独的数据库和单独的表里后更进一步的把本来是一个总体的表进一步拆分成多张表,每一张表都用独立的数据库进行存储.当表被水平拆分后,原数据表成为了一个逻辑的概念,而这个逻辑表的业务含义须要多张物理表协同完毕.因此数据库的表被水平拆分后.那么我们对这张表

关于大型站点技术演进的思考(七)--存储的瓶颈(7)

本文开篇提个问题给大家,关系数据库的瓶颈有哪些?我想有些朋友看到这个问题肯定会说出自己平时开发中碰到了一个跟数据库有关的什么什么问题,然后怎样解决的等等.这种答案没问题,可是却没有代表性.假设出现了一个新的存储瓶颈问题,你在那个场景的处理经验能够套用在这个新问题上吗?这个真的非常难说. 事实上无论什么样的问题场景最后解决它都要落实到数据库的话.那么这个问题场景一定是击中了数据库的某个痛点,那么我前面的六篇文章里那些手段究竟是在解决数据库的那些痛点,以下我总结下,详细例如以下: 痛点一:数据库的连

大型站点高并发架构技术

高并发: 高并发主要是由于网站PV访问量大,单台服务器涌承载大量访问所带来的压力,所以会采用多台服务器进行分流,采用服务器集群技术,对于每个访问会被 发送到哪台服务器,我们采取负载均衡策略,常见的技术有LVS,由于网站中有大量的静态页面,所以采用缓存服务器和反向代理技术,包括HAPROXY,Redis,数据库可以采用数据库集群,进行读写分离,缓解数据库压力. 大型站点高并发架构就是利用负载均衡技术.反向代理技术.数据库集群.web服务器集群.Nosql技术等,以实现单台数据器不能达到的并发量,换