一、架构演变
不断迭代的架构图:
切记: 不要为了追求技术而设计架构, 而是为了业务来使用技术.
二、网站架构模式
- 分层： 应用层，服务层，数据层
- 分割：业务拆分
- 分布式：分布式应用和服务、分布式静态资源、分布式数据和存储、分布式计算、分布式配置、分布式锁、分布式文件
- 集群： 同一个集群配置相同项目，一个出错访问另外的
- 缓存：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.监控管理
- 系统报警
- 失效转移
- 自动降级
原创文章 63
获赞 48
访问量 8万+