一、架构演变
不断迭代的架构图:
切记: 不要为了追求技术而设计架构, 而是为了业务来使用技术.
二、网站架构模式
- 分层: 应用层,服务层,数据层
- 分割:业务拆分
- 分布式:分布式应用和服务、分布式静态资源、分布式数据和存储、分布式计算、分布式配置、分布式锁、分布式文件
- 集群: 同一个集群配置相同项目,一个出错访问另外的
- 缓存:CDN、反向代理、本地缓存、分布式缓存
- 异步:提高系统可用性、加快网站响应速度、消除并发高峰(rabbitMQ)
- 冗余:冷备份,热备份,灾备中心
- 自动化:自动化发布、自动化代码管理、自动化测试、自动化安全测试、自动化部署、自动化监控 、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化分配资源
- 安全:加密、验证码、XSS、SQL注入、风险控制
三、大型网站架构核心要素
1、性能
2、可用性:一台宕机,其他的顶上
3、伸缩性:容易向集群中加入新的服务器
4、扩展性:方便业务进行扩展
5、安全性
四、瞬时响应:网站的高性能架构
- 网站性能测试
- web前端性能优化:减少HTTP请求,浏览器缓存、数据压缩、css放上面,js放下面,较少cookie传输、 cdn加速、 反向代理
- 应用服务器性能优化:分布式缓存、异步、集群、代码优化
- 存储性能优化:机械硬盘和固态、B+树和LSM树文件数据索引排序(排序后方便读取)、RAID和HDFS
五、万无一失:网站高可用架构
1. 高可用的应用:
- 通过负载均衡进行无状态的失效转移,一个服务器失效转移到另外的可用的
- 应用服务器集群的Session管理
A. Session复制,多个负载均衡的服务器之间复制session, 占用大量网络带宽,太慢
B. Session绑定, 根据IP地址绑定不同服务器.(无意义)
C. Cookie存储Session,简单易用,可用性高
D. Session服务器,
2.高可用服务
- 业务分级管理, 核心业务使用更好的硬件
- 超时设置, 服务调用设置超时时间, 一旦超时, 转移到其他服务器
- 异步调用, 缩断响应时间
- 服务降级, 并发量太大时, 为保证核心业务正常运行.
A. 拒绝服务: 随机拒绝部分用户请求
B. 关闭功能: 关闭非核心业务(淘宝双十一,关闭评价和确认收货功能) - 幂等设计: 保证接口幂等性
3. 高可用数据
- CAP原理
CAP原则又称CAP定理,指的是在一个分布式系统中,一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)。CAP 原则指的是,这三个要素最多只能同时实现两点,不可能三者兼顾。
数据持久性: 写入数据持久性存储, 并且多个备份
数据可访问性: 一台服务器出错, 将其请求转移或者拒绝访问
数据一致性: 保证多个副本之间数据一致
大型网站, 一般会选择 可用性A和伸缩性P, 适当放弃一致性,因为一致性一般只在高并发写操作和集群状态不稳定时容易产生.
数据一致性分类:
- 数据强一致: 各个副本物理数据总是强制一致的, 数据更新操作结果和操作响应总是一致的.
- 数据用户一致: 副本可能不一致 ,但用户访问时,通过纠错和校验机制, 确定一个一致的且正确的数据返回给用户.
- 数据最终一致: 同一用户连续访问,结果不同,不同用户同时访问, 结果也不同, 但是在一个比较短的时间内, 数据会进行自我修复, 保证最终一致性
4.数据备份
热备份: 异步热备份和同步热备份
5.失效转移
- 失效确认:
通过控制中心确认服务器已经宕机 - 访问转移
一台服务器宕机, 路由到其他服务器 - 数据恢复
宕机的服务器重启后需要恢复数据
6.高可用软件质量保证
- 网站发布
分批发布: - 自动化测试
- 预发布验证
开发工程师修改host文件到预发布服务器 - 代码控制, SVN,Git
- 自动化发布:
周四发布最合适: 周一到周三准备, 有问题周五修复
火车模型
- 灰度发布: 分批集群进行发布, 有问题及时回滚
7. 网站运行和监控
- 用户端日志收集: 服务端收集,浏览器收集(js脚本)
- 服务器性能监控
- 运行数据报告
8.监控管理
- 系统报警
- 失效转移
- 自动降级