Martin L. Abbott，业界资深管理者，曾参与管理过多家世界500强企业和创业公司。AKF Partners公司创始人。曾任Quigo公司首席运营官（该公司后被AOL收购），eBay公司高级副总裁和首席技术官，还曾在Gateway和摩托罗拉担任重要职位。现任多家技术公司董事，多所高校、公共机构以及私企的咨询顾问。Martin分别于西点军校和佛罗里达大学取得计算机学士和硕士学位，并参加过哈佛大学商学院高级经理培训，目前在西储大学攻读博士学位。
    Michael T. Fisher，业界资深管理者，曾参与管理过多家世界500强企业和创业公司。AKF Partners公司创始人。曾任Quigo公司首席技术官、总裁，PayPal公司工程和架构部门副总裁。曾在通用电器工作7年，帮助制定公司的技术战略。目前担任多家私企和非营利机构的董事和顾问。Michael毕业于西点军校，是六西格玛黑带大师，目前在西储大学攻读博士学位。

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

    本书是Abbott 和 Fisher的又一力作，我想把它推荐给我们公司的所有工程师。对于处理在线业务可扩展性的每一位人士，本书必不可少。
    ——Chris Lalonde，Bullhorn公司副总裁

    Abbott和Fisher从实践出发，再次以独一无二的方式解决了扩展性难题。目前，网站设计要素错综复杂且不断增多，两人将这些难题和挑战总结为50条功能强大、简单易用的原则。可以说，本书是关于网站扩展性秘诀的秘籍，它能够指引读者穿越‘爆发式增长网络难题的迷雾’，创建扩展性优良的网站。
    ——Geoffrey Weber，Shutterfly公司副总裁

    50条原则是Abbott和Fisher多年智慧的结晶，运用这些原则可以避免网站的许多特殊问题。这套原则强大、令人信服！
    ——Jonathan Heiliger，Facebook副总裁

    化简方程
    在我们的学习或工作中，都曾遇到过这样的情况：死盯着一个复杂的问题不放，以至于最后丧失了希望。我们应该从何处入手？如何在预定的时间内解决问题？或者说得极端一些，如何在有生之年解决这个问题？要做的事情太多了，这个问题太过棘手，是不能解决的，事实如此，就此罢手吧。游戏结束了……
    等等，不要丧失希望。深呼吸，想想你的高中或者大学数学老师。就像解数学题，把大方程化简成易于计算的小方程一样，如果你遇到的是棘手的大型架构问题，那么可以把大问题分拆成小问题，把小问题分拆成更小的问题，直到这些问题可以轻易解决为止。
    我们的观点是，任何大问题，只要分拆方法正确，都不过是一系列有待解决的小问题的集合。这一章介绍的就是如何把大的架构问题分拆成小问题，用较少的工作实现同样的结果。在很多案例中，该方法都减少了（而不是增加了）解决问题所必需的工作量，简化了架构和解决方案，最终得到了更具可扩展性的解决方案或平台。
    本书各章所介绍的原则篇幅不一，复杂度也不同。有些普适的原则，适用于一个设计的多个方面。而有些原则只适合特定系统。
    1.1　原则1：不要过度设计
    目的：防止设计中出现复杂的解决方案。
    适用情形：适用于任何项目，所有大型的或复杂的系统和项目都应该采用该原则。
    应用方式：让同行来检查解决方案是否好理解，抵制过度设计的强烈欲望。
    应用理由：复杂的解决方案实施成本高，而且会产生大量长期成本。
    要点：过度复杂的系统会限制扩展能力。简单的系统更容易维护和扩展，且成本更低。
    维基百科解释说，过度设计分为两大类[1]。一类是指设计与实现超出了有用需求的产品。出于完整性的考虑，我们只简单地讨论一下这个问题。相对于第二类问题来说，这类问题对可扩展性的影响较小。过度设计的另一类问题指过于复杂的产品。如前所述，我们最关心的是第二类问题对可扩展性的影响。不过，还是先来了解一下第一个问题吧。
    要解释过度设计的第一类问题，即超出产品有用需求的问题，就要先搞清楚“有用的”这个术语的含义，这个术语在这里表示的只是“能够使用”。例如，为家庭住房设计一种空调，能够在室外温度为0开时把整个房子的温度加热到300华氏度，这毫无意义，纯属浪费，我们只需要一个能够在室外温度为 20华氏度时把房子加热到舒适温度的产品。这种过度设计会产生过度的成本，其中开发的成本会更高，实施该方案的硬件和软件成本也会更高。如果研发这种过度设计系统的时间比研发有用系统的时间更长，还可能拖延产品的发布，对公司造成进一步的影响。成本高，利润就低。研发时间长，收入或收益就会被延迟，所有这些成本都会影响到利益相关者。范围蔓延，或者最初的产品定义和最初的产品发布之间的范围差异，是过度设计的一种表现。
    说个更接近我们工作的例子，是开发一个员工打卡系统，这个系统能够处理的员工数量是整个地球上人数的100倍。在这个软件的使用期限内，地球上的人口升至100倍的可能性是微乎其微的，而所有人都为一家公司工作的可能性则更小。我们当然想让构建的系统满足客户需求，但也不想浪费时间来实现和部署远远超出需求的系统。
    过度设计的第二类表现是使系统过度复杂，或者用复杂的方式来实现它。简而言之，就是要花费过大的力气去完成一项工作，或者是让用户花费过大的力气去完成一项任务，或者是让程序员花费过大的力气去理解一个功能。让我们来逐一分析过度复杂的系统的这三种情况。
    什么是花费过大的力气去完成一项工作呢？现实世界有最简单的例子。假设你让某人去杂货店买东西，你告诉他，店里面的所有商品都拿一个，排队结账时给你打电话。等他打电话给你时，你再告诉他到底想要哪几个，让他从所拿的无数篮商品中选出来，然后把其他商品都倒在地上。你一定会说：“别开玩笑了。”可是，你在自己的代码中用过select (*) schema_name.table_name这样的SQL语句，只是为了从返回的集合中找出自己想要的结果吗（参见原则35）？我们这个杂货店的例子，和上述的select(*)正是异曲同工。在你的代码中，有几个条件语句是处理个别情况的，它们是按照什么顺序执行的？是不是最可能发生的情况最先执行？你是不是经常刚查询完一个结果，又重复查询一次？是不是经常刚显示了一个HTML页面，又重新创建它？这种情况（反复做一项工作）随处可见，却又经常被忽视，我们将专门用一章（第6章）来讨论这个主题。
    什么是让一位用户花费过大的力气去完成一项任务呢？答案非常简单。在许多情况下，少就是多。为追求系统的灵活性，我们总是想给它硬加上尽可能多的奇怪功能。但生活的情趣并不总在于多种多样。许多时候，用户只是想无干扰地尽可能快地从A到达B。如果你的市场中有99%的用户不需要把日志文件存成.pdf文件，那么就不要构建一个提示框询问他们是否想把日志文件保存成.pdf文件。如果你的用户想把.wav文件转换成MP3文件，那么他们已经不在乎损失精度了，所以不必再提示他们转换成无损压缩的FLAC文件，那样只会干扰他们。
    最后一种情况，就是软件复杂得让其他程序员难以理解。创建复杂的代码让他人难以理解曾经非常流行（还有过比赛）。有时，代码写得复杂，是为了让它比一般程序员所开发的代码运行更快。而更多的情况是，代码的复杂度（就其理解的难度而言）成了程序员才华的象征，或者说是功夫高低的象征。那些开发的代码能让做代码检查的高级开发人员欲苦无泪的人反而颇受推崇。复杂度成了智慧的牢笼，编程极客们会在公司内部争强好胜。对于乐此不疲的人来说，这是很好的比赛，但对于公司和股东来说，则要为一场无人关心的牢笼大赛买单。对于那些仍然沉浸于这场极客盛宴的人，如果不想损害利益相关者的利益，又想真刀真枪地拼一场，那建议你参加国际混淆C代码竞赛，网址是www0.us.ioccc.org/ main.html。
    我们都应该努力去写让每个人都能理解的代码。衡量一个伟大程序员的真正标准，是他能够多快把一个复杂的问题简化（见原则3），多快能开发出一个既容易理解，又容易维护的解决方案。容易执行的解决方案意味着一般程序员就可以快速地掌握系统，为它提供支持。容易理解的解决方案则意味着在查找问题时能够更快地发现问题，从而以更快的方式把系统恢复到正常工作状态。容易执行的解决方案可以提高公司和解决方案的可扩展性。
    要测试系统是否太复杂，一个很好的方法是让负责解决复杂问题的程序员把他的解决方案陈述给公司内的一组程序员。这组程序员应该代表公司内不同的编码水平，不同的工作年限（加入这一条，是因为可能有些有经验的程序员在公司的工作经验不多）。要通过这一测试，需要这组程序员中的每一位都能够轻松理解该解决方案，能够在无帮助的情况下向他人描述它，而不只是知道它。如果这组程序员中的任何一位不能理解该解决方案，那么就要小组讨论该系统是不是过度复杂了。
    过度设计是可扩展性的一个敌人。开发一个超出有用需求的解决方案，既浪费金钱又浪费时间。此外，还可能进一步浪费处理资源，增加扩展成本，限制系统的整体扩展能力（即系统能被扩展到什么程度）。构建过度复杂的解决方案会造成类似的后果。运行吃力的系统会增加成本，限制最终发展规模。让用户用起来吃力的系统，会放慢吸引客户的速度，从而限制业务增长的速度。太复杂以至于难以理解的系统，则会扼制公司的生产力，让你无从增加程序员，或者难以给系统增加功能。
    ……

第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　小结