大型网站技术架构 笔记
大型网站架构演化
特点：
高并发、大流量
高可用
海量数据
用户分布广泛、网络情况复杂
安全环境恶劣
需求快速变更、发布频繁
渐进式开发
演化发展历程
数据量的总大小 一个机器放不下
数据的索引（B+ Tree）一个机器的内存放不下
访问量（读写混合）一个实例不能承受
只有当以上3件事情任何一件或多件满足时，我们才需要考虑往下一级演变。
1. 初始阶段：
应用程序、数据库、文件都在一台服务器，如常用的Linux+PHP+Apache+Mysql
2. 应用服务和数据库分离
原因：性能变差、存储空间不足
三台服务器：应用服务器（运算能力：CPU）、文件服务器（更大的存储）和数据库服务器（更大的存储和内存）
3. 使用缓存改善
原因：数据库访问压力太大； 数据访问遵循2-8定律
将访问多的20%的数据放在缓存上，可分为应用服务器端的本地缓存和分布式的远端缓存
4. 应用服务器集群
原因：单一服务器处理的请求链接成为瓶颈
使用应用服务器集群，使用反向代理实现负载均衡、可用性监测、可伸缩的实现
5. 数据库读写分离
原因：使用缓存后，仍有部分读操作和全部写操作要访问数据库，随着规模的增大，这些操作造成数据库瓶颈
数据库进行主从备份和读写分离
6. 使用反向代理和CDN加速网站响应
原因：加速网站访问速度
CDN: 部署到客户端最近的网络提供商的机房，用户可从自己最近的网络提供商获取数据，多用于静态内容如CSS、图片等
反向代理：一般代理都是在客户的浏览器端，而此处的代理是在网站端。 用户请求先通过反向代理，反向代理如果缓存有用户需要的资源则立刻返回，否则调用相应服务器
7. 使用分布式文件系统
原因：业务需求继续增大
8. 使用分布式数据库
分库：
分表：单表数据规模非常庞大时
9. 使用NoSQL和搜索引擎
特点：数据存储和检索越来越复杂
NoSQL对可伸缩的分布式特性有很好的支持
10. 业务拆分
将网站拆分成多个应用，每个应用独立维护
11. 分布式服务
将共有业务（用户管理、商品管理等）提取出来独立部署，上层业务复用这些业务完成具体操作
大型网站架构模式
网站架构模式
分层
将系统分成MVC层，对C进一步分成service层和Dao层
注意：定义好层次边界和接口
作用：便于合作开发和维护；方便分离部署
分割
对业务进行拆分，彼此之间低耦合，然后部署到单独的应用服务器上
分布式
分层和分割的主要目的就是为了切分后的模块便于分布式部署
常用方案有：
1. 分布式应用与服务：改善性能和复用
2. 分布式静态资源：如JS，CSS独立部署并有独立的域名
3. 分布式数据和存储：对传统数据库使用分布式、采用NoSQL
4. 分布式计算：MapReduce
集群
在多个机器上部署单一模块，提供扩展性、有效性、负载均衡的处理
缓存
条件：某些数据被频繁访问；数据在某个时间段内有效，不会很快过期
有以下方式：
CDN：离用户最近，静态资源
反向代理：网站的前段，静态资源等
本地缓存：应用服务器本机
分布式缓存
异步
使用消息队列实现，单一应用服务器使用多线程之间的消息队列实现异步；分布式环境中使用分布式的消息队列实现异步
好处：降低耦合；加快响应速度；消除并发访问高峰
冗余
实现7*24小时服务，提高可用性
服务器集群实现； 数据库的冷、热备份
自动化
发布过程：自动化代码管理、自动化测试、自动化部署、自动化安全检测
运行过程：自动化监控、自动化报警、自动化失效转移和回复、自动化降级
安全
身份认证： 密码和手机校验码
加密：登录、交易和存储的敏感数据
验证码：机器人程序攻击网站
编码转换：XSS攻击和Sql注入
过滤：垃圾信息和敏感信息
风险控制： 对交易转账等重要操作根据交易模式和交易信息进行
大型网站核心架构要素
性能
定义：用户访问的快慢
评价指标：响应时间，TPS，系统性能计数器
手段：
1. 浏览器端：页面压缩、浏览器缓存、合理布局页面、减少cookie传输、CDN、CSS放在上面和js放在最下边
2. 应用服务器端：反向代理服务器、缓存、异步请求、集群
3. 代码层：多线程、改善内存管理
4. 数据库端：索引、缓存、SQL优化、主从备份和读写分离、NoSQL数据库
可用性
定义：可以访问的时间
评价指标：几个9，如99.99%
手段：
1. 冗余（应用服务器集群、数据库备份）
2. 软件质量：预发布验证、自动化测试、自动化发布、灰度发布
伸缩性
定义：通过向集群中加入服务器提高并发访问和数据存储需求
评价指标：是否容易添加新的服务器；新的服务器能否提供无差别服务；服务器数量是否有限制
手段：
1. 应用服务器集群：服务器上不保存数据（无状态）+合适的负载均衡设备
2. 缓存集群：改进缓存路由算法：hash环
3. 数据库集群：路由分区将部署有多个数据库的服务器组成一个集群； NoSQL数据库天生比较好
扩展性
定义：快速响应需求变化
评价指标：增加新业务，是否对现有产品透明无影响
手段：
1. 事件驱动：消息队列实现
2. 分布式服务：业务通过分布式框架调用可复用服务
安全性
定义：现存和潜在攻击手段的应对策略
瞬时响应：网站的高性能架构
网站性能测试
1. 不同视角的网站性能
1）用户视角
浏览器和服务器通信时间+处理时间+浏览器解析响应数据的时间
2）开发人员视角
应用程序本身和子系统的性能，有 响应时间、吞吐量、并发处理能力、系统稳定性等指标
3）运维人员视角
关注基础设施性能和资源利用率，如网络带宽利用率和服务器资源利用率等
手段：建设优化骨干网、定制的服务器、使用虚拟化技术优化资源利用率
2. 性能测试指标
响应时间：
执行一个操作需要的时间
测量方法：重复请求，如一个请求重复执行1万次，求得单次平均访问时间
并发数：
同时访问的请求数量
测量方法：模拟并发用户，在两次请求之间加入随机等待时间（思考时间）
吞吐量：
单位时间内处理的请求数量，TPS（每秒事务数）
并发小：吞吐量增加、响应时间小幅上升；并发逐渐增加：吞吐量下降、响应时间快速上升；并发达到崩溃点：吞吐量为0，不响应
性能计数器
描述服务器和操作系统性能的数据指标，如System Load（进程数和CPU数）、内存和CPU使用、对象与线程数
3. 性能测试方法
性能测试：以系统规划初期的指标测试
负载测试：增加并发请求，直到多项性能指标达到临界值
压力测试：直到系统崩溃
稳定性测试：特定软硬件条件下，给系统加载一定业务压力，使系统运行一段时间
4. 性能优化策略
性能分析： 检查各环节日志——》检查监控数据，关注内存、磁盘、网络、CPU——》确定是代码问题、架构设计还是系统资源不足
Web前段性能优化
浏览器访问优化
1. 减少http请求
合并javascript css、图片（如果每张独有不同的超链接，可通过css偏移响应鼠标点击操作，构造不同的URL）。
2. 使用浏览器缓存
设置http头中的Cache-Control和Expires设定浏览器缓存
静态文件变化后：改变js文件名并更新html文件中的引用
更新静态资源时，采用批量更新的方法，比如更新10个图标文件，应一个文件一个文件逐步更新，并有一定时间间隔
3. 启用压缩
可对html css javaScript启动GZip压缩，但会对服务器产生压力
需要在 通信和服务器资源间权衡考虑
4. CSS放在页面最上面，JavaScript放在最下面
浏览器会在下载完全部CSS后才进行页面渲染，最好是把CSS放在页面上边
浏览器在加载Js后立刻执行，有可能阻塞整个页面，因此js放在下面，但如果页面解析时就要用到JavaScript的，放在下面就不太合适了
5. 减少cookie传输
静态资源使用独立域名，避免发送cookie
哪些数据需要写入cookie要慎重考虑
CDN加速
用于对静态资源的代理
反向代理
部署在应用服务器前边，实现 安全过滤、缓存加速web请求、负载均衡
应用服务器性能优化
主要手段有缓存、集群和异步
分布式缓存
网站优化第一定律：优先考虑缓存优化
缓存实际是内存的hash表
1. 合理使用缓存：
1）频繁修改的数据：读写比在2:1以上
2）没有热点的访问
3）数据不一致和脏读：设置失效时间、数据更新时立即更新缓存
4）缓存可用性
5）缓存预热：新缓存上没数据
6）缓存穿透：持续高并发地请求某个不存在的数据，会对数据库造成很大压力
2. 分布式缓存架构
集群
异步
使用消息队列：减少响应延迟、平滑并发访问波动；
需要对返回状态做特殊处理，如订单提交（等待消费者处理完后才显示成功）等
代码优化
1. 多线程
使用原因：IO阻塞会释放CPU； 多CPU每个对应一个
多少线程： 启动线程数=【任务执行时间/(任务执行时间-IO等待时间)】*CPU数
线程安全问题：对象是无状态的；使用threadLocal 方法内对象；并发访问资源时加锁
2. 资源复用
开销很大的资源，如数据库连接、网络连接、线程、复杂对象。有两种模式：单例和对象池
3. 数据结构
字符串Hash散列算法：Time33算法： hash(i)=hash(i-1)*33+str[i]
相似的字符串hash值区别很大： MD5算法
4. 垃圾回收
有助于程序优化和参数调优，分为stack和heap，堆空间分为Young Generation（Eden from to）和Old Generation，新建对象在Eden，当Eden满时，复制到from；Eden又满了，将Eden和from——》to，下次Eden+to——》from，young都满了就放到old，如果都满了就触发Full GC（时间比较长）
合理设置young 和 old大小，尽量减少Full GC
存储性能优化
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
万无一失：网站的高可用性架构
可用性的度量和考核
可用性度量： 几个9，如99.99%
可用性考核（对工程师的考核）： 故障时间*故障权重
高可用的网站架构
企业级采用昂贵的软硬件，如IOE；互联网更多是PC级服务器、开源的数据库和操作系统
主要手段：数据和服务的冗余备份和失效转移。
高可用的应用
1. 无状态应用服务器
采用负载均衡软件，一般都提供：心跳检测可用性；失效转移、负载均衡
2. 有状态的应用服务器
1）session复制：当服务器集群规模下的时候可用。通过开启web容器的session复制功能，让每台服务器上都有用户session信息。 应用在集群规模小的情况下。
2）session绑定：使用负载均衡软件的源地址hash算法，保证同一IP的处理总在一台服务器上。但使用较少，主要是可用性的问题，如果该机器done了，该用户的session会丢失
3）cookie记录session：1）cookie大小限制；2）每次都要传输；3）关闭cookie访问不正常；4）简单易用；5）支持应用服务器的线性伸缩。 大部分网站或多或少使用。
4）session服务器： 可用性高，伸缩性好，性能也不错，信息大小又没限制。 将服务器中session都放到独立的session服务器统一管理，每次读写session时，都通过session服务器。通过对分布式缓存、数据库基础上包装实现。
高可用的服务
1. 分级管理： 对不同的功能模块进行分级，对于高优先级使用好的硬件，更快的相应速度；等访问量大时，可关闭低优先级功能
2. 超时设置： 设置调用的超时时间，当服务不可用或超时后，通信框架报出异常，根据调度策略转移到其他服务器
3. 异步调用：消息队列
4. 服务降级：访问高峰期，拒绝低优先级服务
5. 冥等性设计：请求重新发送时，保证统一请求重复调用和一次调用结果相同，比如转账（使用交易编号）
高可用的数据
1. 冷备： 廉价； 不能保证数据一致性；可用来定期备份
2. 异步热备：只写成功一份，其他之间复制
3. 同步热备：同时向多个副本中写入
4. 失效转移：失效确认（心跳检测和访问异常）——》访问转移——》数据恢复
5. 库表散列： 不同业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。
高可用网站的软件质量保证
1. 网站发布
每次关闭服务器集群中的一小部分，发布完后立刻可以访问。
使用发布脚本实现
2. 自动化测试
Selenium 自动化测试技术
3. 预发布验证
4. 代码控制
要求：发布版本和开发版本互不影响
主干开发、分支发布：发布时主干出一个branch，如果该版本有bug，在分支上修改发布，并将修改merge回主干
5. 自动化发布
6. 灰度发布
每天只发布一部分服务器，观察运行稳定没有故障
网站运行监控
1. 数据采集
用户行为日志收集：服务器端（web服务器）、客户端（javascript）
性能监控
运行数据报告
统计：基于实时计算框架Storm的日志统计和分析工具
2. 监控管理
系统报警
主动失效转移
自动优雅降级
永无止境：网站的伸缩架构
伸缩性：当访问量增加时，通过增加资源（服务器）可以提高吞吐率
伸缩性设计是复杂的、没有通用的、完美的解决方案
网站架构
根据功能进行物理分离实现伸缩
一台服务器——》数据库分离——》缓存分离——》静态资源从应用服务器分离
纵向分离（按层分割）：网络具体产品--可复用业务服务--基础技术服务--数据库
横向分离（业务分割）：网站前台--买家前台--卖家后台
单一功能通过集群实现伸缩
条件：当随着访问量增大，即使分离到最小粒度的独立部署，单一服务器也不能满足需要
应用服务器集群
1. 如果是无状态的，可以使用负载均衡（请求分发，服务器可用性监测）
2. 负载均衡实现技术有：
1. http重定向： 使用http request将用户请求重新定向到处理服务器，优点是简单；缺点是两次请求才能完成一次访问，性能较差。重定向服务器可能成为系统瓶颈。 http302会被搜索引擎判定为作弊。 实际使用中不多见
2. dns域名解析：在DNS中实现负载均衡。优点是负载均衡给了DNS实现简单。可以解析到用户最近的服务器地址；缺点是当下线了某台服务器不能立即反应。 实际中大型网站使用DNS作为第一级负载均衡，到同样提供负载均衡的内部服务器
3. 反向代理： 反向代理服务器提供缓存资源、负载均衡的功能，需要部署双网卡和双ip，优点是 和反向代理功能一起部署比较简单。缺点是反向代理服务器是所有请求和响应的中转站，性能可能成为瓶颈
4. IP负载均衡：负载均衡服务器修改数据包中的目的IP地址实现。优点较反向代理有更好的处理性能；缺点是所有请求都经过，数据吞吐量受限于网卡带宽
5. 数据链路层负载均衡：修改mac地址实现。使用最广，linux平台使用LVS(Linux Virtual Server)
3. 负载均衡算法
轮询：请求依次分发
加权轮询：根据服务器的硬件情况加权
随机：好的随机数本身就很均衡，如果硬件配置不同，可使用加权随机
最少链接：记录每个服务器的连接数，新的请求分配到最少的
源地址散列：对IP进行散列，使得该IP的上下文信息存储在这台服务器上，实现会话粘滞
分布式缓存
1. 目标： 新加入的缓存使得已缓存的数据尽可能能被访问到
2. memchached 分布式缓存集群，其中路由算法很重要：
1. 余数hash： 缓存数据hashcode/服务器数目。 但添加新的缓存服务器就麻烦了，解决方案是 使用虚拟节点的一致性hash环
数据存储服务器
1. 目标：相对于缓存，对数据的持久性（能存到硬盘）和可用性（能访问到数据）要求更高
2. 关系型数据库
数据库复制： 主从读写分离； 分库（不同表在不同数据库集群，缺点是不能进行跨库join）； 分表（产品有Amoeba和Cobar，Cobar可与mysql集群使用）
伸缩的实现：Corba的服务器使用负载均衡；Mysql（Cobar利用Mysql的数据同步功能进行数据迁移）
无法执行跨库Join和事务
避免事务或利用事务补偿机制（分布式事务）代替数据库事务；分解数据访问逻辑避免JOIN操作
支持JOIN的，如GreenPlum，但延迟比较大
3. NoSql数据库
Apache 的HBase，依赖于可分裂的HRegion（数据块）和HDFS（分布式文件系统）。使用者无需处理
随需应变：网站的可扩展架构
扩展性： 对现有系统影响最小情况下，可以加功能，符合开闭原则
构建可扩展的网站架构
软件架构师最大的价值不是掌握多少先进技术，而在于具有将一个大系统切分成N个低耦合的子模块的能力，这些子模块包括横向模块和纵向模块。这种能力是专业的技术和经验，对业务场景的理解，对人性的把握。
核心思想是模块化，并在此基础上，降低模块间的耦合性
主要手段是分层和分割，模块间通过分布式消息队列和分布式服务聚合
利用分布式消息队列降低耦合性
事件驱动架构
借助事件完成模块间合作，常见的是生产者消费者模式，最常用的分布式消息队列
好处是：更好的响应延迟；平缓高峰压力；
分布式消息队列
ActiveMQ：除了实现分布式消息队列，在伸缩性（加入队列服务器）和可用性（内存队列满后，写入磁盘）也做了改善。
避免系统当机造成消息丢失，会把发送成功的消息存储在生产者服务器，等消息被消费者处理后才删除消息。
分布式服务
纵向拆分：将一个大应用拆分为多个小应用，部署为单独的web系统
横向拆分：将复用业务拆分后部署为分布式服务，新增业务调用这些服务
纵向比较简单，通过梳理业务将较少相关的业务剥离，使其成为独立的web应用。横向不仅要识别可复用的业务，设计服务接口，规范依赖关系，还需要一个完善的分布式服务管理框架。
web service与企业级分布式服务
可整合异构系统和构件分布式系统
缺点： 臃肿的注册和发现机制；低效的xml序列化；开销相对较高的HTTP远程通信；复杂的部署和维护手段。
大型网站分布式服务的需求
服务注册和发现
服务调用
负载均衡：对热门服务如登录或商品服务，需要部署在集群上
失效转移
高效的远程通信
整合异构系统
对应用最少侵入：尽量使框架和业务独立
版本管理：提供者升级接口发布新版本服务，并同时提供旧版本服务，当请求者调用接口升级后才关闭旧版本服务。
分布式服务框架设计
开源的阿里的Dubbo
描述：
1. 消费者通过服务接口调用服务，服务接口通过代理加载服务，代理调用服务框架客户端模块，客户端包括服务提供者列表、负载均衡、失效迁移服务
2. 提供者提供服务管理容器注册服务
3. 支持多种通信协议和序列化协议，使用NIO通信框架，具有较高的网络通信性能
可扩展数据结构
无需修改表字段就可以新增字段，使用NoSql数据库
利用开放平台建立生态圈
提供更多的增值服务，将API开放被第三方开发者使用
固若金汤：网站的安全架构
网站应用攻击和防御
1. XSS攻击
跨站点脚本攻击，有两种，一种是反射性（在url中 ?