这是一本有关设计和构建可扩展性系统的深入而且实用的指南，是产品构建团队和运营团队的必读书籍，作者从AKF的多年实践经验中提炼出了简明扼要的规则。由于现代系统的复杂性，可扩展性应该是架构及其实施过程中不可缺少的一个组成部分。扩展系统以满足高速增长，这需要与产品特征紧密相关的敏捷和迭代方法，本书将告诉你怎么做。

感谢你对本书第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. 作者注：著名的亚马逊之两个披萨饼规则——团队规模不能大过两张披萨饼可以喂饱的人数。

计算机\Web设计

这本书提纲挈领，提出了50个保证可扩展性的规则，让技术干将们获得全面的战术训练。
——唐彬，易宝支付CEO及共同创始人， 互联网金融千人会轮值主席
就像商业的真谛和本质不会因为新商业模式的不断涌现而改变，架构设计的基本原理也不会因为新技术的层出不穷而过时，愿这本《架构真经》成为应对技术和商业变迁的有效工具。
——向江旭，苏宁云商IT总部执行副总裁， 苏宁技术研究院院长
本书将帮助读者学习可扩展性的技能，避免常见的架构陷阱。更重要的是，本书将把架构师和工程师带到更高水平，使他们有能力处理未来的问题。 快乐阅读！
——叶亚明，携程旅行网首席技术官
如果说《架构即未来》阐述的是互联网架构之道，这本书则是互联网架构的“术”。本书提供了50个凝聚作者丰富经验的招式，可以帮助互联网企业的工程师们快速找到解决问题的方向。
——段念，花虾金融CEO
本书是对《架构即未来》一书的全面升级和扩展，凝结了作者和众多行业专家多年的实践积累和思想升华，同时结合最新的业界案例让读者能够迅速理解，并使用规则构建面向未来产品的可扩展解决方案。
——吴华鹏，iTech Club理事长、1024学院创始人
本书作者用最为简单的自然之道诠释了最为复杂的各种计算机互联网运用。当今，互联网+各行业正处于快速发展的关键阶段，这是一本非常值得包括传统行业在内的各行从业人员认真阅读，内涵深厚的技术架构图书。
——张瑞海，百悟科技董事长
这是一本非常好的书，将技术架构和商业实践完美地结合在一起。书里提供的概念可以供任何人使用，它不仅是技术人的一本真经，更是公司管理层乃至CEO都适用的一本好读物。
——韩军，原1号店CTO
这本书从很大程度上解决了初任架构师的困惑，让他们在实际工作中能够全面完整地去分析和设计系统架构，不再是在茫茫的黑夜中摸索前行。对于资深架构师而言，这本书同样提供了很好的参考。
——程炳皓，前开心网创始人兼首席执行官
本书用一个个久经考验的规则告诉你，如何一步步构建一个可扩展的系统，可以说是一本互联网系统的可扩展红包书。
——张云泉，中科院计算所研究员，博导，国家超算济南中心主任
本书提炼了架构思维的50条黄金规则，非常值得一读。
——李大学，磁云科技CEO，中国互联网＋实战团发起人，京东终身荣誉技术顾问
我相信这两本书虚实结合，一定能够帮助有志于在架构设计领域精进的各位同学。
——霍泰稳，极客邦科技创始人兼CEO

(美)马丁 L. 阿伯特(Martin L. Abbott)　 迈克尔 T. 费舍尔(Michael T. Fisher) 著：暂无简介

2016年，由我翻译、机械工业出版社华章分社出版的《架构即未来》一书在互联网技术行业广受欢迎。2016年年底，机械工业出版社华章分社的编辑又联系我，希望我能把《架构即未来》的姊妹篇《架构真经》也翻译出来，由他们出版并奉献给国内的读者。在得到该书的英文版后，我如饥似渴地读了起来，仅用一个通宵就把50个架构原则通读了一遍。这本书使我个人受益匪浅，同时我也看到了它对我国互联网技术人员的潜在价值，深深感觉到自己有责任尽快地把它翻译成中文，把好的经验分享给大家。
我于2008年加入eBay公司，2014年离开。在eBay的6年时间里，我深刻地体会到硅谷公司对互联网技术架构的重视，公司里有应用架构师、信息安全架构师、网络架构师、数据库架构师和运维架构师等负责技术架构的专业人员，每个重要项目及系统的变更都需要经过架构师的层层严格审查。原著作者阿伯特和费舍尔两位也曾在eBay和PayPal主持过技术工作，他们在本书中所叙述的人物、事件、架构等也是我非常熟悉甚至亲身经历过的，所以翻译起来得心应手，倍感亲切。仿佛自己又回到了在eBay和PayPal的年代，好像是在写自己的回忆录。所以整个翻译过程如行云流水般顺利，只用两个月时间就完成了本书全部的翻译工作。
2014年回到易宝后，我发现公司里没有架构师，也缺乏架构师的培养和晋升体系。面对培养架构师和建立技术体系的挑战，我曾经萌发过自己编写一本培训教材的念头，专门总结和介绍硅谷的互联网技术架构经验。2016年我翻译的《架构即未来》一书，从人员、管理、过程和架构几个方面对硅谷互联网技术架构的最佳实践做了全面介绍。而本书则聚焦在技术架构本身，把两位作者多年积累的互联网技术架构实战经验提炼出来。通过硅谷著名互联网企业首席技术官所讲述的真实故事，以易于理解的方式，生动且形象地把枯燥难懂的50个架构原则讲解清楚，读了之后使人有醍醐灌顶、豁然开朗的感觉。我利用本书的第一部分作为基本教材在易宝做了一次尝试性的分享，技术人员的反响不错，大家都很期待后续章节的分享。2017年2月，我在CTO学院收了十几个徒弟，他们都是各互联网公司的技术精英和未来的CTO，当他们问我如何学习和掌握互联网架构技术时，我告诉他们最近会出版一本可以教导准CTO的秘籍，好像《射雕英雄传》里的《九阴真经》和《九阳真经》那样，能使他们的技术架构能力大增，也正是因为此，本书的中文名称被定为《架构真经》。非常期待这本书的出版能为互联网技术江湖培养出一大批技术英雄。
从互联网技术架构的理念、设计、实施和监控方面，本书全面概括了相关场景、条件和方法。作为互联网扩展技术的高级专家，本书作者通过AKF合伙公司为数以百计的互联网企业提供了技术咨询服务，也因此积累了丰富的实战经验。最近AKF合伙公司也把目光转向了中国，在本书中文版出版前夕，当我邀请费舍尔为中文版写寄语时，他表达出了要和中国的互联网企业加强合作的强烈期待。中国的互联网技术发展日新月异，一日千里，甚至在应用方面已经超过世界发达国家，开始引领世界互联网技术的发展潮流。希望本书中文版的出版能为中国的互联网技术发展助一臂之力。

本书赞誉
中文版序一
中文版序二
译者序
前言
致谢
作者简介
第1章　大道至简 …… 1
规则1——避免过度设计 …… 4
规则2——方案中包括扩展 …… 9
规则3——三次简化方案 …… 13
规则4——减少域名解析 …… 16
规则5——减少页面目标 …… 19
规则6——采用同构网络 …… 23
总结 …… 24
注释 …… 25
第2章　分而治之 …… 27
规则7——X轴扩展 …… 31
规则8——Y轴拆分 …… 35
规则9——Z轴拆分 …… 39
总结 …… 41
注释 …… 42
第3章　水平扩展 …… 43
规则10——向外扩展 …… 46
规则11——用商品化系统（金鱼而非汗血宝马） …… 50
规则12——托管方案扩展 …… 53
规则13——利用云 …… 61
总结 …… 64
注释 …… 64
第4章　先利其器 …… 65
规则14——适当使用数据库 …… 71
规则15——慎重使用防火墙 …… 80
规则16——积极使用日志文件 …… 85
总结 …… 88
注释 …… 89
第5章　画龙点睛 …… 90
规则17——避免画蛇添足 …… 93
规则18——停止重定向 …… 98
规则19——放宽时间约束 …… 104
总结 …… 107
注释 …… 107
第6章　缓存为王 …… 109
规则20——利用CDN缓存 …… 113
规则21——灵活管理缓存 …… 117
规则22——利用Ajax缓存 …… 120
规则23——利用页面缓存 …… 128
规则24——利用应用缓存 …… 130
规则25——利用对象缓存 …… 134
规则26——独立对象缓存 …… 137
总结 …… 139
注释 …… 139
第7章　前车之鉴 …… 141
规则27——失败乃成功之母 …… 144
规则28——不靠QA发现错误 …… 151
规则29——不能回滚注定失败 …… 155
总结 …… 160
注释 …… 160
第8章　重中之重 …… 162
规则30——从事务处理中清除商务智能 …… 164
规则31——注意昂贵的关系 …… 168
规则32——正确使用数据库锁 …… 172
规则33——禁用分阶段提交 …… 176
规则34——慎用Select for Update …… 178
规则35——避免选择所有列 …… 181
总结 …… 183
注释 …… 184
第9章　有备无患 …… 185
规则36——用“泳道”隔离故障 …… 188
规则37——拒绝单点故障 …… 194
规则38——避免系统串联 …… 198
规则39——启用与禁用功能 …… 201
总结 …… 205
第10章　超然物外 …… 206
规则40——力求无状态 …… 208
规则41——在浏览器中保存会话数据 …… 211
规则42——用分布式缓存处理状态 …… 213
总结 …… 216
注释 …… 217
第11章　异步通信 …… 218
规则43——尽可能异步通信 …… 220
规则44——扩展消息总线 …… 224
规则45——避免总线过度拥挤 …… 229
总结 …… 233
第12章　意犹未尽 …… 234
规则46——警惕第三方方案 …… 237
规则47——梯级存储策略 …… 240
规则48——分类处理不同负载 …… 246
规则49——完善监控 …… 250
规则50——保持竞争力 …… 255
总结 …… 257
注释 …… 258
第13章　谋定而动 …… 259
用风险收益模型评估可扩展性项目和举措 …… 259
50条可扩展性规则简述 …… 264
可扩展性规则的利益与优先级排行榜 …… 297
总结 …… 300