大型网站技术架构
2019-12-23 10:11:12 0 举报AI智能生成
根据书籍整合
作者其他创作
大纲/内容
架构核心要素
高性能架构
安全性架构
可用性架构
伸缩性架构
扩展性架构
网站的高性能架构
性能测试
性能观察视角
用户视角
开发视角
运维视角
性能测试指标
响应时间
请求和响应的时间差，进行重复测试，然后取得平均的响应时间
并发数
系统能够同时处理的请求数量，测试程序在两次请求中间加入一个随机等待时间，这个时间称为思考时间
吞吐量
单位时间内系统处理请求数量，如：请求数量/秒，页面数/秒、访问人数/天
TPS:每秒事务数
HPS:每秒HTTP请求数
QPS:每秒查询数
性能计数器
系统负载
对象与线程数
内存使用
cpu使用
磁盘与IO
性能测试方法
性能测试
负载测试
压力测试
稳定性测试
性能优化
性能分析
代码问题?硬件资源问题?架构问题？
web前端性能优化
减少http请求，如合并js、合并css、合并图片
使用浏览器缓存
比如缓存图片、css、js等，可通过http头Cache-Control和Expres来控制缓存和时间等
如果有更新，通过更改文件名来实现缓存失效
如果有更新，通过更改文件名来实现缓存失效
启用压缩
比如对传输的静态文件进行压缩，到浏览器在解压缩，可有效降低数据传输量
但也对服务器增加了一些压缩的压力，所以在通信良好和系统资源不足的情况下需要权衡考虑
但也对服务器增加了一些压缩的压力，所以在通信良好和系统资源不足的情况下需要权衡考虑
css在上，js在下
css文件放在页面上端，让浏览器尽快渲染页面
尽量将js放在页面下面，因为浏览器加载到js时会立即执行，会造成页面的阻塞
尽量将js放在页面下面，因为浏览器加载到js时会立即执行，会造成页面的阻塞
减少cookie的传输
减少cookie的传输
比如访问静态文件、css、js等就不需要cookie信息，可以考虑使用不同的域名
比如访问静态文件、css、js等就不需要cookie信息，可以考虑使用不同的域名
CDN加速
部署在网络运营商的机房，以缓存访问量很高的静态页面、css、js、图片等
反向代理
一般部署在应用服务器之前，通过缓存静态文件、css、js、图片等来减少服务器的压力
也可缓存一些动态文件，当这些内容有变化时，通过方向通知机制通知代理来通知代理缓存失效
有时也做负载均衡控制
也可缓存一些动态文件，当这些内容有变化时，通过方向通知机制通知代理来通知代理缓存失效
有时也做负载均衡控制
应用服务器性能优化
缓存
性能优化第一定律:优先使用缓存
二八定律:80%的访问落在20%的数据上
缓存预热
系统启动时及缓存一部分数据
缓存穿透
访问不存在的数据，由于缓存没有，所有请求都落在数据库上
规避方法，对不存在的数据也缓存null
分布式缓存架构
同步更新架构
JBoss Cache
互不通信架构
Memcached
内存分配
slab_class--slab---chunk
LRU算法清楚最近最久未被访问的数据
slab_class--slab---chunk
LRU算法清楚最近最久未被访问的数据
redis
nosql
异步操作
消息队列
需要考虑业务是否允许
使用集群
代码优化
多线程
如果是IO磁盘操作，多启动线程就能够提高程序的吞吐量
如果是IO磁盘操作，多启动线程就能够提高程序的吞吐量
如果都是cpu计算型任务，启动线程数最多不超过cpu内核数
涉及线程安全问题
使用无状态对象
使用局部对象
使用线程安全类或锁
资源复用
单例
对象池
线程池
通信池
内存优化
合理配置内存大小
垃圾回收
存储性能优化
机械硬盘VS固态硬盘
传统数据库采用B+树结构--N叉排序树
Nosql采用LSM存储--N阶合并数
RAID和HDFS
网站的伸缩性架构
架构的伸缩性设计
不同功能进行物理分离实现伸缩
纵向分离
横向分离
单一功能进行集群部署实现伸缩
应用服务器的伸缩性设计
http重定向负载均衡
重定向http请求实现
DNS域名解析负载均衡
通过一个域名配置多个地址实现
反向代理负载均衡
一般反向代理服务器都具备负载均衡的功能
ip负载均衡
通过修改ip的方式实现
数据链路层负载均衡
通过修改mac地址的方式实现
缓存的伸缩性设计
一致性hash算法，一致性hash环
通过key计算得到hash值，在hash环上顺时针查找，离此hash值最近的服务器就是要招的缓存服务器
将一台物理服务器虚拟成多个虚拟服务器，将虚拟服务器的hash值放在hash环上
一台服务器虚拟150个虚拟服务器比较合理
数据存储服务器的伸缩性设计
关系数据库
mysql
oracle
nosql数据库
Apache HBase
MongDB
redis
网站的安全性架构
攻击
XSS攻击（跨站脚本攻击）
攻击手法
反射型
诱导用户点击恶意链接
诱导用户点击恶意链接
持久型
提交含有恶意代码的请求，存储到服务器上进行攻讦
提交含有恶意代码的请求，存储到服务器上进行攻讦
防御
对输入信息进行过滤和转义
使用httponly
javascript无法读取带有httponly属性的cookie
javascript无法读取带有httponly属性的cookie
注入攻击
攻击手法
sql注入和OS注入
防御
避免错误回显，如500错误不能显示在页面上，避免为黑客提供猜取数据库的可能性
过滤和消毒
参数绑定，让攻击者提交的数据当成参数执行，而不是当成命令执行
CSRF攻击（跨站点请求伪造）
攻击手法
攻击者通过跨站请求，以合法用户的身份进行操作，其核心是利用了cookie和session策略来盗取用户身份
防御
表单token
http请求头的Referer记录着请求来源，可通过检查此值来确定是否是正常页面发起
文件上传
手段
可以通过上传可执行程序来达到攻击的目的
可以通过上传可执行程序来达到攻击的目的
防御
只允许上传指定类型，还可以修改文件名等
只允许上传指定类型，还可以修改文件名等
路径遍历
攻击者在请求中使用相对路径来访问未开放的目录
防御
js、css等使用独立的服务器、独立的域名，其它文件不使用静态路径访问，动态参数不包含路径信息
js、css等使用独立的服务器、独立的域名，其它文件不使用静态路径访问，动态参数不包含路径信息
web应用防火墙
ModSecruity
探测攻击并保护web程序
信息加密技术
单向散列算法
MD5
SHA
对称加密
DES
RC
非对称加密
RSA
信息过滤与反垃圾
文本匹配
大型网站架构演变过程
初始架构
一台服务器
应用、DB、文件都在一块
经典的LAMP模式
应用服务和数据分离
问题：性能变差、数据存储空间不够
3台服务器
应用服务器
需要处理大量业务逻辑，这需要更强的CPU；
数据服务器
需要快速磁盘检索和数据缓存，这需要更快的硬盘和更大的内存；
文件服务器
需要存储用户上传的文件，需要更大的硬盘；
使用缓存改善网站性能
问题：访问量持续增长，web性能再次变差；响应速度变慢
2-8定律：web的访问规律：80%业务访问集中在20%的数据上；
增加应用服务器本地缓存，这个最直接，也最简单
增加远程分布式缓存集群：当本地的内存不足以放下需要的缓存的数据时，就只能通过分布式
使用类似于memcached之类的开源缓存产品。redis缓存更多的数据
应用服务器集群化
随着网站的成长，单一应用服务器成为网站瓶颈；
应用服务器集群化提高网站并发处理能力
做成集群的关键是增加负载均衡服务器来调度应用集群
数据库读写分离
问题：当增加缓存之后，随着访问量的持续增长，
数据库再次出现问题：数据库负载压力过高
数据库再次出现问题：数据库负载压力过高
数据库读写分离
利用数据库主从热备功能，实现读写分离；
读写分离的细节这篇文章讲的很清楚了，就不多说，有需要的请参考
利用数据库主从热备功能，实现读写分离；
读写分离的细节这篇文章讲的很清楚了，就不多说，有需要的请参考
使用反向代理和CDN
问题：网站做大，全国甚至全球各区域的访问量都来了，但是各区域的访问速度差别巨大；
解决方案：使用反向代理和CDN
CDN和反向代理基本原理都是缓存，CDN部署在网络提供商的机房，
用户请求最近的节点访问；而反向代理则部署在网站的中心机房；
使用分布式FS和分布式DBS
问题：应用集群如果将session管理做好，或做成无状态的应用集群，可达到线性伸缩；
而数据库的压力却不是很好解决；
而数据库的压力却不是很好解决；
解决方案：使用分布式数据库拆分，可使用的方法有：
单表拆分：将不同的表放到不同的库中，从而降低单个数据库的结点的负载；
这样带来的问题就是不同库中的表无法做join操作；
这样带来的问题就是不同库中的表无法做join操作；
另一种方法就是按业务拆分，将属于同一业务的表划分到一个库中，
从而有效降低数据库负载，同时在业务逻辑实现上不至于过于复杂；
使用NOSQL和搜索引擎
问题：出现海量数据存储和检索的需求
解决方案：使用NoSQl产品分布式部署来支持海量数据的查询和存储；
业务切分
按照业务来划分子系统，按产品线划分系统，通过分布式服务来协同工作；
系统发展到最后都是一个拆分的过程，也不会像三国一样合就必分，系统职能越来越单一化。
这也回到了面向对象编程的五项基本原则的单一职责的原则。
这也回到了面向对象编程的五项基本原则的单一职责的原则。
大型网站架构模式
分层
横向维度切分
示例
spring MVC模式
网络的七层架构模式
分割
将大系统模块化，进行业务分割
分布式
分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算
分布式配置
分布式锁
分布式文件系统
集群
多条服务器部署相同的应用
缓存
CDN
反向代理器
本地缓存
分布式缓存
异步
使用消息队列等方式
冗余
自动化
自动化部署
自动化测试
自动化管理
安全
通信加密
密码加密
防止网络攻击
网站的高可用架构
可用性度量
多少个9来衡量可用性，即99%，99.9%，99.99%
多少个9来衡量可用性，即99%，99.9%，99.99%
2个9表示基本可用,年度不可用时间小于88小时
3个9较高可用，不可用时间小于9小时
4个9高可用，不可用时间小于53分钟
5个9极高可用，不可用时间小于5分钟
可用性考核
故障分=故障时间(分钟)*故障权重
高可用性应用
通过负载均衡进行无状态服务的失效转移
集群部署
应用服务器集群的session管理
session服务器集群
建立单独的服务器管理session
session复制
各服务器间复制session，内存及性能会有影响
session绑定
同一个ip访问同台服务，如果一台服务挂了，数据就会丢失
利用cookie记录session
高可用服务
分级管理
核心业务使用好的硬件，且管理级别高
超时设置
超时请求可抛出异常，负载均衡根据策略可选择重试或者分配到另外的服务上处理
异步调用
服务降级
拒绝服务
拒绝低优先级的服务调用，以保证高优先级的服务正常工作
比如同一个服务A能访问，B不可以，很可能是B被拒绝服务了
比如同一个服务A能访问，B不可以，很可能是B被拒绝服务了
关闭服务
关闭一部分低优先级的服务来保证高优先级服务的正常工作
比如淘宝双11时可能会关闭评价、确认收货等服务
比如淘宝双11时可能会关闭评价、确认收货等服务
幂等性设计
保证服务重复调用和调用一次的结果是一致的，比如转账操作
高可用数据
CAP原理
一个提供服务的存储系统无法同时满足:
数据一致性(Consistency),
数据可用性(Availibility),
分区耐受性(patition Torlerance)
数据一致性(Consistency),
数据可用性(Availibility),
分区耐受性(patition Torlerance)
大型网站通常会首先保证数据的可用性、分区耐受性，而牺牲一些一致性
数据一致性
数据强一致
数据用户一致
数据最终一致
数据备份
冷备
定期复制数据，缺点是不能保证数据最终一致，也无法保证数据可用性,因为数据恢复的时候是无法访问的
热备
异步热备
同步热备
关系数据库的热备机制:Master-Slave主从同步策略
失效转移
单一台数据服务宕机时，可以转移到另外一条数据服务上进行
单一台数据服务宕机时，可以转移到另外一条数据服务上进行
失效确认
访问转移
数据恢复
高可用网站的软件质量保证
网站发布
自动化测试
Selenium自动化测试工具
预发布验证
代码控制
主干开发，分支发布
不同项目不同期问题
分支开发，主干发布
可分工开发
自动化发布
灰度发布
每天只发布一部分服务器，持续多天发布，直至发布完成
网站运行监控
监控数据采集
用户行为日志
服务端日志收集
比如web服务器都能提供日志收集
比如web服务器都能提供日志收集
页面嵌入javascript的方式收集
比如百度访问量监控
比如百度访问量监控
服务器性能监控
CPU
内存
IO
运行数据报告
缓存命中率
响应时间
吞吐量
并发量
监控管理
系统报警
失效转移
自动降级
网站的可扩展性
分布式消息队列降低系统的耦合性
分布式服务提高系统的可复用性
0 条评论
下一页
