《大型网站技术架构》读书笔记

学习笔记 yan loading.. 0评论 已收录

 

大型网站特点:

  1. 高并发,大流量
  2. 高可用
  3. 海量数据
  4. 用户分布广泛,网络情况复杂
  5. 安全环境恶劣
  6. 需求快速变更、发布频繁
  7. 渐进式发展

大型网站的发展过程:

1、集多种功能于一体(小型网站)

只有一台服务器,所有功能都部署在一台服务器上。应用程序、文件和数据库等文件都在一台服务器上。通常是利用Linux系统,部署Apache环境,使用PHP开发,同时数据库使用Mysql,即可打造一台小型的服务器。

2、应用和数据分离

分离成应用服务器、文件服务器和数据库服务器三台服务器。不同功能的服务器对硬件设施有不同的需求。应用服务器需要处理大量的业务逻辑,因此需要更强大的CPU;文件服务器需要存储更多的内容,因此需要更大的硬盘;数据库服务器需要快速的检索磁盘和数据缓存,因此需要更大的内存和更快的磁盘。

3、利用缓存提高性能

80%的业务访问集中在20%的数据上

把一小部分常用的数据缓存起来,从而提高网站的访问速度和性能。缓存一般分为:本地缓存远程分布式缓存(集群)

4、使用集群提高并发性

通过负载均衡调度服务器,可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上,使应用服务器的负载压力不再成为整个网站的瓶颈。

只要能通过增加一台服务器的方式改善负载压力,就可以以同样的方式持续增加服务器来不断改善系统性能,实现可伸缩性。

5、数据库的读写分离

通过配置两台数据库的主从关系,可以将一台数据库服务器的数据更新同步到另一台服务器上。利用该功能可以实现数据库的读写分离。

主服务器写操作,从服务器读操作

6、使用反向代理和cdn

7、使用分布式文件系统和数据库

8、使用NoSQL和搜索引擎

9、业务拆分

10、分布式系统

网站架构设计误区

用技术解决一切。对于高并发的问题,不一定非要技术手段解决,业务手段也可以优化。比如12306,将零点放票改成分时分段售票

网站构架模式

1、分层(横向)、分割(纵向)

2、分布式

  1. 分布式应用和服务
  2. 分布式静态资源
  3. 分布式数据和存储
  4. 分布式计算

3、集群化

4、缓存

  1. CDN
  2. 反向代理
  3. 本地缓存
  4. 分布式缓存

5、异步

降低软件耦合性

6、冗余

7、自动化

8、安全

系统解耦合的方法:分层、分割、分布、异步等

好的模式绝对不是模仿,不是生搬硬套某个模式,而是对问题深刻理解之上的创造与创新,即使是“微创新”,也是让人耳目一新的似曾相识。山寨与创新的最大区别不在于是否抄袭,是否模板,而在于对问题和需求是否真正理解与把握。

集群和分布式的区别:

集群,多台服务器部署相同应用构成一个集群,通过负载均衡对外提供服务。(缓解单一服务器处理同一事务的压力)
分布式:把应用进行分层、分割后的模块独立部署,一个应用拆分成多个模块,由一台服务器拆分成多台服务器。(缓解一台服务器处理过多事务)

集群:很多机器做同样的事情(类似于副本),分流的效果。(提高可用性,提高并发性,分流)。同一个业务,部署在多个服务器上
分布式:很多机器做不同的事情,共同协作完成一个目的。一个业务分拆多个子业务,部署在不同的服务器上

 大型网站核心要素

  1. 性能
  2. 可用性
  3. 伸缩性
  4. 扩展性
  5. 安全性

瞬时响应:网站的高性能构架

1、网站的性能测试

  • a) 用户角度的性能:直观上的快慢(通信时间、处理时间、请求解析响应数据时间)
  • b)开发角度的性能:程序本身问题(响应延迟、系统吞吐量、并发能力、稳定性、缓存、集群、异步、代码)
  • c)运维角度的性能:基础设施性能(带宽、硬件配置、数据中心网络架构、资源利用率)

1.1、性能测试的指标

  • a)响应时间
  • b)并发数
  • c)吞吐量(TPS、HPS、QPS)
  • d)性能计数器(性能数据指标)

1.2、性能测试的方法

  • a)性能测试
  • b)负载测试
  • c)压力测试
  • d)稳定性测试

随着压力的增加,依次进行:性能测试(0~预期目标点)、负载测试(预期目标点~最大负载点)、压力测试(最大负载点~系统崩溃点)。一般情况下,日常下系统运行在0~预期目标点范围内;当因为突发事件超出日常访问压力的情况下,保证系统正常运行在能够承受的最大负载点之内;当压力继续增大,达到系统崩溃点后,则可能导致系统崩溃。

1.3、性能优化策略

Web前端性能优化、应用服务器性能优化、存储服务器性能优化

2、Web前端性能优化

2.1、浏览器访问优化

  • a)减少HTTP请求,合并CSS、JS、图片
  • b)使用浏览器缓存
  • c)启用压缩
  • d)css放在页眉,js放在页脚
  • e)减少cookie传输

2.2、CDN加速

2.3、反向代理

3、应用服务器性能优化

网站性能优化第一定律:优先考虑使用缓存优化性能。
二八定律,80%的访问落在20%的数据上

3.1、分布式缓存

  • a)合理使用缓存:不要缓存频繁修改的数据,**要缓存读写比大于2:1的,频繁读取的数据。**对于不一致数据的处理,缓存可用性、缓存预热、缓存穿透
  • b)分布式缓存框架:JBoss Cache分布式缓存,同步更新,受限于一台服务器的内存大小,当集群过大时,同步的开销很大;Memcached,缓存部署在一组专门的服务器上,通过Hash等路由算法选择服务器进行访问缓存数据,服务器之间不通信,有良好的可伸缩性。

3.2、异步操作

3.3、使用集群

3.4、代码优化

  • a)多线程:无状态对象(本身不存储状态信息,如Servlet)、使用局部对象、使用锁控制并发
  • b)资源复用
  • c)数据结构
  • d)垃圾回收

4、存储性能优化

4.1、固态硬盘SSD代替机械硬盘

4.2、LSM树代替B+树

4.3、HDFS代替RAID

万无一失:网站的高可用性框架

1、网站可用性的度量和考核

1.1、可用性的度量

网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点

网站年度可用性能指标=(1-网站不可用时间/年度总时间)*100%

2个9(99%)是基本可用,3个9是较高可用,4个9是自动恢复能力的高可用(QQ就是99.99%),5个9是极高可用

1.2 可用性的考核

2、高可用性的网站构架

主要目的是保证服务器估计故障时服务依然可用,数据依然保存并能被访问。

主要手段是数据和服务的冗余备份及失效转移

典型的分层模型:应用层(具体业务逻辑处理)、服务层(可复用的服务)和数据层(数据的存储和访问)。应用层的服务器通常为了对应高并发的访问请求,通过负载均衡将一组服务器组成一个集群共同对外提供服务,当发现某台服务器不可用时,就将其剔除集群,将请求分发到其他可用的服务器上;服务层与应用层类似,通过分布式服务框架被应用层调用,分布式服务框架会在应用层客户端程序中实现软件负载均衡,并通过服务注册中心对提供服务的服务器进行心跳检测(如HSF);数据层存储数据,数据写入时进行同步复制到多台备份服务器上,实现数据冗余备份。

3、高可用性的应用

无状态性:应用服务器不保存上下文信息,仅根据每次请求提交的数据进行相应的业务逻辑处理,多个服务实例(服务器)之间完全对等,请求提交到任意服务器处理结果是完全一样的。

3.1 通过负载均衡进行无状态服务的失效转移

3.2 集群的session管理

如何实现无状态应用呢?大部分网站需要存储用户的信息,因此需要将session和应用服务器脱离,产生集群session

  • 1. Session复制。开启应用服务器Web容器的session复制功能,集群中的服务器相互同步session,使得每台应用服务器都保存所有的用户session信息,应用只需访问本地的session即可。(**不需要额外的服务器,同一IP请求随机服务器处理**)
  • 2. session绑定。负载均衡器根据原地址hash算法(或cookie信息),将同一IP的请求始终分发到同一台服务器上。(**不需要额外的服务器,同一IP请求始终同一台服务器处理**)
  • 3. 利用cookie记录session。缺点:受cookie大小限制,影响性能,关闭cookie影响使用。(**不需要额外的服务器,同一IP请求随机服务器处理**)
  • 4. session服务器(集群)。建立Session服务器(集群)进行统一的管理。

4、高可用的服务

可用复用的服务和应用一样,是无状态的服务,因此可用使用类似负载均衡的策略进行失效转移。

  1. 负载均衡(同应用)
  2. 分级管理(根据服务的优先级(重要性),进行不同等级的管理)
  3. 超时设置,避免因为没有响应而造成的长时间的等待
  4. 异步调用
  5. 服务降级,在高峰期时,对非必要的服务进行降级,以保证主要业务的可用性
  6. 幂等性设计,用来避免服务因为网络等因素重复提交造成的影响

5、高可用的数据

数据不同于应用,每台服务器数据不同,当一台服务器宕机后,任意的切换会出现问题。主要的手段是数据备份(冗余)和失效转移机制。

6、高可用的缓存

目前对于缓存的争议比较大,一部分人认为:缓存已经成为了网站数据服务的重要组成部分,为数据库分担了大量的压力,若缓存宕机可能会因为数据库的压力突然增加而造成无法设想的后果;另一部分人认为:缓存的初衷就是为了缓解数据库压力而产生的非持久性的、临时性的存储服务,若进行持久性保存反而会与其初衷产生矛盾。

但是笔者赞同后一观点,可以利用分布式缓存代替单机缓存,若分布式缓存中一台机器宕机,对整体的缓存影响微乎其微。

6.1、CAP原理

C:数据一致性(多副本下,副本不一致)所有应用程序访问都能得到一致的数据。
A:数据可访问性(出现故障后,可以快速的切换)任何时候,任何应用都可以读写访问。
P:分区耐受性/数据持久性(备份容灾)数据可以跨网络分区线性伸缩。

CAP原理认为无法同时满足三项条件,只能满足两个而舍弃一个。一般情况下,数据较大,要保证P伸缩性和高可用性A,从而放弃部分的一致性C。

6.2、数据备份

冷备和热备(同步热备和异步热备),通常关系型数据库的热备机制Master-Slave同步机制,主写从读,实现读写分离。

6.3、失效转移

当服务器中一台机器宕机后,会对这台服务器的所有读写操作进行转移路由到其他服务器上。主要由失效确认、访问转移、数据恢复三部分组成。

7、高可用网站的软件质量保证

  1. 集群中的网站分批发布
  2. 自动化测试
  3. 预发布验证
  4. 代码控制(svn、git)
  5. 自动化发布
  6. 灰度发布(每天只发布一部分机器,新老版本相互保留)

8、网站运行监控

8.1、监控数据采集

  1. 用户行为日志收集:服务器端日志收集和客户端浏览器日志收集
  2. 服务器性能监控
  3. 运行数据报告

8.2、监控管理

系统报警(设置阈值)、失效转移、自动降级

永无止境:网站的伸缩性

1、网站架构的伸缩性设计

1.1、不同功能,物理分离实现伸缩

单一服务器 -> 应用、逻辑、数据分离 -> 缓存分离 -> 静态文件分离。总体分为纵向分离(分层后分离)和横向分离(业务分割后分离)

1.2、相同功能,利用集群进行伸缩

2、应用服务器集群的伸缩性设计(负载均衡服务器(这里只考虑web应用)也可以成为HTTP请求分发器)

  1. HTTP重定向负载均衡,负载均衡服务器返回302状态码,**缺点:让客户端请求两次**。
  2. DNS域名解析负载均衡,域名DNS解析时进行负载均衡算法,返回均衡后的IP。**缺点:DNS每一级会有缓存**。
  3. 反向代理负载均衡,通过反向代理服务器转发所有请求到内部集群。**缺点:所有请求都经过反向代理服务器,其性能会成为瓶颈**。
  4. IP负载均衡,类似于反向代理方式,只是进行IP映射,在网络层完成,性能较好于反向代理。缺点同上。
  5. 数据链路层负载均衡,类似于IP负载均衡,但是只修改mac地址不修改IP。真实物理服务器处理后直接返回给客户端,三角传输模式。**在数据链路层完成,同时数据返回不经过负载均衡服务器,减少受其带宽的影响,目前大型网站使用最广的一种手段,LInux上最好的链路层负载均衡开源产品是LVS(Linux Virtual Server)**。
  6. 负载均衡算法,轮询、加权轮询、随机、最少连接、源地址散列

3、分布式缓存集群的伸缩性设计

缓存集群不同于别的集群,每台服务器上存储的内容都不相同,在增加服务器时,需要对原先集群影响较小,即原先可以访问的数据依旧可以访问。

分布式缓存的一致性hash算法(带有虚拟节点的hash环)

4、数据存储服务器集群的伸缩性设计

数据存储相比较缓存服务器而言,对数据的持久性和可用性提出来更高的要求。

4.1、关系型数据库集群的伸缩性设计

分库分表、主从读写分离

4.2 NoSQL数据库的伸缩性设计

随需应变:网站的可扩展性架构

在对现有系统影响最小的情况下,系统功能可持续扩展及提升的能力。系统架构设计层面的开闭原则(对扩展开放,对修改关闭)

1、分布式消息队列

2、分布式服务

3、可扩展的数据结构,(NoSQL数据库的ColumnFamily列族设计,无需指定字段)

4、利用开放平台建设网站生态圈

固若金汤:网站的安全架构

1、XSS攻击(跨站点脚本攻击)
解决办法:消毒(字符转义)、HttpOnly

2、注入攻击(sql注入和os注入)
解决办法:消毒(字符转义)、参数绑定(用变量的形式书写sql)

3、CSRF攻击(跨站点请求伪造)
解决办法:表单Token、验证码、Referer check

4、信息加密技术及密钥安全管理

  • 单向散列加密
  • 对称加密
  • 非对称加密

关注<爱上极客>公众号,定期推送精彩内容!

喜欢 (0)

如未说明则本站原创,转载请注明出处:爱上极客 » 《大型网站技术架构》读书笔记


0
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址