第二章 大型网站架构模式
模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用（类似于设计模式中的模式）。
2.1 网站架构模式
2.1.1 分层
将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
在大型网站架构中也采用分层结构，将网站软件系统分为应用层、服务层、数据层等。
优势：便于分工合作开发和维护
挑战：必须合理规划层次边界和接口，以及在开发过程中要严格遵循分层架构的约束，禁止跨层次的调用以及逆向调用。
2.1.2 分割
在纵向方面对软件进行切分。分割形成高内聚低耦合的模块单元。
2.1.3 分布式
对于大型网站，分层和分割的一个主要目的就是为了切分后的模块便于分布式部署。
分布式可能遇到的问题：
\1. 网络延迟的影响
\2. 服务器宕机
\3. 数据一致性保证
\4. 开发维护的问题
在网站应用中，常见的分布式方案有以下几种：
- 分布式应用和服务
- 分布式静态资源
- 分布式数据和存储（传统的关系数据库分布式部署 / NoSQL ）
- 分布式计算（MapReduce）
2.1.4 集群
将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
2.1.5 缓存
- CDN
- 反向代理
- 本地缓存：在应用服务器本地缓存这热点数据
- 分布式缓存：将数据缓存在一个专门的分布式缓存集群中
2.1.6 异步
在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署。
- 网站扩展新功能非常便利
- 提高系统可用性
- 加快网站响应速度
- 消除并发访问高峰：将突然增加的访问请求数据加入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力
2.1.7 冗余
服务器冗余运行+数据冗余备份
数据库——冷备份+热备份
灾备数据中心
2.1.8 自动化
2.1.9 安全
2.2 架构模式在新浪微博的应用
第三章 大型网站核心架构要素
这一章主要是高屋建瓴，这个思维导图非常全面
第四章
性能测试指标：
响应时间
并发数
吞吐量：TPS（每秒事务数），HPS（每秒HTTP请求数）,QPS（每秒查询数）。吞吐量随着并发数的变化先是逐渐增加，达到一个集先后随着并发数下降，最后系统资源耗尽，打出gg。这个过程中响应时间显示小幅上升，达到吞吐量集先后快速上升，最后达到崩溃点
性能计数器：一些描述系统性能的指标，包括system Load等。system load是当前被执行cpu执行的和等待被执行的进程数的总和，理想情况下该值应该等于cpu的数量
a-b，系统正常运行区间，c点是系统最大负载点，d是系统崩溃点
web端优化
- 浏览器访问优化：
- 减少http请求：因为http是无状态的，每次请求的开销都比较昂贵（需要建立通信链路、进行数据传输，而服务器端对于每个http请求都需要启动独立的线程去处理）；减少http的主要手段是合并CSS、合并JS、合并图片（CSS精灵，利用偏移定位image）；
- 使用浏览器缓存：设置http头中Cache-Control和Expires属性；
- 启用压缩：可以对html、css、js文件启用Gzip压缩，可以达到较高的压缩效率，但是压缩会对服务器及浏览器产生一定的压力；
- CSS放页面最上面，JS放页面最下面：浏览器会在下载完全部CSS之后才开始对整个页面进行渲染，因此最好将CSS放在页面最上面；而浏览器在加载JS后会立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此最好将JS放在页面最下面；
- 减少Cookie传输：一方面，太大的Cookie会严重影响数据传输；另一方面，对于某些静态资源的访问（如CSS、JS等）发送Cookie没有意义；
- CDN加速：
- 反向代理：
后端优化
- 分布式缓存：memcached
- 异步操作
- 分布式
- 代码优化
- 多线程
- 资源复用（单例和对象吃）
- 数据结构
- 垃圾回收调优（java）
- 存储优化
第五章 网站的高可用架构
考量方式：故障分=故障等级*故障权重
网站升级时也会宕机，设计时也需要考虑这一点。
典型架构：应用层，服务层，数据层
高可用的应用
应用层的特点是无状态，多个服务实力完全对等。
- 无状态服务：通过负载均衡进行无状态的失效转移
- 有状态服务，通常通过session管理状态，常用以下四种方式管理session
- session复制。在不同服务器间复制session，只适用于小项目
- session绑定：其实是用hash等思想将相同session发送大同一服务器，扩展性好，但是不支持高可用
- 利用cookie记录session：受cookie大小限制；每次请求都需要传输cookie，影响性能。
- session服务器：session用分布式存储独立维护，应用服务器每次拿到请求去session服务器查找
高可用的服务
- 分级管理，不同服务隔离
- 超时设置
- 异步调用
- 服务降级
- 幂等性设计
高可用数据
数据备份，失效转移等。
高可用QA
- 网站发布：在柔性的发布过程中，每次关闭的服务都是集群中的一小部分，并在发布完成后立即可以访问；
- 自动化测试：使用自动测试工具或脚本完成测试；
- 预发布验证：引入预发布服务器，与正式服务器几乎一致，只是没有配置在负载均衡服务器上，外部用户无法访问；
- 灰度发布：每次只发布一小部分
网站监控
- 监控数据采集
- 用户行为日志收集：服务器端的日志收集和客户端的日志收集；目前许多网站逐步开发基于实时计算框架Storm的日志统计与分析工具；
- 服务器性能监控：收集服务器性能指标，如系统Load、内存占用、磁盘IO等，及时判断，防患于未然
- 运行数据报告：采集并报告，汇总后统一显示，应用程序需要在代码中处理运行数据采集的逻辑；
- 监控管理
- 系统报警：配置报警阀值和值守人员联系方式，系统发生报警时，即使工程师在千里之外，也可以被及时通知；
- 失效转移：监控系统在发现故障时，主动通知应用进行失效转移；
- 自动优雅降级：为了应付网站访问高峰，主动关闭部分功能，释放部分系统资源，保证核心应用服务的正常运行；—>网站柔性架构的理想状态
第六章 网站的伸缩性架构
负载均衡
- Http重定向
- DNS域名解析负载均衡
- 反向代理负载均衡（反向的意思是代理的目标只有一个，客户有多个）
- ip负载均衡
- 数据链路层负载均衡
分布式缓存：一致性hash可以通过虚拟层来解决服务器负载不均衡的问题
关系型数据库
- 主从
- 分片（amoeba，cobar）
NoSQL
第七章 网站的可扩展架构
分布式队列
利用分布式消息队列降低系统耦合性，采取事件驱动架构，在低耦合模块间传输事件消息完成模块间的合作并保持模块的松散。
分布式服务
巨无霸应用带来的问题：
- 编译，部署困难
- 代码分支管理困难
- 数据库连接耗尽
- 新增业务困难
分布式服务的框架需求
- 负载均衡
- 失效转移
- 高效的远程通信
- 证合一构系统
- 对应用最少侵入：即支持服务在分布式和集中式之间调整
- 版本管理
- 实时监控
典型框架 Dubbo
设计要点：
- 服务消费者程序通过服务接口使用服务，而服务接口通过代理价再具体服务，具体服务可以使本地代码，也可以是远程服务，因此对应用侵入较少：应用只需要调用服务接口，服务框架更具配置自动调用本地或者远程实现
- 服务框架客户端模块通过服务注册中心家在服务提供者列表，并根据负载均很策略选择将调用请求发送给某服务。服务调用失败客户端会自动选择另一台服务器重新请求服务，实现服务的自动失效转移，保证服务的高可用
- 使用NIO通信框架，支持多种通信协议和数据序列化协议，具有较高的网络通信性能
可扩展的数据结构
类似hbase的源数据组织方式：，创建表的时候，只需要指定ColumnFamily的名字，无需指定字段（Column），可以在数据写入时再指定，通过这种方式，数据表可以包含数百万的字段，使应用程序的数据结构可以随意扩展。
利用开放平台建设网站生态圈
第八章 网站的安全架构
常见攻击
- XSS
- 注入攻击
- CSRF跨站点请求伪造
加密技术
单向散列加密：比如加盐MD5
对称加密：加解密用同一个密钥，常用语需要安全交换或者储存的场合，如cookie加密和通信加密等。常用DES，RC等
非对称加密：公钥开发，私钥只有所有者知道。常用在信息安全传输，数字签名等。如RSA等
密钥安全管理：把密钥和算法做成独立服务，或者吧密钥单独存储
参考文献
http://www.cnblogs.com/edisonchou/p/3773828.html
本文采用创作共用保留署名-非商业-禁止演绎4.0国际许可证，欢迎转载，但转载请注明来自http://thousandhu.github.io，并保持转载后文章内容的完整。本人保留所有版权相关权利。