前 言
感谢你对本书第2版感兴趣！作为一本入门、进修和轻量级的参考手册，本书旨在帮助工程师、架构师和管理者研发及维护可扩展的互联网产品。本书给出了一系列规则，每个规则围绕着不同的主题展开讨论。大部分的规则聚焦在技术上，少数规则涉及一些关键的思维或流程问题，每个规则对构建可扩展的产品都是至关重要的。这些规则在深度和焦点上都有所不同。有些规则是高级的，例如定义一个可以应用于几乎任何可扩展性问题的模型；其他的则比较具体，可能用来解释一种技术，例如怎么修改HTTP头来最大化内容缓存。在本版中，我们增加了成功的互联网产品公司中首席技术官和企业家的故事，这里涉及的公司既包括初创企业也有财富500强公司。这些故事有助于说明规则是如何形成的，以及它们为什么在海量事务处理环境中显得如此重要。没有什么其他故事可以比亚马逊更能说明在互联网上急速扩展所遇到的需求和挑战。里克·达尔泽尔是亚马逊的第一位首席技术官，在本书中他用自己的故事阐述了几个规则。
驯服互联网的狂野西部
从创新和行业破坏的角度来看，很少有像亚马逊这样成功的公司。自1994年成立以来，亚马逊所做出的贡献已经重新定义了至少三个行业：消费者商务、印刷出版和服务器托管。亚马逊的所作所为已经远远超出了行业破坏；他们一直是面向服务架构、研发团队建设和无数其他工程方法的思想领袖。亚马逊的规模和全维度的业务扩展令人难以置信；该公司以传统实体企业难以想象的速度不断成长。自1998年以来，亚马逊从年收入6亿美元（根本就不是小企业）增长到2015年惊人的1070亿美元［1］。2015年世界上最大的零售商是沃尔玛，其年销售额为4857亿美元［2］。但是沃尔玛自1962年以来就一直存在，它花了35年的时间使销售额攀升到1000亿美元，而亚马逊却只用了21年。如果没有一个或几个出自亚马逊的故事，那些自称编纂的是来自于首席技术官口中并由他们创造的可扩展性规则的书将是不完整的。
杰夫·贝佐斯于1994年7月建立了亚马逊（原名Cadabra），并在1995年推出Amazon.com作为在线图书商。1997年，贝佐斯聘请了时任沃尔玛信息技术副总裁的里克·达尔泽尔。里克领导亚马逊研发团队长达十年。让我们和里克一起回顾他在亚马逊职业生涯中的故事：
“当我在沃尔玛时，我们有一个世界上最大的关系型数据库支撑着公司的业务。但是亚马逊团队很快就明白了，那个巨大的单体数据库根本就不适用于亚马逊。即使在那个时候，亚马逊系统在一个星期内处理的交易比沃尔玛系统在一个月内要处理的交易量还要大。如果再综合考虑不可思议的增长，那么很明显单体的系统根本就跟不上节奏。有一天，杰夫［贝佐斯］带我去吃午饭，我告诉他，我们需要把现在的单体系统拆分成服务。他说，“这很好，但是我们需要在这个业务的周围建造一条护城河，以获得1400万客户。”我解释说，如果现在还不开始这些拆分工作，那么我们有可能撑不过圣诞节。”
里克接着说，“请记住，这是20世纪90年代中后期。研发分布式事务处理系统的公司凤毛麟角。如果出现事务处理系统的交易量同比增长超过三倍，没有几个地方可以帮你提出如何解决扩展问题的方案。没有任何规则手册，也没有任何专家曾经做过或者经历过。这是一个崭新的战地前沿——一个完全荒凉的西部。但我们很清楚，要成功就必须把这些交易分散下去。与我在沃尔玛成功所做的事情相反，如果我们要保障解决方案和组织可以扩展，那么就需要把解决方案和底层数据库拆分成数个服务。”（提醒读者注意，本书的第2章专门讲解这类拆分。）
“我们开始着手将电子商务引擎和商店引擎从后端的订单处理系统中拆分出来。这是亚马逊所谓的面向服务架构旅程的真正起点。各种各样的事情都因此而发生，其中包括亚马逊的团队独立性和API合同。最终，这项工作创造了一个新的行业［基础设施即服务］，并为亚马逊网络服务带来了一个新的业务——那是另外一段故事。这项工作并不简单；之前单体数据库中的一些组成部分，诸如客户数据——我们称之为亚马逊客户数据库或ACB——花了我们几年的时间才搞清楚应该怎么拆分。我们从交易量高的服务开始，并且可以对软件和数据快速拆分，如前面描述的前端和后端系统。每做一个拆分都进一步分散系统，从而获得更大的扩展空间。最后，我们重新解决ACB这个老大难问题，终于在2004年左右完成了拆分。”
“团队聪明得令人难以相信，但是偶然我们也有些幸运。我们并不是从来都没有失败过，但是一旦犯了错，我们会迅速改正并且弄清楚该怎样解决相关的问题。幸运的是，我们发生过的事故没有像其他那些也在同一条道路上挣扎的公司损失那么严重，影响那么大。在建立这些分布式服务的过程中有一些重要经验来自于这些拆分，学习和掌握了诸如需要限制会话和状态、远离分布式的两阶段事务提交、通信尽可能保持异步等。事实上，对发布-订阅模式的消息总线异步通信我并没有强烈的偏好，没有它的支撑，我不知道是否还可以拆分和扩展。我们还学习到，如果可能尽量让事务在最终一致，除了支付以外，这具有广泛的适用性。实时一致性的成本很高，如果人们意识不到这个差别，可让事情暂时处于模糊状态，在后期同步。当然，也有一些人员或者团队方面的学习经验，例如保持团队规模足够小［3］，在团队之间发生的服务调用需要签订特别的合约等。”
里克关于如何在10年时间内领导亚马逊可扩展性研发团队的故事非常有价值。我们可以从他的见解吸取一些教训，这些教训可以避免很多面临可扩展性挑战的公司走弯路。我们将引用里克和其他几位著名的首席技术官及成功的互联网产品公司企业家的故事（这些公司既包括初创企业也包括财富500强公司），来说明本书讨论的规则对海量交易环境扩展的重要性。
快速入门指南
经验丰富的工程师、架构师和经理可以阅读所有规则的概要部分，包含规则名称、内容、场景、用法、原因和要点。你可以浏览每章各个规则的概要部分，也可以直接跳到第13章，该章汇集了所有规则的概要部分。读完这些规则的概要后，你可以选择性地阅读觉得有趣或有新鲜感的章节。
对于经验不足的读者，我们明白，掌握50条规则负担太重。我们确信最终你会熟悉所有的规则，但我们也了解你需要协调自己的时间。考虑到这一点，我们为经理选择了5章，为软件研发人员选择了5章，为技术运维人员选择了5章，我们推荐你抢先阅读本书，以免落后于其他人。
经理可以选择阅读以下几章：
第1章 大道至简
第2章 分而治之
第4章 先利其器
第7章 前车之鉴
第12章 意犹未尽
软件研发人员可以选择阅读以下几章：
第1章 大道至简
第2章 分而治之
第5章 画龙点睛
第10章 超然物外
第11章 异步通信
技术运维人员可以选择阅读以下几章：
第2章 分而治之
第3章 水平扩展
第6章 缓存为王
第8章 重中之重
第9章 有备无患
不管你是什么职位，如果有时间，建议你通读本书以掌握本书中的规则和概念。本书很短，你可以在短途的飞行中完成阅读。
读过第一遍后，本书可以作为参考书。如果你正在计划修复或重新架构现有产品，第13章提供了针对现有平台基于成本和预期收益应用规则的方法。如果你已经有了自己的优先级管理机制，我们不建议你替换，除非你更喜欢我们的方法。如果你没有现成的优先级管理机制，我们的方法应有助于你思考首先应该应用哪些规则。
如果你刚刚开始研发一个新产品，这些规则可以帮助你了解关于扩展的最佳实践。在这种情况下，最好把第13章讨论的优先级管理方法作为指南，了解在设计中最需要考虑哪些东西。你应该查看最有可能满足当下和长期扩展需要的规则，然后有计划地实施。
对于所有组织，这些规则可以帮助你建立一套架构原则来推动未来的研发。选择5、10或15个有助于产品最佳扩展的规则，并将它们用作对现有设计评审标准的补充。工程师和架构师可以提出与每个可扩展性规则相关的问题，并确保任何新的重要设计都符合可扩展性标准。虽然这些规则定义尽可能具体和固定，但是根据系统的特定情况仍有修改的余地。如果你或你的团队具有相当的可扩展性经验，可以因地制宜根据需要调整这些规则。如果你和你的团队缺乏大型系统的可扩展性经验，那就按部就班地使用这些规则，看看它对你的扩展实践有多么大的帮助。
最后，本书旨在作为参考书和手册。第13章总结了本书的50条规则，有助于读者快速参考。无论是遇到了问题，还是只希望设计一个更具可扩展性的解决方案，第13章都可以作为快速参考指南，其中的规则可以帮助你最快地走出困境或帮助你在新的征程中确定最佳路径。除了把本书作为案头参考之外，还可以考虑通过一些手段将其整合到组织中，例如，每周选取一个或两个规则在技术全员大会上讨论。
为什么会出第2版
本书的第1版是第一本以规则为脉络讲述可扩展性的书，因简洁、易用和方便深受客户的喜欢。但是不断有来自于我们公司（即AKF合作伙伴的读者和客户）要求我们讲述这些规则背后的故事。因为把客户的需要放在首位使我们感到自豪，所以我们在编辑时把隐藏在这些规则后面的故事也加了进来。
除了讲述多位首席技术官和成功企业家的故事之外，编辑本书第2版允许我们及时更新内容以确保符合行业的最佳实践。再版也给了我们让技术同行对本书内容进行另一轮评审的机会。所有这一切使第2版更容易阅读、更容易理解、更容易应用。
本书与《架构即未来》有什么不同
《架构即未来》第2版是我们第一本关于可扩展性主题的书，它专注于人、过程和技术，而本书则主要是专注于技术。不要误解，我们仍然相信人和过程是构建可扩展性解决方案最重要的组成部分。毕竟，正是公司（包括个人贡献者和管理层）在构建可扩展的解决方案的过程中有成有败。无法扩展不是技术的错误，而是人错误地构建、选择或者集成了技术。我们相信《架构即未来》已经充分论述了人和过程在可扩展性方面的问题，本书会更深入地探讨可扩展性的技术方面。
本书扩展了《架构即未来》中的第三部分（技术）。与《架构即未来》相比，本书中的内容要么是新的，要么是更偏重技术层面。正如亚马逊的一些评论者指出的那样，如果本书单独作为一本书有其独立的价值，当然它也可以作为《架构即未来》的姊妹篇。
注释
1. “Net Sales Revenue of Amazon from 2004 to 2015,”www.statista.com/statistics/
266282/annual-net-revenue-of-amazoncom/.
2. Walmart, Corporate and Financial Facts,http://corporate.walmart.com/_news_/news-
archive/investors/2015/02/19/walmart-announces-q4-underlying-eps-of-161-and-additional-strategic-investments-in-people-e-commerce-walmart-us-comp-sales-increased-15-percent.
3. 作者注：著名的亚马逊之两个披萨饼规则——团队规模不能大过两张披萨饼可以喂饱的人数。
目 录
本书赞誉
中文版序一
中文版序二
译者序
前言
致谢
作者简介
规则1——避免过度设计
规则2——方案中包括扩展
规则3——三次简化方案
规则4——减少域名解析
规则5——减少页面目标
规则6——采用同构网络
总结
注释
规则7——X轴扩展
规则8——Y轴拆分
规则9——Z轴拆分
总结
注释
规则10——向外扩展
规则11——用商品化系统（金鱼而非汗血宝马）
规则12——托管方案扩展
规则13——利用云
总结
注释
第4章 先利其器
规则14——适当使用数据库
规则15——慎重使用防火墙
规则16——积极使用日志文件
总结
注释
第5章 画龙点睛
规则17——避免画蛇添足
规则18——停止重定向
规则19——放宽时间约束
总结
注释
第6章 缓存为王
规则20——利用CDN缓存
规则21——灵活管理缓存
规则22——利用Ajax缓存
规则23——利用页面缓存
规则24——利用应用缓存
规则25——利用对象缓存
规则26——独立对象缓存
总结
注释
第7章 前车之鉴
规则27——失败乃成功之母
规则28——不靠QA发现错误
规则29——不能回滚注定失败
总结
注释
第8章 重中之重
规则30——从事务处理中清除商务智能
规则31——注意昂贵的关系
规则32——正确使用数据库锁
规则33——禁用分阶段提交
规则34——慎用Select for Update
规则35——避免选择所有列
总结
注释
第9章 有备无患
规则36——用“泳道”隔离故障
规则37——拒绝单点故障
规则38——避免系统串联
规则39——启用与禁用功能
总结
第10章 超然物外
规则40——力求无状态
规则41——在浏览器中保存会话数据
规则42——用分布式缓存处理状态
总结
注释
第11章 异步通信
规则43——尽可能异步通信
规则44——扩展消息总线
规则45——避免总线过度拥挤
总结
第12章 意犹未尽
规则46——警惕第三方方案
规则47——梯级存储策略
规则48——分类处理不同负载
规则49——完善监控
规则50——保持竞争力
总结
注释
第13章 谋定而动
用风险收益模型评估可扩展性项目和举措
50条可扩展性规则简述
可扩展性规则的利益与优先级排行榜
总结
