《大型网站技术架构:核心原理与案例分析》笔记

第一章:大型网站架构演化

1,大型网站软件系统特点:

1)        高并发、大流量

2)        高可用

3)        海量数据

4)        用户分布广泛、网络情况复杂

5)        安全环境恶劣

6)        需求快速变更,发布频繁

7)        渐进式发展

2,大型网站架构演化发展:

1)        初期阶段

2)        应用服务和数据服务分离

3)        使用缓存改善网站性能

4)        使用应用服务器集群改善网站的并发处理能力

5)        数据库读写分离

6)        使用反向代理和CDN加速网站响应

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

8)        使用NoSQL和搜索引擎

9)        业务拆分

10)    分布式服务

第二章:大型网站架构模式

1,网站架构模式

1)        分层:企业应用系统中最常见的一种架构模式,将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统。

2)        分割:在纵向方面对软件进行切分。将不同的功能和服务分割开来,包装成高内聚低耦合的模块单元有助于软件的开发和维护,并且便于不同模块的分布式部署,提高网站的并发处理能力和功能扩展能力。

3)        分布式:将通过分层和分割后的不同模块部署在不同的服务器上,通过远程调用协同工作。

分布式遇到的问题:

A.       服务调用必须通过网络,对性能造成比较严重的影响

B.       服务器越多,服务器宕机的概率越大

C.       保持数据一致性困难

D.       导致网站依赖错综复杂,开发管理维护困难


常见的分布式方案:

A.       分布式应用和服务

B.       分布式静态资源

C.       分布式数据和存储

D.       分布式计算

E.        其他(分布式配置、分布式锁、分布式文件系统)

4)        集群:多台服务器部署相同应用构成一个集群,通过负载均衡设备共同对外提供服务。

5)        缓存:将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段。

常见缓存:

A.       CDN(内容分发网络)部署在距离终端用户最近的网络服务商

B.       反向代理:网站前端架构的一部分,部署在网站的前端,缓存网站的静态资源

C.       本地缓存:在应用服务器本地缓存存放热点数据

D.       分布式缓存:将数据缓存在一个专门的分布式缓存集群中。

6)        异步:将一个业务操作分成多个阶段,每个阶段之间通过共享数据的方式异步执行进行协作。在单一服务器内部可以通过多线程贡献内存队列的方式实现异步;分布式系统中,多个服务器集群通过分布式消息队列实现异步。

异步消息队列的特性:

A.       提高系统可用性

B.       加快网站响应速度

C.       消除并发访问高峰

7)        冗余:一定程度的服务器冗余运行、数据冗余备份,可以在某台服务器宕机时将其上的服务和数据转移到其他机器上,实现服务高可用。

8)        自动化:通过减少人为干预,是使发布过程自动化可有效减少故障。包括自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化是小转移、自动化失效恢复、自动化降级、自动化分配资源等

9)        安全:身份验证、加密、验证码、攻击处理、信息过滤、风险控制等

第三章:大型网站核心架构要素

1)        性能     

2)        可用性:目标是当服务器宕机的时候服务或者应用依然可用

3)        伸缩性:通过不断向集群中增加服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储要求,主要目标是可以用多台服务器构建集群,并容易向集群中添加新的服务器,加入新的服务器后可以提供和原来的服务器无差别的服务,集群中可容纳的总的服务器数量无限制。

4)        扩展性:网站的架构使其能够快速相应需求变化。手段:事件驱动架构和分布式服务。

5)        安全性

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

1,性能测试指标

1)        响应时间

2)        并发数

3)        吞吐量

4)        性能计数器

2,性能测试方法

1)        性能测试

2)        负载测试

3)        压力测试

4)        稳定性测试

3,Web前端性能优化

1)        浏览器访问优化

A.       减少http请求:合并CSS,合并JavaScript、合并图片。

B.       使用浏览器缓存:将CSS、JavaScript、图标等静态文件缓存在浏览器中。更新静态资源时,采用批量更新的方法。

C.       启用压缩:在服务器端对文件进行压缩,在浏览器端对文件解压缩。

D.       CSS放在页面最上面,JavaScript放在页面最下面

E.        减少Cookie传输

2)        CDN加速

3)        反向代理

4,应用服务器性能优化

1)        分布式缓存(memcached)

2)        异步操作(使用消息队列)

用户请求的数据发给消息队列后立刻返回,再由消息队列的消费者进程从消息队列中获取数据,异步写入数据库。消息队列有削峰作用,通过异步处理,将段时间高并发产生的消息存储在消息队列中,从而削平高峰期的并发事物。

3)        使用集群:使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群,并将并发访问请求分发到多台服务器上处理。

4)        代码优化

a)        多线程

b)        资源复用

c)        良好的数据结构

d)        垃圾回收

5,存储性能优化

1)        机械VS固态

2)        B+树VS LSM树

3)        RAID VS HDFS

第五章:万无一失:网站的高可用架构

1,应用层的高可用

         应用层主要处理网站应用的业务逻辑,显著特点是应用的无状态性。对于应用服务器集群,实现这种服务器可用状态实时监测、自动转移失败任务的机制是负载平衡。

         负载平衡主要是用在业务量和数据量较高的情况下,当单台服务器不足以承担所有压力时通过负载均衡将流量分摊到一个集群组成的多台服务器上,以提高整体的负载处理能力。

         Session管理:

1)        Session复制:在几台服务器之间同步session对象,使得每台服务器上都保存所有用户的session信息。

2)        Session绑定:负载均衡的源地址hash算法。负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。又称作会话黏滞。

3)        利用cookie记录session:将session记录在客户端

4)        Session服务器:利用独立不熟的session服务器(集群)统一管理session。

2,服务层的高可用

1)        分级管理:将服务器进行分级管理,核心应用和服务优先使用更好的硬件。

2)        超时设置:在应用程序中设置服务超时时间。

3)        异步调用:应用对服务的调用通过消息队列等异步方式完成,避免一个服务失败导致整个应用请求失败的情况。

4)        服务降级:通过拒绝服务(拒绝低优先级应用的调用,减少服务调用并发数,或者随机拒绝部分请求调用)和关闭功能(关闭部分不重要的服务)

5)        幂等性设计:在服务层保证服务重复调用和调用一次产生的结果相同。

3,数据层的高可用

         保证数据存储高可用的主要手段是数据备份和失效转移机制。数据备份是保证数据有多个副本,任意副本都不会导致数据的永久丢失,从而实现数据的持久化;而失效转移机制则保证当一个数据副本不可访问时,可以快速切换访问数据的其他副本,保证系统可用。

         CAP原理:一个提供数据服务的存储系统无法同时满足数据一致性、数据可用性、分区耐受性这三个条件。

         数据备份:

1)        冷备份:简单廉价/不能保证数据最终一致和数据可用性。

2)        热备份:异步热备份/同步热备份。异步方式试制多份数据副本的写入操作异步完成,应用程序收到数据服务系统的写操作成功响应时只写成功了一份,存储系统会异步的写其他副本。同步方式是指多分数据副本的写入操作同步完成,即应用程序收到数据服务系统的写成功响应时,多分数据都已经写操作成功。

失效转移:

1)        失效确认:心跳检测和应用程序访问失败报告

2)        访问转移:对于完全对等存储的服务器,其中一台宕机后切换到对等服务器上;若是不对等的,就需要重新计算路由选择存储服务器

3)        数据恢复:系统需要从间看的服务器复制数据将数据副本数目恢复到设定值

4,高可用的软件质量保证

1)        网站发布

2)        自动化检测

3)        预发布验证

4)        代码控制

5)        自动化发布

6)        灰度发布

5,网站运行监控

第六章:永无止境:网站的伸缩性架构

1,架构的伸缩性设计

1)        不同功能进行物理分离:通过增加服务器、将部分功能和服务分离到新增服务器。

         纵向分离:将业务处理流程上的不同部分分离部署,实现系统伸缩性。

         横向分离:将不同的业务模块分离部署,实现系统伸缩性

2)        单一功能通过集群实现伸缩:将相同服务部署在多台服务器上构成一个集群整体对外提供服务。

2,应用服务器集群的伸缩性设计

1)        HTTP重定向负载均衡

HTTP重定向服务器是一台普通的应用服务器,其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址,并将该Web服务器地址写入HTTP重定向响应中返回给用户浏览器。

2)        DNS域名解析负载均衡

每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回,这样A记录中配置的多个服务器就构成一个集群,并可以实现负载均衡。

3)        反向代理负载均衡

反向代理服务器不仅缓存资源,同时提供负载均衡的功能,管理一组WEB服务器,将请求根据负载均衡算法转发到不同WEB服务器上,WEB服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于方向代理服务器转发请求在HTTP协议层面,一次也叫做应用层负载均衡。

4)        IP负载均衡

在网络层通过修改请求目标地址进行负载均衡。其在内核进程完成数据分发,较反向代理负载均衡(在应用程序中分发数据)有更好的处理性能,但受限于负载均衡服务器的网卡贷款。

5)        数据链路层负载均衡

在通信协议的数据链路层修改mac地址进行负载均衡,又叫做三角传输模式。负载均衡数据分发过程中不修改IP地址,只修改目的mac地址,通过配置真是物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致,从而达到不修改数据包的源地址就可以进行数据分发的目的。这种负载均衡方式又称直接路由方式DR

6)        负载均衡算法

轮询:所有请求被一次分发到每台应用服务器上

加权轮询:按照配置的权重将请求分发到每个服务器,高性能的服务器能分配更多请求。

随机:请求随机分配到各个服务器

最小链接:记录每个应用服务器正在处理的连接数,江心岛的请求分发到最少链接的服务器上

源地址散列:根据请求来源的IP地址进行Hash计算,得到应用服务器,这样来自同一个IP地址的请求总在同一个服务器上处理,请求的上下文信息可以存储在这台服务器上,实现会话粘滞。

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

1)        Memcached分布式缓存集群的访问模型

应用程序输入需要写缓存的数据,API将K输入路由算法模块,路由算法根据K和Memcached集群服务器列表计算得到一台服务编号NODE1,静儿得到该机器的IP地址和端口。API调用通信模块和编号为NODE1的服务器通信,将数据写入服务器,完成缓存写操作;

读缓存使用同样的路由算法和服务器列表,通过K值访问相同的服务器去读取相同的缓存。

2)        路由算法:

简单的使用余数Hash:用服务器数目初一缓存数据KEY的Hash值,余数为服务器列表下标编号

一致性Hash算法:构造一个长度为0~2^32的整数环,根据节点名称的Hash值,将缓存服务器节点放置在这个Hash环上,然后根据需要缓存的数据的Key值计算得到其Hash值,然后再Hash环上顺时针查找距离这个Key的Hash值最近的缓存服务器节点,完成Key到服务器的Hash映射查找

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

         Cobra/HBase

 

你可能感兴趣的:(后台)