【中文版序一】
Thanks for your interest in the second edition of Scalability Rules!
We are very excited that this version is being translated for our Chinese readers. Our consulting practice, AKF Partners, has worked with several Chinese ecommerce and internet related businesses such as Dianping and others. Scalability Rules was the f?irst book to address the topic of scalability in a rules-oriented fashion and was well received by technologist around the world. We have found through our consulting practice that people learn best from stories; therefore, for this edition we have updated the rules and included stories from CTOs and entrepreneurs of successful Internet product companies. We are very happy about this translation and we hope you enjoy this version of Scalability Rules.
（感谢您对本书第2版的关注！对本书第2版能在中国翻译出版，我们感到非常兴奋！AKF合作伙伴已经与中国的几家电子商务和互联网公司（如大众点评网）等开展了咨询合作。这是第一本以规则为脉络讲述可扩展性的著作，广为世界各地技术人员所喜爱。通过咨询实践，我们发现从故事中学习是一种最好的方式。因此，本版不仅更新了规则，还包括了成功互联网公司首席技术官和企业家的故事。我们对本书能翻译成中文出版感到很高兴，希望你也能喜欢。）
——马丁L.阿伯特，AKF公司初始合伙人，eBay前CTO
【中文版序二】
马尔科姆·格拉德威尔在《异类》一书中提出了著名的“一万小时定律”，也就是说，任何凡人要成为某个领域的顶尖专家，都至少需要一万个小时的练习。其实中国古训也有“天道酬勤”的说法。但是勤奋是不是等于精进呢？显然，历史和现实的案例告诉我们，勤奋是优秀的必要条件，但不是充分条件。这就是为什么“刻意练习”（deliberate practice）这个概念现在变得如此之火。因为在一万个小时的背后，真正起作用的是有针对性的刻意练习。
刻意练习是指在介于“舒适区”和“恐慌区”之间的“学习区”进行大量组块化的、专注的、有反馈的练习。真正的学习不是闲庭信步，不是读几个公众号或者翻几本书就足够的。刻意练习是非常枯燥的，它令人很不舒服，并且消磨人的耐心。真正从菜鸟到高手的道路，都是通过刻意练习的汗水铺就的。
莫扎特是公认的音乐神童，但他纠正说，没有人比他对大师的作品研究得更加刻苦。高尔夫球星泰格·伍兹，通过从小刻苦的专业训练，实现了惊人的竞技成就。歌唱家、网球手、数学家、银行家，甚至政治家，都需要通过在自己的领域中刻意练习才能出类拔萃。“三百六十行，行行出状元”，这一个个状元，都是通过刻意练习达成的。
优秀程序员的诞生也是一样。
编程是一项基本功，也是程序员每日工作的基本内容。码农很多，但是真正跳出来思考代码之上的架构法则的则不多。这种思维方式不是写百万行代码就能够培养出来的。在程序员的竞技场上脱颖而出，同样需要刻意练习。首先要跳出舒适区，去思考代码为什么这么写，结构为什么这么设计。其次，要有师父带领，高手指导，才能把前人珍贵的经验法则传授给你。再次，要反复练习，在实践中不断训练前述经验法则，将它们内化为下意识的思维模式。最后，还要通过实效的反馈，不断修正自己的技术习惯，发现自己的技术盲点，提高自己的技术思维。通过这样有意识的训练，才有可能从程序员走向架构师，甚至CTO。
武林中人人追求的《九阳真经》，就是这种刻意练习的指导材料。那么，在程序员的世界，也有这种可资修炼的武林宝典吗？
有的，摆在你面前的这本《架构真经》就是。
作为《架构即未来》的姊妹篇，阿伯特和费舍尔给出了50个组块化的架构法则，可让程序员获得一整套在实战中刻意练习的材料。如果你从《架构即未来》中获得了人员、过程和技术方面的整体框架，那么这本书就能让你在技术方面进行有针对性的训练。
作为前eBay资深架构师和现任易宝CTO，译者陈斌本人就是译本质量的保证。他对技术工具如数家珍，在技术实战中运筹帷幄，在技术思维上融会贯通，既有硅谷名企的扎实训练和先进理念，也了解国内企业的技术现状和实际需求。他不但热衷于钻研专业知识，而且热爱阅读写作，译笔可谓信达雅兼具，从目录中的成语章名即可见一斑。
希望每个有志于走向卓越的程序员，都通过《架构真经》提供的法则进行刻意练习，把科学的架构思维变成一种本能反应。我相信，长此以往，大多数互联网公司的可扩展性问题都会获得极大的改善。本书与《架构即未来》一样，应该成为程序员们的案头必备。
——余晨，易宝支付高级副总裁及联合创始人
【译者序】
2016年，由我翻译、机械工业出版社华章公司出版的《架构即未来》一书在互联网技术行业广受欢迎。2016年年底，华章公司的编辑又联系我，希望我能把《架构即未来》的姊妹篇《架构真经》也翻译出来，由他们出版并奉献给国内的读者。在得到该书的英文版后，我如饥似渴地读了起来，仅用一个通宵就把50个架构原则通读了一遍。这本书使我个人受益匪浅，同时我也看到了它对我国互联网技术人员的潜在价值，深深感觉到自己有责任尽快地把它翻译成中文，把好的经验分享给大家。
我于2008年加入eBay公司，2014年离开。在eBay的6年时间里，我深刻地体会到硅谷公司对互联网技术架构的重视，公司里有应用架构师、信息安全架构师、网络架构师、数据库架构师和运维架构师等负责技术架构的专业人员，每个重要项目及系统的变更都需要经过架构师的层层严格审查。原著作者阿伯特和费舍尔两位也曾在eBay和PayPal主持过技术工作，他们在本书中所叙述的人物、事件、架构等也是我非常熟悉甚至亲身经历过的，所以翻译起来得心应手，倍感亲切。仿佛自己又回到了在eBay和PayPal的年代，好像是在写自己的回忆录。所以整个翻译过程如行云流水般顺利，只用两个月时间就完成了本书全部的翻译工作。
2014年回到易宝后，我发现公司里没有架构师，也缺乏架构师的培养和晋升体系。面对培养架构师和建立技术体系的挑战，我曾经萌发过自己编写一本培训教材的念头，专门总结和介绍硅谷的互联网技术架构经验。2016年我翻译的《架构即未来》一书，从人员、管理、过程和架构几个方面对硅谷互联网技术架构的最佳实践做了全面介绍。而本书则聚焦在技术架构本身，把两位作者多年积累的互联网技术架构实战经验提炼出来。通过硅谷著名互联网企业首席技术官所讲述的真实故事，以易于理解的方式，生动且形象地把枯燥难懂的50个架构原则讲解清楚，读了之后使人有醍醐灌顶、豁然开朗的感觉。我利用本书的第一部分作为基本教材在易宝做了一次尝试性的分享，技术人员的反响不错，大家都很期待后续章节的分享。2017年2月，我在CTO学院收了十几个徒弟，他们都是各互联网公司的技术精英和未来的CTO，当他们问我如何学习和掌握互联网架构技术时，我告诉他们最近会出版一本可以教导准CTO的秘籍，好像《射雕英雄传》里的《九阴真经》和《九阳真经》那样，能使他们的技术架构能力大增，也正是因为此，本书的中文名称被定为《架构真经》。非常期待这本书的出版能为互联网技术江湖培养出一大批技术英雄。
从互联网技术架构的理念、设计、实施和监控方面，本书全面概括了相关场景、条件和方法。作为互联网扩展技术的高级专家，本书作者通过AKF合伙公司为数以百计的互联网企业提供了技术咨询服务，也因此积累了丰富的实战经验。最近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版是我们第一本关于可扩展性主题的书，它专注于人、过程和技术，而本书则主要是专注于技术。不要误解，我们仍然相信人和过程是构建可扩展性解决方案最重要的组成部分。毕竟，正是公司（包括个人贡献者和管理层）在构建可扩展的解决方案的过程中有成有败。无法扩展不是技术的错误，而是人错误地构建、选择或者集成了技术。我们相信《架构即未来》已经充分论述了人和过程在可扩展性方面的问题，本书会更深入地探讨可扩展性的技术方面。
本书扩展了《架构即未来》中的第三部分（技术）。与《架构即未来》相比，本书中的内容要么是新的，要么是更偏重技术层面。正如亚马逊的一些评论者指出的那样，如果本书单独作为一本书有其独立的价值，当然它也可以作为《架构即未来》的姊妹篇。
![《架构真经：互联网技术架构的设计原则（原书第2版）》[67M]百度网盘|亲测有效|pdf下载](/upload/2024-12-29/58d4dadcN9ea3f3b2.jpg.avif)
