高扩展性网站的50条原则

简化方程

　　1 不要过度设计

　　　　应用方式：让同行来检查解决方案是否好理解，抵制过度设计的强烈欲望

　　　　两种分类：1 设计与实现超出了有用需求的产品 2 过于复杂的产品

　　2 设计时就考虑扩展性

　　　　应用方式：* 设计20倍的容量 * 实现3倍的容量 * 部署约1.5倍的容量

　　3 把方案一简再简

　　　　应用方式：1 用帕累托法则(20—80)简化范围，

　　　　　　　　　2 从成本效率和可扩展性出发简化设计

　　　　　　　　   3 利用他人的经验简化实施

　　4 减少DNS查找

　　　　应用方式：减少下载页面所需的DNS查找，不过要权衡考虑浏览器对同时连接的限制

　　　　要点：减少对象、任务、计算等都可以加速页面载入，但同时也要考虑工作分解

　　5 尽可能减少对象

　　　　应用方式：* 减少或合并对象，但要与最大同时连接数进行平衡

　　　　　　　　　* 测试修改过的页面，确保性能提高了

　　　　要点：在必要的内容和功能、对象大小、显示时间、总下载时间、域等因素之间，都要进行平衡

　　6 使用同一品牌的网络设备

　　　　要点：不同品牌的网络设备可能会造成可用性和扩展性问题，最好只选择一个供应商

 

 

 

 

分布工作

　　7 横向复制

　　　　目的：复制服务或数据库来分散事务负载

　　　　适用情形：* 具有非常高读写比例的数据库

　　　　　　　　　* 事务增长大于数据增长的系统

　　　　应用方式：* 只需克隆服务并实施负载均衡

　　　　　　　　　* 对于数据库，要确保访问代码能够区分读写操作　　

　　　　数据的时间敏感度：对于数据的写副本来说，只读副本有多么新，或者是否完全正确

　　　　分布数据的方法：1 在数据库前端使用缓存层，每次查询读取缓存

　　　　　　　　　　　　2 复制数据库来拆分数据

　　8 拆分不同的东西

　　　　目的：有时该原则被称为通过服务或资源进行扩展，重点是扩展数据集合、事务和程序员小组

　　　　适用情形：* 非常大的数据集合，数据间关系并不重要

　　　　　　　　　* 大型的复杂系统，需要特别扩展编程资源

　　　　应用方式：* 用动词拆分操作，用名词拆分资源，或者兼而有之

　　　　　　　　　* 根据动词/名词方法的定义，拆分服务和数据

　　　　应用理由：不仅能有效地扩展事务，还能有效地扩展与事务相关的大型数据集合

　　　　要点：面向数据/服务的拆分，能够有效地扩展事务、大型数据集合，并且有助于故障隔离

　　　　面向服务的架构(SOA)和面向资源的架构(ROA)，大体上就是采用动词(服务)和名词(资源)的概念来实现拆分

　　9 拆分相近的东西(数据分片)

　　　　目的：通常可以利用客户特有的属性进行拆分

　　　　适用情形：非常大的相似数据集合

　　　　应用方式：根据属性拆分数据和服务

　　　　应用利用：部分数据增长速度超过了其他所有数据的增长

 

 

 

横向扩展设计

　　10 设计横向扩展方案

　　　　目的：横向扩展，通过复制服务或数据库来分散事务负载，而纵向扩展即购买更大的硬件，前者通常代替后者

　　11 采用经济型系统

　　12 横向扩展数据中心

　　　　目的：设计具有三个或更多实时数据中心的系统，以减少整体成本、提高可用性以及实现灾难恢复

　　　　适用情形：任何考虑加入灾难恢复(冷备份)数据中心的公司

　　　　应用方式：采用“多个实时数据中心”的配置，拆分数据，分散到这些数据中心，把事务负载也分散到这些数据中心

　　　　应用理由：通常设计为三个或更多个数据中心，成本比只有两个数据中心低，在高峰时利用闲置的容量，而不是降低处理事务的速度

　　　　要点：

　　13 利用云技术进行设计

　　　　适用情形：临时的、激增的或者间歇性的需求，或者产品响应时间并非关键因素的情况

 

 

 

 

使用正确的工具

　　14 合理使用数据库

　　　　应用方式：在选择最合适的存储工具时，要考虑数据量、存储空间、响应时间的要求、关系以及其他多种因素

　　　　应用理由：RDBMS提供了最好的事务完整性，但相对于其他存储选择，这种数据库很难扩展且扩展成本高，可用性低

　　　　RDBMS的好处：1 利用ACID属性确保了事务完整性 2 表内和表间的关系型结构

 　　　　即不要求数据间的关系，也不要求事务完整性的数据，最好采用其他的存储系统

　　　　如果不会发生读写冲突，不需要维护大量的数据关系，并不真正用到数据库事务，那么采用文件系统才是最好的选择

　　15 防火墙

　　16 积极利用日志文件

　　　　目的：诊断问题并防止问题出现

　　　　适用情形：落实监控日志文件的流程，强制人们对发现的问题采取措施

　　　

 

 

 

不要重复工作

　　17 不要立即检查刚做过的工作

　　　　应用理由：验证工作相对于不太能出现的故障来说成本更高

　　18 停止重定向

　　19 放松时序约束

　　　　应用方式：放松业务原则中的约束

　　　　应用理由：由于大多数RDBMS的ACID属性，扩展具有时序约束的系统非常困难

　　　　要点：虽然某些特殊情况可能会令客户失望，但是弥补客户比起不能扩展来说容易得多　

　　　　

 

 

积极利用缓存

　　20 利用CDN

　　　　应用方式：大多数CDN利用DNS，从而替站点来提供内容

　　　　应用理由：CDN有助于分流高峰期的流量，通常是扩展站点部分流量的经济型方法

　　　　要点：总体来说，CDN可以简单快速地分散流量高峰和流量增长。确保做成本效益分析，监控CDN使用

　　　　CDN：一组计算机的集合，这些计算机称为节点或边缘服务器，连结它们的网络叫做主干网，这些节点上保存有客户数据或

　　　　　　　内容的副本，CDN可以将请求发送到最适合响应的节点，这种优化可以通过最小的网络跳数、最高的可用性或最小的

　　　　　　　请求数来实现，重点是减少最终用户、请求者感知的服务响应时间

　　21 使用过期头

　　　　目的：减少请求，提高系统的可扩展性和性能

　　　　应用理由：减少对象请求可以提高页面性能，减少系统必须处理的每个用户的请求数

　　　　要点：考虑每种对象类型可以缓存多久，从而正确设置过期头

　　22 缓存Ajax调用

　　23 利用页面缓存

　　24 利用应用缓存

　　25 利用对象缓存

　　26 自己建缓存层

 

 

 

从错误中吸取教训

　　27 积极的学习

　　28 不要依靠QA发现失误

　　29 没有回退功能的设计是失败的设计

　　30 讨论失败并从中吸取教训

 

 

 

 

数据库原则

　　31 注意代价高的关系

　　32 使用类型正确的数据库锁

　　33 不要使用多阶段提交

　　　　应用理由：多阶段提交协议是一种阻断提议，在他完成之前，其他事务不能执行

　　34 不要使用select for update

　　35 不要选择所有数据

 

 

 

容错设计和故障控制

 

 

避免和分发状态

　　40 努力实现无状态

　　41 尽可能在浏览器端维护会话

　　　　应用方式：采用cookie在用户浏览器中存放会话数据

　　42 利用分布式缓存存放状态

　　　　目的：在系统中存储会话数据时，使用分布式缓存

　　　　应用理由：认真考虑如何存储会话数据可以确保系统能够持续扩展

　　　　一些基本原则：

　　　　　　1 不要实现要求关联到服务器的系统

　　　　　　2 不要使用状态或会话服务，在不同的系统中创建重复的数据

　　　　　　3 最好把会话信息放在自己的服务器层上

 

 

 

 

异步通信和消息总线

　　43 尽可能使用异步通信

　　44 确保消息总线能够扩展

　　　　目的：当需求过大发生故障，它们也需要扩展

　　　　应用方式：* 根据服务或消息的属性划分 * 根据客户、用户或站点属性划分

　　45 避免让消息总线过度拥挤

　　　　目的：让总线流量仅限于价值高于处理成本的数据

　　　　应用方式：减少低价值高成本的流量

 　　

 

 

 

其他原则

　　46 慎用第三方解决方案扩展