大型网站技术架构：核心原理与案例分析

大型网站架构演化

1. 大型网站软件系统的特点
1. 高并发，大流量
2. 高可用
3. 海量数据
4. 用户分布广泛，网络情况复杂
5. 安全环境恶劣
6. 需求快速变更，发布频繁
7. 渐进式发展

大型网站架构模式

1. 网站架构模式
1. 分层(横向)
   在大型网站架构中采用分层结构，将网站软件系统分为应用层、服务层、数据层
2. 分割(纵向)
3. 网站常用的分布式方案
1. 分布式应用和服务
2. 分布式静态资源
3. 分布式数据和存储
4. 分布式计算
4. 异步
5. 冗余
   服务器冗余运行，数据冗余备份。大型网站对整个数据中心进行备份，在全球范围内部署灾备数据中心。
6. 自动化
7. 安全

大型网站核心架构要素

1. 性能
2. 可用性
3. 伸缩性
4. 扩展性
5. 安全性

瞬时响应：网站的高性能架构

1. 网站性能测试
2. 性能测试标准
3. 性能测试方法
1. 性能测试
2. 负载测试
3. 压力测试
4. 稳定性测试
4. 性能测试报告
5. 性能优化策略
1. 性能分析
   检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络还是CPU，是代码问题还是架构设计不合理，或者系统资源确实不足
2. 性能优化
1. web前端性能优化
1. 减少http请求
2. 使用浏览器缓存
3. 启用压缩
   对于html、css、javascript文件启用GZip压缩，但压缩会对服务器和浏览器产生一定的压力，在通信带宽良好，而服务器资源不足的情况下要权衡考虑
4. 一般情况下，css放在页面上面，js放在页面下面，但是如果页面解析时就需要用到js，这时放在底部就不合适了
5. 减少cookie的传输
2. CDN(Content Distribute Network，内容分发网络)加速，CDN能够缓存的一般是静态资源，将访问频度高的文件缓存在CDN中可极大改善网页的打开速度
3. 反向代理
1. 保护网站安全
2. 可以通过配置缓存功能加速web请求
3. 可以实现负载均衡功能，改善网站的高并发情况下的性能
3. 应用服务器性能优化
1. 分布式缓存
   网站性能的优化定律：优先考虑使用缓存优化性能
1. 网站数据的访问通常遵循二八定律，即80%的访问落在20%的数据上
2. 不恰当的使用缓存非但不能提高系统的性能吗，还会成为系统的累赘甚至风险，不恰当的使用缓存如下：
1. 频繁修改的数据 一般，数据的读写比在2:1以上，即写入一次缓存
2. 没有热点的访问
3. 数据不一致与脏读
4. 缓存可用性
   通过分布式缓存服务器，将缓存数据分布到集群多态服务器上可在一定程度上改善缓存的可用性
5. 缓存中存放的热点数据
   热点数据有事缓存系统利用近久未用算法(LRU)，对不断访问的数据筛选淘汰出来的，这个过程需要花费较长的时间。新启动的缓存系统在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫作缓存预热
6. 缓存穿透
   应对办法：将请求的不存在的数据也缓存起来
7. 分布式缓存架构
1. JBoss Cache
2. Memcached
2. 异步操作
3. 使用集群 负载均衡
4. 代码优化
1. 多线程
   假设服务器上执行的都是相同的任务，针对该类任务启动的线程格式可以参考
   启动线程数 = [任务执行时间 / (任务执行时间 -IO等待时间)] * CPU 内核数
   启动线程数和CPU 内核数量成正比，和IO阻塞时间成反比。如果任务都是cpu计算型任务，那么线程多不能超过Cpu内核数
   在编程上面解决线程安全的主要手段：
1. 将对象状态设计为无状态对象
2. 使用局部对象
3. 并发访问资源时使用锁
2. 资源复用
   资源复用主要模式
1. 单例模式
2. 对象池 (线程池和连接池)
3. 数据结构
4. 垃圾回收 了解垃圾回收机制，尽量避免Full GC
4. 存储性能优化
1. 建议使用固态硬盘
2. B+ 树是一种专门针对磁盘存储而优化的N叉排序树，以树节点为单位存储在磁盘中
   LSM树
3. RAID(廉价磁盘冗余阵列) VS. HDFS

网站的高可用架构

1. 网站可用性的度量与考核
1. 网站的可用性度量
1. 网站不可用时间(故障时间) = 故障修复时间点-故障发现时间点
2. 网站年度可用性指标 = (1-网站不可用时间/年度总时间) *
2. 网站可用性考核
   故障分 = 故障时间(分钟) * 故障权重
2. 高可用网站架构
   高可用架构的主要手段是数据和服务的冗余备份及失效转移，一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘读取数据
   一个典型的网站设计通常分为三层，各层之间具有相对独立性
1. 应用层 主要负责具体业务逻辑处理
2. 服务层 可复用的服务
3. 数据层 数据的存储与访问
3. 高可用的应用
   应用的无状态性
1. 通过负载均衡进行无状态服务的失效转移
2. 应用服务器集群的session管理
1. session复制
2. session绑定
3. 使用cookie记录session
4. session服务器
4. 高可用的服务
   可复用的服务和应用一样，是无状态的服务，可以使用类似负载均衡的失效转移策略实现高可用服务
   可以的服务策略
1. 分级管理
2. 超时设置
3. 异步调用
4. 服务降级
1. 拒绝服务
2. 关闭功能
5. 幂等性设计
   在服务层保证服务重复调用和调用一次产生的结果相同
5. 高可用的数据
1. CAP原理

   高可用数据有如下几个层面的含义：
1. 数据持久性
2. 数据可访问性
3. 数据一致性
CAP认为，一个提供数据服务的存储系统无法同时满足数据一致性、数据可用性、分区耐受性(系统具有跨网络分区的伸缩性)，在大型网站中，通常会选择强化分布式存储系统的可用性和伸缩性在某种程度上放弃一致性
数据一致性分为：
1. 数据强一致
2. 数据用户一致
3. 数据终一致
2. 数据备份
1. 数据冷备
2. 数据热备
1. 异步热备方式
2. 同步热备方式
3. 失效转移
1. 失效确认
   系统确认一台服务器是否宕机的手段：
1. 心跳检测
2. 应用程序访问失败报告
2. 访问转移
3. 数据恢复
6. 高可用网站的软件质量
1. 网站发布
   相当于给飞行中的飞机换个引擎，既不能让飞机有剧烈晃动(影响用户体验)，也不能让飞机降落(系统停机维护)，更不能让飞机坠毁(系统故障网站完全不可用)
2. 版本控制
1. svn
2. git
3. 自动化发布
   灰度发布：在部分服务器上发布新版本，其余服务器保持老版本(或发布另一个版本)，然后监控用户操作行为，手机用户体验报告，比较用户对两个版本的满意度，以确定终的发布版本
7. 网站运行监控
1. 监控数据采集
1. 用户行为日志收集 storm工具
   指用户在浏览器上所做的所有操作及其所在的操作环境，包括用户操作系统与浏览器版本信息，ip地址、页面访问路径、页面停留时间等。
1. 服务器端日志收集
2. 客户端浏览器日志收集
2. 服务器性能监控
   Ganglia
3. 运行数据报告
2. 监控管理
1. 系统报警
2. 失效转移
3. 自动优雅降级

网站的伸缩性架构

1. 网站架构的伸缩性设计
1. 不同功能进行物理分离实现伸缩
1. 纵向分离 将业务处理流程上的不同部分分离部署，实现系统伸缩性
2. 横向分离 将不同的业务模块分离部署，实现系统伸缩性
2. 单一功能通过集群规模实现伸缩
   相同服务部署在多台服务器上构成一个集群对外提供服务
2. 应用服务器集群的伸缩性设计
   负载均衡
1. http 重定向负载均衡
2. dns域名解析负载均衡
3. 反向代理负载均衡 反向代理服务器需要配置双网卡和内外部两套ip地址，反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈
4. ip负载均衡 在内核进程中完成数据分发，交反向代理负载均衡有更好的性能。但是由于所有请求响应都需要经过负载均衡服务器，集群的响应数据吞吐量不得不受制于负载均衡服务器的网卡和带宽
5. 数据链路层负载均衡 (三角传输模式) LVS
6. 负载均衡算法
3. 分布式缓存集群的伸缩性设计
   必须让新上线的缓存服务器对整个分布式缓存集群影响小
1. memcached分布式缓存集群
2. 对于服务器集群的管理，路由算法至关重要，和负载均衡算法一样，决定着究竟该访问集群中的哪台服务器
3. 余数hash路由算法
4. 在网站访问量少的时候，扩容缓存服务器集群，，这时候对数据库的负载小，通过模拟请求的方法逐渐预热缓存
5. 分布式缓存的一致性hash算法 一台物理服务器 虚拟为 150 左右各虚拟服务器合适
4. 数据存储服务器集群的伸缩性设计
1. 关系数据库集群的伸缩性设计
1. 数据库的数据复制功能
2. 数据分库 制约条件时 跨库的表不能进行join操作
3. 支持数据分片的分布式关系数据库产品 ： Amoeba 和 Cobar
   应用于服务器和数据库之间
4. Cobar 以 数据库为单位进行数据迁移的
2. NoSQL数据库的伸缩性设计
   nosql 数据库产品放弃了关系数据库的两大重要基础：
1. 以关系代数为基础的结构话查询语言
2. 事务一致性保证
3. HBase (借助可伸缩的HDFS分布式文件系统) 数据以HRegion为单位进行管理
4. 这个世界只有遇不到的问题，没有解决不了的问题，高手之所以成为高手，是因为他们遇到了常人很难遇到的问题，并解决了。

网站的可扩展架构

1. 构建可扩展网站架构
   将一个大系统切分成N个低耦合的子模块的能力，这些子模块包括横向的业务模块也包含纵向的基础模块
2. 利用分布式消息队列降低系统耦合性
1. 事件驱动架构 : 通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作
2. 常见的是 ： 分布式消息队列
   Apache ActiveMQ
3. 利用分布式服务打造可复用的业务平台
   分布式服务通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用
   拆分，降低系统耦合性
1. web service 与企业级分布式服务
   缺点：
1. 臃肿的注册和发现机制
2. 低效的xml序列化手段
3. 开销相对较高的http远程通信
4. 复杂的部署与维护手段
2. 大型网站分布式服务的需求与特点：
1. web service
2. 负载均衡
3. 失效转移
4. 高效的远程通信
5. 整合异构系统
6. 对应用少侵入 是否使用分布式服务需要根据业务发现规划
7. 版本管理
8. 实时监控
3. 分布式服务框架设计 Thrift 及 Dubbo
4. 可扩展性的数据结构
5. 利用开放平台建设网站生态圈

网站的安全架构

1. 网站应用攻击与防御
1. ModSecurity 开源的web防火墙
2. 信息加密技术及密钥安全管理
1. 改善密钥安全性的手段
1. 将密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设施，对外提供加密和解密服务
2. 将加密算法放在应用系统中，密钥则放在独立服务器中，实际存储时密钥被切分成数片，加密后分别保存在不同存储介质中
3. 信息过滤与反垃圾
1. 文本匹配
1. trie 算法
2. 构造多级Hash表进行文本匹配(缺点：浪费部分内存空间)
2. 分类算法
1. 贝叶斯分类算法
2. TAN算法
3. ARCS算法
分类算法除了用于反垃圾，还可用于信息自动分类。
3. 黑名单
1. hash表
2. 布隆过滤器 (不适合用于判断)
4. 电子商务风险控制
1. 风控
1. 规则引擎
2. 统计模型

案例

1. wikipedia
1. wikipedia CDN缓存的几条准则:
1. 内容不包括动态信息，以免页面内容缓存很快失效或包含过时信息
2. 每个内容页面有的rest风格的url，一遍cdn快速查找并避免重复缓存
3. 在html响应头写入缓存控制信息，通过应用控制内容是否缓存及缓存有效期
2. 服务端性能优化
1. 使用APC (php 缓存字节码缓存模块)
2. 使用Imagemagick进行图片处理和转化
3. 使用Tex进行文本格式化
4. 替换php的字符串查找函数 strstr()，使用更优化的算法重构
3. 后端性能优化

   后端优化主要的手段是使用缓存，将热点数据缓存在分布式缓存系统的内存中
1. 热点特别集中的数据直接缓存到应用服务器的本地内存中
2. 缓存数据的内容尽量是应用服务器可以直接使用的格式，以减少应用服务器从缓存中获取数据后解析构造数据的代价
3. 使用缓存服务器存储session对象
4. memcached的持久化连接非常廉价，如果有需要就创建一个
对于存储核心的mysql数据库的优化:
1. 使用较大的服务器内存
2. 使用RAID0磁盘阵列以加速磁盘访问 （加速磁盘访问，降低了数据库的持久可靠性）
3. 将数据库事务一致性设置在较低水平，加快宕机恢速度
4. 如果Master 数据库宕机，立即将应用切换到Salve数据库，同时关闭数据写服务
2. 网购秒杀系统架构

   秒杀业务不能使用正常的业务流程，也不能和正常的网站交易业务共用服务器，必须设计部署专门的秒杀系统进行专门应对
1. 秒杀系统的解决多用户抢购的问题策略：
1. 秒杀系统独立部署
2. 秒杀商品页面静态化
3. 租借秒杀活动网络带宽
4. 动态生成随机下单页面url