醉染图书架构真经9787111563884

本书赞誉
中文版序
中文版序二
译者序
前言
致谢
作者简介
章大道至简1
规则1——避免过度设计4
规则2——方案中包括扩展9
规则3——三次简化方案13
规则4——减少域名解析16
规则5——减少页面目标19
规则6——采用同构网络
总结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
规则——利用页面缓存128
规则24——利用应用缓存130
规则25——利用对象缓存134
规则26——独立对象缓存137
总结139
注释139
第7章前车之鉴141
规则27——失败乃成功之母144
规则28——不靠A发现错误151
规则29——不能回滚注定失败155
总结160
注释160
第8章重中之重162
规则30——从事务处理中清除商务智能164
规则31——注意昂贵的关系168
规则32——正确使用数据库锁172
规则33——禁用分阶段提交176
规则34——慎用Selectfor Update178
规则35——避免选择所有列181
总结183
注释184
第9章有备无患185
规则36——用“泳道”隔离故障188
规则37——拒绝单点故障194
规则38——避免系统串联198
规则39——启用与禁用功能201
总结205
0章超然物外206
规则40——力求无状态208
规则41——在浏览器中保存会话数据211
规则42——用分布式缓存处理状态213
总结216
注释217
1章异步通信218
规则43——尽可能异步通信220
规则44——扩展消息总线224
规则45——避免总线过度拥挤229
总结
2章意犹未尽4
规则46——警惕第三方方案
规则47——梯级存储策略240
规则48——分类处理不同负载246
规则49——完善监控250
规则50——保持竞争力255
总结257
注释258
3章谋定而动259
用风险收益模型评估可扩展项目和举措259
50条可扩展规则简述264
可扩展规则的利益与优先级排行榜297
总结300

马丁·阿伯特是研究增长和可扩展的咨询公司AKF的创始合伙人。马丁曾任igo的首席运营官，igo是一家从事广告业务的初创公司，后来被AOL收购。在AOL，他负责产品策略、产品管理、技术研发和客户服务。马丁曾在eBay工作了6年，先后担任不错技术副总裁、首席技术官和管员。加入eBay前，马丁在Gateway和Motorola公司担任美国靠前和靠前的工程、管理及行政职务。他还曾在几个私人和上市公司里担任董事。马丁从美国军事学院获得计算机士学，拥有罗里达大学计算机工程硕士，是哈商学院执行人员教育项目的生，同时拥有凯斯威斯顿储备大学的管理学博士。
迈克尔·费舍尔是研究增长和可扩展的咨询公司AKF的创始合伙人。在共同创建AKF公司之前，迈克尔曾任igo的首席技术官。加入igo之前，迈克尔曾在eBay的子公司PayPal担任负责工程和架构的副总裁。在加入PayPal前，迈克尔曾经在通用电气工作了7年，负责制订公司的技术发展战略，在此期间，他获得了六西格玛黑带大师的荣誉。迈克尔作为飞行员和上尉在美国陆役6年，从凯斯威斯顿储备大学管理学院获得了MBA和博士，从夏威夷太平洋大学取得信息系统硕士，从美国军事学院（西点军校）取得计算机士学。迈克尔在凯斯威斯顿储备大学管理学院的设计与创新系担任兼职教授。

前  言感谢你对本书第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强公司），来说明本书讨论的规则对海量交易环境扩展的重要。    快速入门指南经验丰富的、架构师和经理可以阅读所有规则的概要部分，包含规则名称、内容、场景、用法、原因和要点。你可以浏览每章各个规则的概要部分，也可以直接跳到3章，该章汇集了所有规则的概要部分。读完这些规则的概要后，你可以选择地阅读觉得有趣或有新鲜感的章节。    对于经验不足的读者，我们明白，掌握50条规则负担太重。我们确信你会熟悉所有的规则，但我们也了解你需要协调自己的时间。考虑到这一点，我们为经理选择了5章，为软件研发人员选择了5章，为技术运维人员选择了5章，我们你抢先阅读本书，以免落后于人。    经理可以选择阅读以下几章：    章  大道至简第2章  分而治之第4章  先利其器第7章  前车之鉴2章  意犹未尽软件研发人员可以选择阅读以下几章：    章  大道至简第2章  分而治之第5章  画龙点睛0章  超然物外1章  异步通信技术运维人员可以选择阅读以下几章：    第2章  分而治之第3章  水平扩展第6章  缓存为王第8章  重中之重第9章  有备无患不管你是什么职位，如果有时间，建议你通读本书以掌握本书中的规则和概念。本书很短，你可以在短途的飞行中完成阅读。    读过遍后，本书可以作为参考书。如果你正在计划修复或重新架构现有产品，3章提供了针对现有平台基于成本和预期收益应用规则的方法。如果你已经有了自己的优先级管理机制，我们不建议你替换，除非你更喜欢我们的方法。如果你没有现成的优先级管理机制，我们的方法应有于你思考首先应该应用哪些规则。    如果你刚刚开始研发一个新产品，这些规则可以帮你了解关于扩展的实践。在这种情况下，把3章讨论的优先级管理方法作为指南，了解在设计中需要考虑哪些东西。你应该查看可能满足当下和长期扩展需要的规则，然后有计划地实施。    对于所有组织，这些规则可以帮你建立一套架构原则来推动未来的研发。选择5、10或15个有于产品扩展的规则，并将它们用作对现有设计评审标准的补充。和架构师可以提出与每个可扩展规则关的问题，并确保任何新的重要设计都符合可扩展标准。虽然这些规则定义尽可能具体和固定，但是根据系统的特定情况仍有修改的余地。如果你或你的团队具有相当的可扩展经验，可以因地制宜根据需要调整这些规则。如果你和你的团队缺乏大型系统的可扩展经验，那就按部就班地使用这些规则，看看它对你的扩展实践有多么大的帮。    ，本书旨在作为参考书和手册。3章总结了本书的50条规则，有于读者快速参考。无论是遇到了问题，还是只希望设计一个更具可扩展的解决方案，3章都可以作为快速参考指南，其中的规则可以帮你快地走出困境或帮你在新的征程中确定路径。除了把本书作为案头参考之外，还可以虑通一些手段将其整合到组织中，例如，每周选取一个或两个规则在技术全员大会上讨论。    为什么会出第2版本书的版是本以规则为脉络讲述可扩展的书，因简洁、易用和方便深受客户的喜欢。但是不断有来自于我们公司（即AKF合作伙伴的读者和客户）要求我们讲述这些规则背后的故事。因为把客户的需要放在首位使我们感到自豪，所以我们在编辑时把隐藏在这些规则后面的故事也加了进来。    除了讲述多位首席技术官和成功企业家的故事之外，编辑本书第2版允许我们及时更新内容以确保符合行业的实践。再版也给了我们让技术同行对本书内容进行另一轮评审的机会。所有这一切使第2版更容易阅读、更容易理解、更容易应用。    本书与《架构即未来》有什么不同《架构即未来》第2版是我们本关于可扩展主题的书，它专注于人、过程和技术，而本书则主要是专注于技术。不要误解，我们仍然相信人和过程是构建可扩展解决方案重要的组成部分。竟，正是公司（包括个人贡献者和管理层）在构建可扩展的解决方案的过程中有成有败。无法扩展不是技术的错误，而是人错误地构建、选择或者集成了技术。我们相信《架构即未来》已经充分论述了人和过程在可扩展方面的问题，本书会更深入地探讨可扩展的技术方面。    本书扩展了《架构即未来》中的第三部分（技术）。与《架构即未来》相比，本书中的内容要么是新的，要么是更偏重技术层面。正如的一些评论者指出的那样，如果本书单独作为一本书有其独立的价值，当然它也可以作为《架构即未来》的姊妹篇。    注释1.“Net Sales Revenue of Amazon from 2004 to 2015,”www

《架构真经:互联网技术架构的设计原则(原书第2版)》是经典著作《架构即未来》的姊妹篇，聚焦于技术架构本身，提供50条久经考验的互联网技术架构原则，几乎可以支持任何高速增长公司的扩展。硅谷有名互联网企业首席技术官和技术主管现身说法，生动形象地呈现“规则背后的故事”，便于读者理解并运用这些规则解决实际工作中所面临的挑战。