读-李智慧-大型网站技术架构:核心原理与案例分析
来源:互联网 发布:电子病历书写软件 编辑:程序博客网 时间:2024/05/13 19:46
- 网站构架演进
- 大型网站的特点
- 架构演化历程
- 价值观
- 架构模式
- 分层
- 分割
- 分布式
- 集群
- 缓存
- 异步
- 冗余
- 自动化
- 安全
- 性能
- 性能测试
- web前端性能优化
- 应用服务器性能优化
- 存储性能优化
- 可用性
- 可用性度量和考核
- 高可用的应用
- 高可用的服务
- 高可用的数据
- 高可用的软件质量保证
- 网站运行监控
- 伸缩性
- 网站架构的伸缩性设计
- 应用服务集群的伸缩性设计
- 分布式缓存集群的伸缩性设计
- 数据存储服务器集群的伸缩性
- 扩展性
- 分布式消息队列mq
- 分布式服务rpc
- 安全性
- 网站应用的攻击与防御
- 加密
- 信息过滤与反垃圾
- 风控
- 后面还有2部分内容
- 总结
先写了大型网站的架构演化路线,给出相关的架构模式,提出从几个方面关注架构的要素,后面给出了一些案例。这本书的名字,我觉得改成架构最佳实践可能更为合适一点。
之前读过这本书,当时没带着自己的想法,走马观花,没有体会到这本书的妙处。这次带着问题,结合所经历的已有系统的架构模式,与书中所写相互印证,获益良多。
总之,这本书时一本好书,可以买本实体书。
网站构架演进
大型网站的特点
- 高并发、大流量;
- 高可用;
- 海量数据;
- 用户分布广泛、网络情况复杂;
- 安全环境恶劣;
- 需求快速变更,发布频繁;
- 渐进式发展:大型网站的发展是从小网站发展而来。
今年看双11晚会,外行看明星,内行看门道,想想一过12点的流量,能抗住这冲击,保证大部分人都能正常下单购物,就感觉ztm牛。再想想之前搞的抽奖活动,就那么点人,怎么就不能分点流量给我们了。
架构演化历程
初始阶段
应用和数据服务器分离
这一步主要还是把数据库服务器独立出去。
- 使用缓存
本地缓存和分布式缓存,这一步主要还是使用本地缓存的多点,一般不会一下子就用到分布式缓存,当然有些系统会直接使用分布式缓存。将一些配置信息、热点数据缓存本地,降低数据库压力。
引申:缓存穿透、雪崩,缓存失效,一致性hash。
- 集群
使用负载均衡通过集群减轻应用服务器的访问压力。
引申:会话管理。需要关注session是统一管理还是分配到集群中的某台机器。如果是某台那就可能有会话粘滞,如果随机一台,就可能需要需要会话统一管理。
- 数据库读写分离
这一步应该细分下为主备-分离,我们现在的系统就是也只是主从备份,没做分离。现在的系统开发,上面这几步都会一步到位,不会慢慢来了。
引申:分离后数据的一致性。
cdn和反向代理
做这一步主要还是把一些请求资源如图片和js往客户端推。缓解后端压力的同时,加速客户端响应。使用分布式文件系统和分布式数据库系统
感觉使用分布式文件系统主要是处理一些小文件存储。数据库数据量大了后一般都会对业务分库,服务器独立部署,各业务库再独立演化拆分分库分表等。
引申:数据库分布式后,就需要统一的数据访问组件隔离底层,其实在数据库主从后就需要,只是到这一步后需求更迫切。
使用nosql和搜索引擎
搜索功能对于互联网系统尤其电商业务重要性不言而喻。使用nosql做离线分析和日志等,我们之前是利用hbase做订单的二次营销。业务拆分
不同的业务,不同产品线,然后应用的独立部署。
从系统的新建到后期的数据库的读写分离等过程,业务的拆分应该是一直都存在的,只不过到一定时期后,这个需求更加迫切而已。
引申:系统间,走消息还是rpc等。
- 分布式服务
将一些基础性的业务操作,提取出来独立部署,供其他业务系统调用。
引申:分布式调用。
价值观
- 业务发展驱动了架构技术的发展
业务驱动了架构技术的发展,而不是技术驱动业务。
架构模式
分层
逻辑分层,物理上可以集中部署也可以分布式。禁止跨层条用和反向调用。
1. 应用层;
2. 服务层;
3. 数据层。
分割
业务切分。
分布式
分层分割是为了更好的分布式。常用的分布式方案:
1. 分布式应用和服务;
2. 分布式静态资源:js、css、图片等资源独立分布式部署,独立域名,动静分离;
3. 分布式数据和存储;
4. 分布式计算;
5. 分布式配置,分布式锁,分布式文件等。
集群
- 减轻负载压力;
- 冗余。
缓存
- cdn;
- 反向代理;
- 本地缓存;
- 分布式缓存。
异步
分层、分割、分布式后的不同产品线和应用间的交互,有些业务可以铜鼓异步消息交互,走消息队列异步处理。
冗余
数据和应用的冗余。灾备、同城双活,异地多活。
自动化
自动化代码管理,自动化测试,自动化部署、监控等等吧。
安全
这个范围太大了,风控、权限、网络攻击等。
性能
性能测试
性能测试时优化的基础,对于不同人员来说,关注的视角不一样
- 用户来说,更多的是关注响应延迟;
- 开发人员来说,吞吐量,并发,响应延迟;
- 运维,基础资源的利用率,网络带宽等。
测试指标
- 响应时间;
- 并发数;
- 吞吐量:tqs、qps;
- 性能计数器:描述服务器或操作系统性能的一些数据。
测试方法
- 性能测试;
- 负载测试;
- 压力测试;
- 稳定性测试。
web前端性能优化
浏览器访问优化
- 减少http请求:并发请求数有限,所以可以讲图片独立域名部署,一些js压缩合并;
- 浏览器缓存:对一些静态资源合理设置缓存时间;
- 启用压缩:这个没做过,感觉对文本文件效果会很好;
- css放在最上面,js放在最下面;
- 减少cookie传输。
cdn加速
反向代理
跟正常代理的区别:正常的是帮你跳出去,反向是帮你跳进来。也可以用来缓存静态资源和热点数据。
应用服务器性能优化
- 分布式缓存
优先使用缓存优化性能。合理使用缓存:
1. 频繁修改的数据:2:1;
2. 没有热点的数据;
3. 数据不一致与脏读;
4. 缓存可用性;
5. 缓存的预热:LRU,最近最少使用;
6. 缓存预热;
7. 缓存穿透:将不存在数据也缓存起来;
缓存架构:
1. JBoss Cache的分布式缓存在集群中所有服务器保存相同的缓存;
2. Memcached:缓存集群间不相互通讯,现在比较流行这种。我们用的是redis。
- 异步操作
感觉异步操作需要业务的妥协,而且也不是所有业务都适合异步操作。当然有些数据分发或者发个短信、邮件什么的利用消息队列使用异步操作没什么问题。
使用原则就是,任何可以晚点做的事情都应该晚点再做。
集群
代码优化
必须了解jvm。
1. 多线程:感觉能不用就最好不用,用不好都不知道怎么死的,有次用了线程池pc模式处理数据,20W数据最后老是丢几十条,查了好久,才发现,线程不同步,有的线程没有正确关闭;
2. 资源的复用;
3. 垃圾回收;
存储性能优化
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
可用性
可用性度量和考核
- 可用性度量
最经常听说的4个9,3个9。
网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点
网站年度可用性指标=(1-网站不可用时间/年度总时间)* 100%
- 考核
故障定级和故障分。
高可用的应用
通过负载均衡进行无状态服务的失效转移
应用服务器集群的session管理
- session复制;
- session绑定:hash,整个会话期间,由同一台服务器处理业务,会产生会话黏滞;
- cookie记录session;
- session服务器;
将应用服务器的状态分离,分为有状态的session服务器和无状态的应用服务器。
高可用的服务
主要是RPC的服务治理的东西,如果用过RPC的东东,应该都有所了解。
- 分级管理:主要是针对不同服务分级,不同优先级不同线程池运行,分级主要是为了大促时做降级,隔离服务;
- 超时管理;
- 异步调用:调用方式支持同步、异步、回调;
- 幂等性设计。
高可用的数据
CAP原理:传统关系数据库CP,牺牲A,现在互联网应用大都为AP,牺牲部分C,利用其它补偿做到数据最终一致;
数据备份:热备,同步,异步热备;
- 失效转移:流程:失效确认-转移-数据恢复。
高可用的软件质量保证
- 网站发布:分批次;
- 自动化测试;
- 预发布验证:准生产环境验证;
- 代码控制:主要是代码版本控制;
- 自动化发布;
- 灰度发布:部分发布,AB测试。
网站运行监控
- 监控数据采集:用户日志、服务器性能、运行数据报告;
- 监控管理:报警,转移,服务降级等;
伸缩性
网站伸缩性是指不需要改变网站的软硬件的设计,仅仅通过部署服务器的数量改变来改变处理能力。想想大促前的机器扩容。
网站架构的伸缩性设计
不同功能物理分离实现伸缩:主要是分层、分割后的业务和模块独立部署
- 纵向分离,将业务处理上的不同部分分离部署;
- 横向分离,将不同的业务模块分离部署。
单一功能通过集群实现伸缩:将单一服务集群部署提供服务
应用服务集群的伸缩性设计
主要是通过负载均衡实现集群的伸缩。
负载均衡技术:
http重定向
DNS解析
反向代理
IP负载
数据链路层负载
负载均衡算法:
- 轮询;
- 加权轮询;
- 随机;
- 最近最少连接;
- hash。
分布式缓存集群的伸缩性设计
搜索了解下分布式hash算法,的确开阔眼界。
数据存储服务器集群的伸缩性
传统数据库集群:搜索mysql的集群方案,常用的2种方式:
- client维护分片信息;
- proxy维护信息,client直跟proxy联系;
nosql,天生支持。
扩展性
网站架构的扩展性是指扩展系统功能时,对现有系统影响最小,主要还是降低系统应用间的耦合。通过2种方式:分布式消息队列降低耦合、可复用的分布式服务。
分布式消息队列:mq
感觉mq还是处理非实时业务或者分布数据,其他的实时的调用还是算了吧。
分布式服务:rpc
分布式框架dubbo的架构原理:
安全性
网站应用的攻击与防御
xss脚本攻击:特殊字符转义
sql注入:sql参数绑定
csfr跨站请求伪造:关键环节2次验证
其他攻击:
- 错误回显:配置常用errorCode如404,500等错误页面;
- html注释:外网系统不注释;
- 文件上传:文件类型等校验;
- 路径遍历:资源文件单独部署;
web应用防火墙;
安全扫描:有一些工具和平台可以做漏洞扫描,最好不要对生产做一些数据清除修改的操作。有次公司的url扫描就改了用户数据,坑爹。
加密
单向散列加密:md5,sha;
对称加密:加解密同一个秘钥,des;
非对称加密:公私钥(私钥加密,公钥解密),RSA;
秘钥管理:作者写的2种方式,没见过,感觉很少这么做,我们公司是申请服务器资源的时候,秘钥同时下发,然后定期更新密码。
- 秘钥和算法独立部署服务器,申请和使用时校验;
- 加解密算法放在应用中,秘钥独立服务器中,秘钥切片存放。
信息过滤与反垃圾
文本匹配:敏感词过滤,trie算法;
分类算法:以反垃圾邮件为例:
黑名单:布隆过滤器;
风控
前2天刚听的风控讲座,很多内容,例如风险就可以发分为欺诈、商户、法规、结算风险等,可以单独搜索学习。主要是利用规则引擎和统计模型训练。在业务流程中将风控前置,在后期可以利用统计模型,机器学习算法等进行风险预测。
推荐吴军博士的《数学之美》这本书,介绍了好多分类、搜索方面统计模型类应用。
后面还有2部分内容
- 一部分讲了几个案例,对前面架构部分做了具体的阐述,有些宽泛,案例部分,还是改天重看淘宝技术10年的时候再好好学习把;
- 另一部分讲了架构师的划分,以及作者对架构师这一工作的理解,不是架构师,虽有体会,但不深。
总结
- 业务需要推动了架构技术的演化,一个日活10来个人的网站,有必要上 一个高大全的分布式的系统嘛?非要上一个,完全自寻死路,没那需求,也没那必要;
- 传道受业解惑,这本书属于架构传道类吧。很多公司死在了通往大型网站的路上,作者写出这本书分享自己的经历,让我们能够了解学习大型网站演化过程中的架构演进,获益良多;
- 从性能、可用、伸缩、扩展性和安全性几个方面考虑网站架构并给出了优化方案,但是因为是传道类的书籍,所以广度够了,深度不够,如果能各点都给出一个够深度的难点,可能会更好;
- 看这本书,一定要带着问题,结合自身的经历去思考,如果是自己应该怎么办,这样才能学有所获,之前第一次读的时候没有注意,白白浪费了一次机会,幸好这次有时间重读一次。
- 读《大型网站技术架构:核心原理与案例分析+李智慧》记一
- 读《大型网站技术架构:核心原理与案例分析+李智慧》记二
- 读-李智慧-大型网站技术架构:核心原理与案例分析
- 大型网站技术架构:核心原理与案例分析-李智慧
- 读书笔记:《大型网站技术架构:核心原理与案例分析》(李智慧)(一)
- 大型网站技术架构+核心原理与案例分析+李智慧
- 读《大型网站技术架构:核心原理与案例分析》
- 大型网站技术架构:核心原理与案例分析
- 大型网站技术架构:核心原理与案例分析
- 大型网站技术架构:核心原理与案例分析
- 大型网站技术架构的核心原理与案例分析
- 《大型网站技术架构核心原理与案例分析》---摘要
- 《大型网站技术架构核心原理与案例分析读书笔记》
- 《大型网站技术架构:核心原理与案例分析》
- 大型网站技术架构核心原理与案例分析
- 《大型网站技术架构:核心原理与案例分析》笔记
- 《大型网站技术架构:核心原理与案例分析》读书笔记
- 《大型网站技术架构:核心原理与案例分析》读书笔记
- OOP
- Android屏幕适配
- Elasticsearch 安装过程小记
- 微软“云服务”战略效果持续强劲!
- Android 最火的快速开发框架XUtils
- 读-李智慧-大型网站技术架构:核心原理与案例分析
- 创建点云文件、加载点云文件
- 关于友盟QQ纯文本分享
- 几种加密算法的使用场景
- JS的string学习
- Apriori算法改进--FP-Tree(FP-Growth)算法
- Leetcode136: Single Number
- 各种数据库连接池对比
- JDK、JRE、JVM之间的关系