高扩展性网站的50条原则

内容简介

网站建设是一项复杂的工程，随着规模的扩大，许多网站势必会遇到严重的性能和可扩展性问题。大量用户涌入时如何保证网站不崩溃？如何缩短页面载入时间？这都是摆在网站开发和运维人员面前迫待解决的问题。
　 《高扩展性网站的50条原则》作者凭借他们在世界上业务流量的网站中积累的管理经验，针对性能测试到IT管理等诸多实际问题，总结出了高扩展性网站建设的50条原则。这些原则适用于所有前端和后端系统，帮助你应对规模迅速增大的网站。
　 本书主要内容包括：
　 通过克隆、复制、分离功能和拆分数据集提高网站扩展性；
　 采用横向扩展方案代替纵向扩展；
　 在不损害网站可扩展性的前提下，程度地利用数据库；
　 避免不必要的重定向和冗余的二次检查；
　 在不引入复杂性的前提下，更加充分地使用缓存和内容分发网络；
　 要求网站设计具备容错、优雅降级和易回滚的功能；
　 设计系统时尽可能选择无状态实现，如果确实需要状态，做到合理；
　 有效利用异步通信；
　 无论你的网站刚刚起步，还是正在设计开发过程中，或者已经成熟运转了很长时间，你都能从书中找到很有针对性的指导原则，提高网站的可扩展性。

目录

第1章　化简方程
1.1　原则1：不要过度设计
1.2　原则2：设计时就考虑扩展性（D-I-D方法）
1.2.1　设计
1.2.2　实现
1.2.3　部署
1.3　原则3：把方案一简再简
1.3.1　如何简化范围
1.3.2　如何简化设计
1.3.3　如何简化实施
1.4　原则4：减少DNS查找
1.5　原则5：尽可能减少对象
1.6　原则6：使用同一品牌的网络设备
1.7　小结
参考资料
第2章　分布工作
2.1　原则7：横向复制（X轴原则）
2.2　原则8：拆分不同的东西（Y轴原则）
2.3　原则9：拆分相近的东西（Z轴原则）
2.4　小结
参考资料
第3章　横向扩展设计
3.1　原则10：设计横向扩展方案
3.2　原则11：采用经济型系统
3.3　原则12：横向扩展数据中心
3.4　原则13：利用云技术进行设计
3.5　小结
参考资料
第4章　使用正确的工具
4.1　原则14：合理使用数据库
4.2　原则15：防火墙，到处都是防火墙
4.3　原则16：积极利用日志文件
4.4　小结
参考资料
第5章　不要重复工作
5.1　原则17：不要立即检查刚做过的工作
5.2　原则18：停止重定向
5.3　原则19：放松时序约束
5.4　小结
参考资料
第6章　积极利用缓存
6.1　原则20：利用CDN
6.2　原则21：使用过期头
6.3　原则22：缓存Ajax调用
6.4　原则23：利用页面缓存
6.5　原则24：利用应用缓存
6.6　原则25：利用对象缓存
6.7　原则26：把对象缓存放在自己的"层"上
6.8　小结
参考资料
第7章　从错误中吸取教训
7.1　原则27：积极地学习
7.2　原则28：不要依靠QA发现失误
7.3　原则29：没有回退功能的设计是失败的设计
7.4　原则30：讨论失败并从中吸取教训
7.5　小结
参考资料
第8章　数据库原则
8.1　原则31：注意代价高的关系
8.2　原则32：使用类型正确的数据库锁
8.3　原则33：不要使用多阶段提交
8.4　原则34：不要使用SELECTFORUPDATE
8.5　原则35：不要选择所有数据
8.6　小结
参考资料
第9章　容错设计与故障控制
9.1　原则36：采用隔离故障的"泳道"
9.2　原则37：不要信任单点故障
9.3　原则38：避免系统串联
9.4　原则39：确保能够启用/禁用功能
9.5　小结
第10章　避免或分发状态
10.1　原则40：努力实现无状态
10.2　原则41：尽可能在浏览器端维护会话
10.3　原则42：利用分布式缓存存放状态
10.4　小结
参考资料
第11章　异步通信和消息总线
11.1　原则43：尽可能使用异步通信
11.2　原则44：确保消息总线能够扩展
11.3　原则45：避免让消息总线过度拥挤
11.4　小结
第12章　其他原则
12.1　原则46：慎用第三方解决方案扩展
12.2　原则47：清除、归档和成本合理的存储
12.3　原则48：删除事务处理中的商业智能
12.4　原则49：设计能够监控的应用
12.5　原则50：要能胜任
12.6　小结
参考资料
第13章　原则回顾和优先级划分
13.1　评估扩展项目和主动权的风险?收益模型
13.2　扩展原则的收益/优先级等级
13.3　小结

摘要与插图

化简方程
　 在我们的学习或工作中，都曾遇到过这样的情况：死盯着一个复杂的问题不放，以至于丧失了希望。我们应该从何处入手？如何在预定的时间内解决问题？或者说得一些，如何在有生之年解决这个问题？要做的事情太多了，这个问题太过棘手，是不能解决的，事实如此，就此罢手吧。游戏结束了……
　 等等，不要丧失希望。深呼吸，想想你的高中或者大学数学老师。就像解数学题，把大方程化简成易于计算的小方程一样，如果你遇到的是棘手的大型架构问题，那么可以把大问题分拆成小问题，把小问题分拆成更小的问题，直到这些问题可以轻易解决为止。
　 我们的观点是，任何大问题，只要分拆方法正确，都不过是一系列有待解决的小问题的集合。这一章介绍的就是如何把大的架构问题分拆成小问题，用较少的工作实现同样的结果。在很多案例中，该方法都减少了（而不是增加了）解决问题所的工作量，简化了架构和解决方案，得到了更具可扩展性的解决方案或平台。
　 本书各章所介绍的原则篇幅不一，复杂度也不同。有些普适的原则，适用于一个设计的多个方面。而有些原则只适合特定系统。
　 1.1　原则1：不要过度设计
　 目的：防止设计中出现复杂的解决方案。
　 适用情形：适用于任何项目，所有大型的或复杂的系统和项目都应该采用该原则。
　 应用方式：让同行来检查解决方案是否好理解，抵制过度设计的强烈欲望。
　 应用理由：复杂的解决方案实施成本高，而且会产生大量长期成本。
　 要点：过度复杂的系统会限制扩展能力。简单的系统更容易维护和扩展，且成本更低。
　 维基百科解释说，过度设计分为两大类[1]。一类是指设计与实现超出了有用需求的产品。出于完整性的考虑，我们只简单地讨论一下这个问题。相对于第二类问题来说，这类问题对可扩展性的影响较小。过度设计的另一类问题指过于复杂的产品。如前所述，我们心的是第二类问题对可扩展性的影响。不过，还是先来了解一下第一个问题吧。
　 要解释过度设计的第一类问题，即超出产品有用需求的问题，就要先搞清楚“有用的”这个术语的含义，这个术语在这里表示的只是“能够使用”。例如，为家庭住房设计一种空调，能够在室外温度为0开时把整个房子的温度加热到300华氏度，这毫无意义，纯属浪费，我们只需要一个能够在室外温度为 20华氏度时把房子加热到舒适温度的产品。这种过度设计会产生过度的成本，其中开发的成本会更高，实施该方案的硬件和软件成本也会更高。如果研发这种过度设计系统的时间比研发有用系统的时间更长，还可能拖延产品的发布，对公司造成进一步的影响。成本高，利润就低。研发时间长，收入或收益就会被延迟，所有这些成本都会影响到利益相关者。范围蔓延，或者的产品定义和的产品发布之间的范围差异，是过度设计的一种表现。
　 说个更接近我们工作的例子，是开发一个员工打卡系统，这个系统能够处理的员工数量是整个地球上人数的100倍。在这个软件的使用期限内，地球上的人口升至100倍的可能性是微乎其微的，而所有人都为一家公司工作的可能性则更小。我们当然想让构建的系统满足客户需求，但也不想浪费时间来实现和部署远远超出需求的系统。
　 过度设计的第二类表现是使系统过度复杂，或者用复杂的方式来实现它。简而言之，就是要花费过大的力气去完成一项工作，或者是让用户花费过大的力气去完成一项任务，或者是让程序员花费过大的力气去理解一个功能。让我们来逐一分析过度复杂的系统的这三种情况。
　 什么是花费过大的力气去完成一项工作呢？现实世界有单的