大型网站技术架构核心原理(1)
序
- 书籍是人类进步的阶梯,字里行间传达的是作者缜密的态度、思维的火花。在此感谢《大型网站技术架构》的作者的分享。私以为,互联网技术迭代日新月异,但核心架构理念是非常值得学习的,愿好书有更多人学习参考,谨以此笔记分享 😃
一、大型网站架构技术演化
- 核心:技术的更新是因为业务的发展,技术是来解决业务问题的
- 误区:技术不能解决所有问题,业务问题需要通过业务手段来解决
- 要素:性能、可用性、伸缩性、扩展性、安全性这五个特性间的关系需要进行平衡处理
平衡策略
性能
- 衡量性能的一般指标:
- 响应时间
- TPS(TransctionPerSecond,每秒系统能够处理的交易或事务的数量)
- 系统性能计数器
-
客户端:
- 浏览器缓存、页面压缩、减少Cookie传输、合理布局页面
- 使用 CND加速,静态资源分发至离用户最进的网络服务商机房,同时在网站机房部署反向代理服务器,缓存热点文件,加快请求相应速度,减轻应用服务器负载压力
-
服务端:
- 服务器本地缓存和分布式缓存
- 异步操作,将用户请求发送至消息队列等待后续任务处理,当前请求直接返回响应给用户
- 高并发情况下,将多台应用服务器组成一个集群共同对外服务,提高整体处理能力,改善性能
- 代码中,使用多线程、改善内存管理等手段优化性能
-
数据库服务端:
- 索引、缓存、SQL优化
- 使用 NoSQL,通过优化数据模型、存储结构、伸缩特性等手段
可用性
- 衡量标准:假设任意一台服务器宕机时,以及出现各种不可预期的问题时,系统整体是否依然可用
-
应用服务器:
- 多台服务器通过负载均衡设备组成集群,有个前提,应用服务器是不你保存
会话信息
,否则服务器宕机,即使将用户请求转发到其他服务器上也无法完成业务处理
- 多台服务器通过负载均衡设备组成集群,有个前提,应用服务器是不你保存
-
存储服务器:
- 数据冗余备份,宕机时保证数据依然可用
-
开发阶段:
- 开发人员代码质量保证
- 自动化测试,自动化发布
伸缩性
- 衡量标准:是否可以用多台服务器构建集群,是否容易向集群中添加新的服务器,加入新服务器后是否可以提供与原来的服务器无差别的服务,集群中可容纳的服务器数量是否有限制
-
应用服务器集群:
- 服务器上不保存数据,所有服务器都是对等的,可以通过使用合适负载均衡设备向集群中不断加入服务器
-
缓存服务器集群:
- 加入新的服务器可能会使缓存路由失效,进而导致集群中大不符缓存数据都无法访问,如果应用严重依赖缓存,需要改进缓存路由算法
- 使用NoSQL数据库缓存,而不是使用 关系型数据库
扩展性
-
衡量标准:增加新业务时对现有产品基本透明无影响,或者仅需改动很少既有业务
-
实现手段:
-
事件驱动:该类型网站使用
消息队列
实现,消息产生(生产者)和消息处理(消费者)分开,增加小的消息胜者任务或者小的消息消费者任务即可提高系统性能 -
分布式服务:
业务
和可复用服务
分离开,通过分布式服务框架调用。新增产品可以通过调用可复用的服务实现自身的业务逻辑,而对现有产品牡羊座任何影响
-
安全性
- 衡量标准:针对现存或潜在的各种攻击手段与窃密手段,是否有可靠的应对策略
1. 大型网站演化历程
思考角度:
- 单体应用局限性
- 数据库分库分表、主从复制
- 缓存性能、时效性
- 集群、负载均衡
- 分布式(业务、文件系统、配置、数据一致性、调度)
- 异步
- 自动化
- 安全
1.1 单服务器应用
- 特点:应用程序、数据库、文件系统统一放在一个服务器上
- 隐患:
- 数据库和文件系统会随着网站运行时间增长,存储空间不再满足需求,扩展困难
- 当用户量或并发量增大时,应用程序与数据库间会有争夺内存,很大概率会宕机
1.2 应用服务和数据服务分离
-
特点:应用服务、数据库、文件系统 放在不同的服务器上
- 应用服务器部署在
CPU有强大计算能力的服务器上
- 数据库服务器部署在
内存很大的服务器上,便于快速磁盘检索与磁盘缓存
- 文件系统服务器部署在
有大空间的存储硬盘上
- 应用服务器部署在
-
隐患:解决了单服务器存储的瓶颈
- 用户增多,对数据库的访问压力增大,导致有延迟,影响体验
1.3 使用缓存减小数据库压力
-
特点:经常访问的数据进行缓存,用户获取数据时直接从缓存中获取,减小数据库压力(二八定律)
- 本地缓存:访问速度更快,但是受本地内存限制,缓存数量有限
- 远程分布式缓存:集群,部署大内存的 的服务器作为专门缓存服务器,
可以做到理论上不受内存容量限制的缓存服务
-
隐患:
单一应用处理请求的连接数有限,应用服务器成为网站的的瓶颈
-
解决方案:增加应用服务器,通过应用服务器集群,负载均衡调度服务器来将连接分发到合适的应用服务器
1.4 解决缓存问题:主从复制,读写分离
-
特点:缓存过期,或缓存访问不命中,写操作就会请求访问数据库,用户规模到某一程度时,数据库会负载压力过高。
-
解决方案:通过主库
写数据
,然后同步更新到读数据的
从库数据服务器,读写分离,降低数据库压力
1.5 CDN加速和反向代理加速网站响应
- 特点:基本原理都是缓存,一方面加快访问速度,一方面降低服务端压力
- CDN:用户请求服务时,从距离自己最近的网络提供商机房获取数据
- 反向代理:在服务端,请求发送到服务端后,若服务端有数据则会返回数据;同时反向代理在请求量到一定规模时,也可以通过负载均衡将请求分发的合适的应用服务器上
1.6 分布式 文件系统 和 分部式 数据库系统
-
特点:表单数量过大时采用
-
解决方案:按业务拆分数据库
-
隐患:随着网站用户及业务量发展,分布式数据库不能满足需求,也需要使用分布式文件系统,这中情况只有在表单规模非常巨大使才使用,
常用的数据库拆分手段是将不同的业务数据库部署在不同的服务器上
1.6 使用NoSQL 以及搜索引擎
1.7 业务拆分
- 特点:每个应用独立部署,应用间通过
超链接
或消息队列
进行数据分发;或者通过访问同一个数据存储系统来构成一个关联的完整系统
1.8 分布式服务
- 特点:独立部署公用业务,由这些可复用的业务连接数据库,提供共用业务服务。
应用系统只需要管理用户界面,通过分布式服务调用共用业务完成具体业务操作
- 解决的问题:
- 数据库连接有限,公用业务进行数据库访问,然后为应用提供数据服务即可,减小数据服务器压力
- 公用业务得到复用,系统更好的维护
1.9 云计算平台
- 情景:大型网站通过上述演化,已通过组合和改进现有技术架构
解决海量数据的管理 和 高并发事物的处理
。因此大公司可以将这些解决方案应用到网站以外的业务上去,中小型公司不需要关注技术架构问题,直接购买即可获得更大的存储空间 和更多的计算资源
- 特点:成熟的架构体系和资源,大型网站开始搭建
云计算平台
,为中小型企业提供计算服务;一方面使大型网站本身的资源(服务器、架构方案),充分得到再利用,另一方面使得中小型公司可以专注业务的发展,不必再架构上试错
,通过购买计算服务即可。
2. 大型网站架构模式
2.1 分层
-
横向分割(逻辑分层),也在物理层面上分层,将不同层级分别部署在不同的服务器上
- 应用层
- 服务层
- 数据层
-
优点
- 便于分工合作和维护
- 各层之间具有一定的独立性,只要维持调用的接口不变,各层可以根据具体问题独立演化发展,并且不影响其他层
-
注意事项
- 各层级不能跨层级调用
- 必须合理规划层次边界和接口
2.2 分割
- 层级内纵向分割。例应用层可分多个(服务层也可根据需要分层)
- 搜索
- 购物
- 广告
- 论坛
2.3 分布式
- 基础条件:
分层
和分割
,将不同模块部署在不同的服务器是和,通过远程调用协同工作 - 实现:分布式用于处理访问量大和数据量大的应用,通过使用更多的计算机、CPU、内存、存储空间,提高并发访问量、负载均衡、计算及存储性能
- 问题:
- 宕机:一台服务器宕机,这太服务的其他子服务器也不能正常使用,资源浪费,网站可用性降低
- 网络:网络波动会影响性能
- 数据:分布式环境中数据保持一致性
2.3.1 分布式应用和服务
- 基础条件:应用和服务模块分层分割分布式部署,
- 优点:
- 改善网站性能和并发性,加快开发和发布,减少数据库连接资源损耗
- 提高服务的
复用性
,便于业务功能的扩展
2.3.2 分布式静态资源
- 动静分离,静态资源分布式部署减轻应用服务器的压力。通过使用
独立域名
,由用户体验部开发等措施,可以加快浏览器并发访问速度
2.3.3 分布式数据和存储
2.3.4 分布式计算
- 计算什么:搜索引擎的索引构建 和 数据仓库的数据分析统计
- 实现:利用
Hadoop
及其MapReduce
分布式计算框架进行批处理计算
,优点如下:- 计算:移动计算 而不是 移动数据,将计算程序分发到数据所在的位置以加速计算和分布式计算
- 分布式配置:网站线上服务器配置实时更新 分布式配置
- 分布式锁:分布式环境下实现兵法和协同的分布式锁
- 分布式文件系统
2.3.3 集群
- 相同应用用多台服务器部署,通过网关控制实现负载均衡,当一台服务器不能使用了,不会导致应用崩溃
2.3.4 缓存
- 目的:将数据存放在离计算机最近的位置以加快处理速度。
- 使用缓存的条件:
- 热点数据应该放在缓存中
- 数据不会在短期失效,否则会产生
zhang读
- 实现:
- CDN
- 反向代理
- 本地缓存
- 分布式缓存
2.3.5 异步
-
实现:
- 单一服务器:内部通过多线程
共享内存队列
的方式实现异步,在业务操作前面的线程将输出写到队列中,后面的线程从队列中读取数据进行处理; - 分布式系统中:多个服务器集群通过
分布式消息队列
实现异步,分布式消息队列可以看作内存队列的分布式部署
- 单一服务器:内部通过多线程
-
特点:典型的
生产者和消费者模式
,两者不存在直接调用,只要保持数据结构不变,彼此功能实现可以随意变化而不互相影响,这网站扩展新功能非常便利。 -
优点
- 提高系统可用性:消费者服务器故障,生产者服务器可以继续处理业务请求;消费者服务器恢复后,继续处理消息队列中的数据
- 加快网站响应速度:生产者服务器处理完业务请求后将数据写入消息队列,不需要等待消费者服务器处理就可返回,响应延迟减少
- 消除并发访问高峰:并发高峰时,消费者访问请求放到消息队列中,等待消费者服务器依次处理,虽然响应可能会慢点,但是不会对网站负载造成太大的压力
2.3.6 冗余
- 情景:网站需要 7x24 小时连续运行,服务器规模比较大时,宕机是必然事件。所以避免数据丢失,需要对数据周期进行
冗余备份
- 常见方式:
- 冷备份,数据定期备分
- 热备份,数据库主从分离
- 灾备数据重心
2.3.7 自动化
- 自动化发布
- 自动化代码管理
- 自动化测试
- 自动化安全检测
- 自动化部署
- 自动化监控
- 自动化报警
- 自动化失效转移
- 自动化失效恢复
- 自动化降级
- 自动化分配资源
2.3.8 安全
- 敏感信息加密
- 对于常见的攻击网站的 XSS 攻击、SQL 注入、进行编码转换等相应处理
- 对垃圾信息进行过滤
- 对交易转账业务进行
风险控制
严律己、宽待人