《大型网站技术架构:核心原理与案例分析》读后感
- 整本书分为很多章节,但是我只是简要说一下大概内容和总结的内容
第一点 大型网站的架构系统的特点
- 现在我们熟悉的都是MVC的架构,什么是是MVC的架构?
- 就是web应用分为三层架构,每一层各司其职(貌似也不仅仅是web应用),现在大部分的网站(这里指的是大型网站,但是中小型的网站也已经实施分层的思想)都是使用这种思维和设计模式。但是这只是设计上的特点,还有其他特点,比如:
- 高并发,大流量 高可用 海量数据 用户分布广泛,网络情况复杂 安全环境恶劣需求快速变更,发布频繁 渐进式发展
- 以上的要素基本上就是大型网站的要点
第二点 大型网站的架构演化发展历程
- 大型网站都是从小网站发展而来的
- 初始阶段 没有人访问 一台服务器就足够 上面拥有网站的所有架构和数据
- 发展阶段 随着业务的发展 一台服务器不能满足需要 这个时候是数据和应用分离
- 继续发展阶段 使用缓存改善网站的性能 降低服务器的压力
- 使用应用服务器集群处理高并发
- 数据库读写分离
- 反向代理和CND加速网站响应
- 使用分布式文件系统和分布式数据库
- 使用NoSQL和搜索引擎
- 业务拆分
- 分布式服务
第三点 大型网站的架构演化价值观
- 这个网站是做什么的?为什么做,怎么做?实现的方法以及企业文化等等都是可以是大型网站的演化价值观
也许有的网站是为了利益,有的是为了好玩,但是最终网站的走向和这些是分不开的
第四点 网站架构的误区
- 一味追求大企业的实践方案
- 这是非常不推崇的,因为那是别人的实践,对于他们的企业以及网站就是非常优秀的解决方案,但是对于我们自己的网站就一定好用,我们应该做的借鉴,而不是抄袭
- 为了技术而技术
- 怎么说的?杀鸡焉用宰牛刀,这句话完全诠释。我们要做的应该是刚刚好,资源不会不够或者浪费,
- 企图用技术解决所有问题
- 这里小猪童鞋要说,法律是技术,而案件就是问题,有时候法和情之间很难抉择,在这里也是一样的。
技术不是万能的,但是没有技术不行,有些应该是业务的架构,比如12306,此处不吐槽了。它的业务架构很复杂很复杂,比起来淘宝的双11来讲,淘宝的双十一抢购,二者各方都有专攻 - 淘宝是计算商品,而12306是计算路线,大家可以设想一下,我从A到Z,途径ABCD—-XYZ,这个是一个完整的路途,12036是不是需要计算有没有这样的一个我不需要换座位的路线,如果有,直接给我,如有没有,就要开始计算,我到哪儿需要转车,而且在计算的过程中,又有很多人来买票退票,自然就很复杂,崩溃也就很正常。
- 这里小猪童鞋要说,法律是技术,而案件就是问题,有时候法和情之间很难抉择,在这里也是一样的。
第五点 大型网站的架构模式
- 分层 MVC思想
- 分割
- 分布式
- 集群
- 缓存
- 异步
- 冗余
- 自动化
- 安全
第六点 大型网站核心架构要素
- 什么是架构:”最高层次的规划,难以改变的决定”
- 性能
- 可用性
- 就是不能经常挂掉,就算挂点也能很快跑起来 这里有个4个9以上的指标 就是一年的99。99%的时间是可以正常使用的
- 伸缩性
- 就是是否可以多台服务器构建集群,是否容易向集群中添加新的服务器或者去除不需要的服务器
- 扩展性
- 在网站新增产品或者业务的时候,或是网站下架某个业务的时候,是否会对整体的架构有很大的影响,时候这个业务挂掉,也不会影响整体的使用
- 安全性
第七点 网站的高性能架构:瞬时响应
网站的性能测试
不同视角下的网站性能
- 用户视角
- 开发人员视角
- 运维人员视角
性能测试指标
- 响应时间
- 并发数
- 吞吐量
- 性能测试器
性能测试方法
- 性能测试
- 负载测试
- 压力测试
- 稳定性测试(最大负载点。系统崩溃点等)
性能测试报告
性能优化策略
- 性能分析
- 负载优化
Web前端性能优化
- 浏览器访问优化
- 减少HTTP请求
- 使用浏览器缓存
- 启用压缩
- CSS放在最上面 JavaScript放在最下面
- 减少Cookie的传输
- CDN加速
- 反响代理
服务器性能优化
分布式缓存
- 缓存的原理
- 合理修改缓存
- 注意点:
- 频繁修改的数据
- 没有热点的访问
- 数据不一致和脏读
- 缓存可用性
- 缓存预热
- 缓存穿透
- 分布式架构缓存
- 一些缓存的”大哥” Redis / Memcached
- Memcached的特点
- 简单的通信协议
- 丰富的客户端程序
- 高性能的网络通信
- 高效的内存管理
- 互不通信的服务器集群架构
- Redis
异步操作
使用集群
代码优化
- 多线程
- 将对象设计为无状态对象
- 使用局部对象
- 并发访问资源时候使用锁
- 资源复用
- 数据结构
- 垃圾回收
存储性能优化
- 机械硬盘 VS 固态硬盘
- B+树 VS LSM树
- RAID VS HDFS
第八点: 网站的高可用架构:万无一失
网站可用性的度量与考量
- 也就是4个9, 99。99%的时间可用 以及度量
分类 | 描述 | 权重 |
---|---|---|
事故级故障 | 严重故障,网站整体不可用 | 100 |
A类故障 | 网站访问不顺畅或核心功能不可用 | 20 |
B类故障 | 非核心功能不可用。或核心功能少数用户不可用 | 5 |
C类故障 | 以上之外的故障 | 1 |
- 故障分=故障时间(分)x故障权重
高可用的网站架构
- MVC / 集群等
高可用的应用
- 通过负载均衡进行无状态服务的失效转移
- 应用服务器集群的Session管理
- session的复制
- session的绑定
- 利用cookie记录session
- session服务器
高可用的服务
- 分级管理
- 超时设置
- 异步调用
- 服务降级
- 幂等性设计
高可用的数据
- CAP原理
- 数据持久性
- 数据可访问性
- 数据一致性
- 数据强一致
- 数据用户一致
- 数据最终一致
- 数据备份
- 失效转移
- 失效确认
- 访问转移
- 数据恢复
高可用网站的软件质量保证
- 网站发布
- 自动化测试
- 预发布测试
- 代码控制
- 主干开发。分支发布
- 分支开发,主干发布
- 自动化发布
- 灰度发布
网站运行监控 (不允许没有监控的系统上线)
- 监控数据采集
- 用户行为日志
- 服务器端日志收集
- 客户端浏览器日志收集 (JavaScript脚本)
- 服务器性能监控
- 运行数据报告
- 监控管理
- 系统报警
- 失效转移
- 自动优雅降级
第九点 网站的伸缩性架构:永无止境
网站架构的伸缩性设计
- 不同功能进行物理分离实现伸缩
- 单一功能通过集群规模实现伸缩
应用服务器集群的伸缩性设计
- HTTP重定向负载均衡
- DNS域名解析负载均衡
- 反向代理负载均衡
- IP负载均衡
- 数据链路层负载均衡
- 负载均衡算法
- 轮询
- 加权轮询
- 随机
- 最少链接
- 源地址散列
分布式缓存集群的伸缩性设计
- Memcached分布式缓存集群的访问类型
- Memcached分布式缓存集群的伸缩挑战
- 分布式缓存的一致性Hash算法
- 数据存储服务器集群的伸缩性设计
- 关系型数据库集群的伸缩性设计
- NoSQL数据库的伸缩性设计
第十点 网站的可拓展架构:随需应变
关键词:拓展性 伸缩性
构建可拓展的网站架构
利用分布式消息队列降低系统的耦合性
- 事件驱动架构
- 分布式消息队列
利用分布式服务打造可复用的业务平台
- Web Service与企业级分布式服务
- 大型网站分布式服务的需求要点
- 负载均衡
- 失效转移
- 高效的远程通信
- 整合异构系统
- 对应用最少侵入
- 版本管理
- 实时监控
- 分布式服务框架设计
- 可拓展的数据结构
- 利用开发平台建设网站生态圈
第十一点 网站的安全架构:固若金汤
道高一尺魔高一丈的网站应用攻击与防御
- XSS攻击
- 注入攻击
- CSRF攻击
- 其他攻击和漏洞攻击
- Rrror Code
- HTML注释
- 文件上传
- 路径遍历
- Web应用防火墙 ModeSecurity(开源) NEC的SiteShell(收费)
- 网站安全漏洞扫描
信息加密技术以及密钥安全管理
- 单向散列加密 (MD5 / SHA)
- 对称加密(DES / RC)
- 非对称加密(RSA)
- 密钥安全管理
信息过滤与反垃圾
- 文本匹配
- 分类算法
- 黑名单
电子邮件商务风险控制
- 风险
- 账户风险
- 卖家风险
- 买家风险
- 交易风险
- 风控
- 规则引擎
- 统计模型
第十二点 国内外大型网站的架构之路
- todo
总结
到此,总结到了一个部分,这只是做一个简要的分析和总结,类似与目录的存在,终归需要明白的就是网站是一个生命,她有她的方方面面,她是一个完整的个体。页面是她的容颜,内容是她的内在美,受到攻击就是她生病了。。。。伟大起于微澜