更新记录
- 2014/11/30, 添加笔记.
- 2015/1/7, 将笔记从Github移到简书
第一篇: 概述
- 大型网站的演化
- 大型网站架构模式
- 大型网站核心架构元素
第一章: 大型网站的演化
1.1 大型网站软件系统的特点
- 高并发, 大流量
- 高可用
- 海量数据
- 用户分布广泛, 网络情况复杂
- 安全环境恶劣
- 需求快速变更, 发布频繁
- 渐进式发展
1.2 大型网站架构演化发展历程
- 初始阶段的网站架构
一台服务器搞定一切
- 应用服务和数据服务分离
分出了应用, 数据, 文件三台服务器. 应用服务器要处理大量的业务, 所以需要更快更强的CPU. 数据服务器快速磁盘检索和数据缓存, 需要更快的硬盘和大内存; 文件服务器用于存储用户的文件, 需要更大的硬盘
- 使用缓存改善网站性能
遵循2/8定律. 80%的业务访问集中在20%的数据上.
只要缓存住了这20%的数据, 就可以大大减少服务器的读
- 使用应用服务器集群改善网站的并发处理能力
通过持续增加应用服务器的方式来改善负载压力, 实现系统的可伸缩性.
而不是采购更强的服务器.
- 数据库的读写分离
配置主从数据库. 应用服务器要写数据时, 访问主数据库. 主数据库通过主从复制机制将数据更新同步到从数据库.
- 使用反向代理和CDN加速网站响应
基本原理都是缓存. 区别在于CDN部署在网络提供商机房中. 而反向代理部署在网站机房中.
- 使用分布式文件系统和分布式数据库系统
使用分布式数据库是数据库拆分的最后手段. 更常使用的是业务分库.
- 使用NoSQL和搜索引擎
通过一个统一的数据层访问各种数据, 减轻应用程序管理诸多数据库的麻烦
- 业务拆分
将整个网站业务拆分成不同的产品线
- 分布式服务
1.3 大型网站架构演化的价值观
- 核心价值是随网站所需灵活应对
- 驱动技术发展的主要力量是业务发展
1.4 网站架构设计误区
- 一味追求大公司的解决方案
- 为了技术而技术
- 企图用技术解决所有问题
技术是用来解决业务问题的, 而业务问题, 也可以通过业务的手段去解决
第二章: 大型网站架构模式
模式: 问题和场景的可重复带来了解决方案的可重复性
2.1 架构模式
- 分层
将系统在横向纬度上切分成几个部分, 每个部分负责一部分比较单一的职责, 然后通过上层对下层的依赖和调用组成一个完整的系统.
分层架构的挑战: 必须合理规划层次边界和接口, 在开发过程中, 严格遵循分层架构约束, 禁止跨层次的调用以及逆向调用(如数据层调用应用层)
- 分割
在纵向方面对软件进行切分. 将不同的功能和服务分割开来, 包装成高内聚低耦合的模块单元.
一方面有助于软件的开发和维护; 另一方面, 便于同步模块的分布式部署, 提供网站的并发处理能力和功能扩展能力
- 分布式
分层和分割的一个主要目的就是为了分布式部署.
分布式会带来以下问题:
a. 必须通过网络, 对性能造成影响
b. 服务器越多, 宕机的可能性越大, 使网站的可用性降低
c. 在分布式环境下保证数据的一致性很困难, 分布式事务也难以保证, 对业务正确性和业务流程造成影响
d. 导致网站依赖复杂, 开发管理维护困难
常用的分布式:
a. 分布式用用和服务
b. 分布式静态资源
减轻应用服务器负载; 通过独立域名加快浏览器并发加载速度; 由专门用户体验团队维护, 分工更加明确.
c. 分布式数据和存储
d. 分布式计算
Hodoop和MapReduce. 特点是移动计算而不是移动数据, 将计算程序分发到数据所在的位置以加速计算和分布式计算
e. 分布式配置
f. 分布式锁
g. 分布式文件系统
- 集群
使用分布式虽然将分层和分割后的模块独立部署, 但对于用户访问集中的模块(比如首页), 还需要将独立部署的服务器集群化, 即多台服务器部署相同的应用构成一个集群, 通过负载均衡服务器共同对外提供服务.
- 缓存
缓存就是将数据存放在距离计算最近的位置以加快处理速度, 缓存是改善软件性能的第一手段
缓存的分类:
CDN: 内容分发网络
反向代理
本地缓存
分布式缓存: Redis Memcached
使用缓存的2个条件:
a. 数据访问热点不均衡, 将热点数据缓存起来
b. 数据在某个时间段内有效, 不会很快过期. 否则缓存的数据会因为失效而产生脏读.
**缓存的作用: **
a. 加速数据访问速度
b. 减轻后端应用和数据存储应用的负载压力, 这一点对网站数据库架构至关重要. 网站数据库几乎都是按照有缓存的前提进行负载能力设计的
- 异步
通过消息队列, 将同步的操作编程异步的.
异步具有如下特性:
a. 提供系统的可用性
b. 加速网站响应速度
c. 消除并发访问高峰
可能对用户体验和业务流程造成影响.
- 冗余
- 自动化
a. 发布过程自动化
b. 自动化代码管理
c. 自动化测试
d. 自动化安全检测
e. 自动化部署
f. 自动化监控
g. 自动化报警
h. 自动化失效转移: 将失效的服务器从集群中隔离除去, 不再处理系统中的应用请求
i. 自动化失效恢复: 重新启动服务, 同步数据保证数据一致性
j. 自动化降级: 通过拒绝部分请求及关闭部分不重要的业务将系统负载降至一个安全的水平
k. 自动化分配资源: 将空闲资源分配给重要的服务, 扩大其部署规模
- 安全
- 身份认证: 密码, 手机短信
- 登录,交易等操作需要对网络通信加密
- 网站存储的敏感数据要加密
- 使用验证码防止机器人攻击
- 对于XSS攻击, SQL注入进行编码转换
- 对垃圾信息和敏感信息进行过滤
- 对交易转账等重要操作进行风险控制
2.2 架构模式在新浪微博中的应用
小结: 好的设计绝不是模范, 不是生搬硬套某个模式, 而是对问题深刻理解之上的创造和创新
山寨和创新的最大区别不是是否抄袭和模范, 而在于对问题和需求是否真正理解和把握
第三章: 大型网站核心架构要素
软件架构: 有关软件整体结构与组件的抽象描述, 用于指导大型软件系统各个方面的设计
系统的各个重要组成部分及其关系构成了系统的架构. 这些组成部分可以是具体的功能模块, 也可以是非功能的设计和决策, 如性能/可用性/伸缩性/扩展性/安全性, 它们相互关系组成一个整体, 共同构成了软件系统的架构
3.1 性能
衡量性能的指标: 响应时间, TPS, 系统性能计数器
对于网站而言, 性能符合预期仅仅是必要条件, 因为无法预知网站可能面临的访问压力, 所以必须考察系统在高并发情况下, 超出负载设计能力时可能出现的问题. 网站需要长时间运行, 还必须保证在持续运行且访问压力不均匀时保持问题的性能特征.
3.2 可用性
高可用的目标就是当服务器宕机时, 服务依然可用. 主要手段是集群, 冗余. 关键在于服务器中不能保存用户会话状态.
3.3 伸缩性
定义: 通过不断想服务器集群中添加服务器的手段来缓解不断上涨的用户并发访问压力和不断增长的数据存储需求
3.4 扩展性
扩展性直接关注网站的功能需求.
目的: 在网站快速发展, 功能不断扩展时, 网站架构能够快速响应需求变化.
主要手段:
a. 事件驱动架构: 利用消息队列实现
b. 分布式服务: 将业务和可复用服务分离开来, 通过分布式服务框架调用
3.5 安全性
小结: 性能, 可用性, 伸缩性, 扩展性和安全性是网站架构最核心的5个要素, 这几个问题解决了, 大型网络架构设计的大部分挑战也就是克服了.
第二篇: 架构
第四章: 瞬时响应, 网站的高性能架构
4.1 网站性能测试
1) 不同视角下的网站性能
- 用户视觉的网站性能
从用户角度, 网站性能就是用户在浏览器中直观感受到的网站响应速度是快还是慢.
优化手段:
- 优化页面HTML
- 利用浏览器端的并发和异步特性
- 调整浏览器缓存策略
- 使用CDN服务
- 反向代理
- 开发人员视角的网站性能
开发人员关注: 应用程序本身及其子系统的性能, 包括响应延迟, 系统吞吐量, 并发处理能力, 系统稳定性等技术指标.
优化手段:
- 使用缓存加速数据读取
- 使用集群提高吞吐能力
- 使用异步消息加快请求响应及实现削峰
- 使用代码优化手段改善程序性能
- 运维人员视角的网站性能
运维人员更关注: 基础设施性能和资源利用率, 如网络运营商的带宽能力, 服务器硬件的配置, 数据中心网络架构, 服务器和网络带宽的资源利用率
**优化手段: **
- 建设优化骨干网
- 使用高性价比定制服务器
- 利用虚拟化技术优化资源利用
2) 性能测试指标
从开发和运维视角看, 网站性能测试的主要指标有: 响应时间, 并发数, 吞吐量, 性能计数器.
- 响应时间
特指应用执行一个操作需要的时间, 包括从发出请求开始到收到最后响应数据所需要的时间. 它是最重要的性能指标, 直观反映系统的'快慢'.
常用系统操作响应时间表
| 操作 | 响应时间 |
- 并发数
- 吞吐量
- 性能计数器
3) 性能测试方法
4) 性能优化策略
4.2 Web前端性能优化
- 浏览器访问优化
- CDN加速
- 反向代理
4.3 应用服务器性能优化
- 分布式缓存
- 异步操作
- 使用集群
- 代码优化
4.5 存储性能优化
- 机械硬盘 vs. 固态硬盘
- B+树 vs. LSM树
- RAID vs. HDFS
小结:
