具体描述
●中文版序
●中文版序二
●译者序
●前言
●致谢
●作者简介
●第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
●部分目录
内容简介
本书是《架构即未来》的姊妹篇。全书共分13章，用成功互联网产品公司首席技术官和企业家的故事，引出了对构建可扩展的产品至关重要的50条规则，可帮助软件研发人员、技术运维人员和管理者修复或重新架构现有产品，了解关于扩展的佳实践并有计划地实施，还可以帮助建立一套架构原则以推动未来的研发。 (美)马丁 L.阿伯特(Martin L.Abbott),(美)迈克尔 T.费舍尔(Michael T.Fisher) 著；陈斌 译 马丁·阿伯特是研究增长和可扩展的咨询公司AKF的创始合伙人。马丁曾任Quigo的首席运营官，Quigo是一家从事广告业务的初创公司，后来被AOL收购。在AOL，他负责产品策略、产品管理、技术研发和客户服务。马丁曾在eBay工作了6年，先后担任不错技术副总裁、首席技术官和高管人员。加入eBay前，马丁在Gateway和Motorola公司担任美国靠前和靠前的工程、管理及行政职务。他还曾在几个私人和上市公司里担任董事。马丁从美国军事学院获得计算机学士学位，拥有佛罗里达大学计算机工程硕士学位，是哈佛商学院执行人员教育项目的毕业生，同时拥有凯斯威斯顿储备大学的管理学博士学位。迈克尔·费舍尔是等 如今，这些担忧远不如从21世纪70年代末到80年代末这段时间。事实上，当我们询问客户关于立即读取刚写入数据的失败率
时，答案相当一致：“从来没有。”除非他们不妥当地处理写操作
返回的错误码，否则永远都不会出现失败。当然，时不时会发生数据损坏，但在大多敉怡况下，数据损坏是在实际写入时发现的。读取刚写入的数据使系统事倍功半。反过来也会降低利润率和盈利能例。较好的方案是直接读取正在执行的操作返回数据，并相信它的正确性，从而捉高有价值的事务处理量。在这里做个侧面说明，对数据损坏很稳妥的保护措施是合理地实现系统的高可用性，并有多个数据副本，如备用数据库或存储复制（参见第9章）。理想情况下很终实现多活。 前 言感谢你对本书第2版感兴趣！作为一本入门、进修和轻量级的参考手册，本书旨在帮助工程师、架构师和管理者研发及维护可扩展的互联网产品。本书给出了一系列规则，每个规则围绕着不同的主题展开讨论。大部分的规则聚焦在技术上，少数规则涉及一些关键的思维或流程问题，每个规则对构建可扩展的产品都是至关重要的。这些规则在深度和焦点上都有所不同。有些规则是高级的，例如定义一个可以应用于几乎任何可扩展性问题的模型；其他的则比较具体，可能用来解释一种技术，例如怎么修改HTTP头来大化内容缓存。在本版中，我们增加了成功的互联网产品公司中首席技术官和企业家的故事，这里涉及的公司既包括初创企业也有财富500强公司。这些故事有助于说明规则是如何形成的，以及它们为什么在海量事务处理环境中显得如此重要。没有什么其他故事可以比YA马逊更能说明在互联网上急速扩展所遇到的需求和挑战。里克·达尔泽尔是YA马逊等
用户评价
阅读《架构真经(原书第2版)》的过程，更像是在经历一场“思维重塑”。这本书并没有直接给我很多“拿来就用”的解决方案，而是通过一些更根本性的原则和思考方式，来引导读者重新审视架构设计的本质。我发现书中反复强调“一致性”和“沟通”，这两点在我平时的开发中，虽然知道重要，但从未像现在这样被拔高到架构设计的基础层面。它让我意识到，很多架构问题，追根溯源，往往是由于缺乏清晰的沟通和统一的理解导致的。 我原本期待能从中找到关于“如何处理高并发”、“如何构建高可用系统”之类的具体技术点，甚至是一些精妙的代码模式。但这本书更侧重于“为何要这样做”，而不是“如何实现”。比如，当谈到“分层架构”时，它更多的是讲解分层带来的职责分离、解耦的好处，以及如何合理划分层级，而不是直接给出如何设计API网关、如何实现服务注册与发现的具体技术方案。这让我感觉，它更适合作为一本“架构哲学”来研读，而不是一本“架构实践手册”。对于我而言，这种略显抽象的讲解，需要花费更多的时间去消化和理解其背后的含义。
拿起《架构真经(原书第2版)》，我的主要目的是想了解如何才能构建出“健壮”且“可扩展”的系统。我以为书中会充斥着各种设计模式、设计原则的详细解析，以及如何将它们应用于实际项目中的指导。然而，读下来之后，我发现这本书的重心似乎更在于“为什么”要做架构设计，以及“为什么”要遵循某些原则。它并没有直接给出“如何选择合适的数据库”、“如何设计高效的缓存策略”之类的具体技术建议。 书里关于“模块化”的讨论，让我印象深刻，但它更多的是从“如何让系统更容易理解和维护”的角度来展开，而不是直接给出“如何进行服务拆分”或者“如何设计服务间通信机制”的具体方法。这让我觉得，这本书更像是在搭建一个“思想框架”，而不是提供一个“工具箱”。我更倾向于那种能够提供具体解决方案，告诉我“这样做”或者“那样做”的书籍。这种偏向理论和概念的讲解，虽然有其价值，但对于我这种更注重实践的开发者来说，需要花费更多的时间去思考如何将其转化为实际的行动。
《架构真经(原书第2版)》给我带来的感觉，更像是在进行一次“概念梳理”。书中的很多概念，比如“康威定律”、“高内聚低耦合”等等，虽然我平时工作中接触过，但这本书将它们系统地串联起来，并从更宏观的视角进行了阐释。它没有直接给出“如何写出优雅的代码”或者“如何设计高性能的数据库”，而是探讨了在更广阔的范围内，如何通过合理的架构设计来提升整个系统的生命力。 我期望这本书能给我一些具体的、可操作的“工具箱”或者“秘籍”，可以直接应用到我的项目中。比如，在面临服务拆分时，我希望它能提供一些明确的拆分原则和参考模型；在遇到性能瓶颈时，我希望它能给出一些实用的性能优化策略。但这本书的讲解方式，更多的是在“为什么”和“是什么”层面进行深入探讨，比如为何要解耦，解耦的意义何在，而不是直接告诉你“如何实现解耦”的具体技术步骤。这让我感觉，它更像是在引导你建立一套“价值观”，而不是提供一套“方法论”。
《架构真经(原书第2版)》给我的第一印象是，它在构建一个“为什么”的理论框架。读这本书，感觉像是被带到了一个高处，俯瞰整个软件开发的全貌，而不是埋头于某个具体的技术细节。它强调的不是“如何做”，而是“为何要这样”。举个例子，在讨论到“模块化”时，它并没有直接给出如何将一个大系统拆分成多少个服务，或者每个服务应该遵循什么样的接口规范，而是深入剖析了模块化能够带来的好处，比如可维护性、可测试性、团队协作的效率等等。这种从根源上理解问题的方式，虽然需要投入更多的时间和精力去消化，但长远来看，对于建立扎实的架构设计思维是有益的。 不过，对于实际动手操作的需求，这本书的直接指导性并不强。我期待这本书能够提供更多关于“如何选择技术栈”、“如何进行技术选型”、“如何评估不同架构方案的优缺点”等方面的具体建议，或者给出一些实际的案例研究，展示如何在真实世界中应用这些架构原则。虽然理论很重要，但对于我们一线开发人员来说，如何将理论转化为可执行的方案，如何解决实际工程中的痛点，才是我们最关心的。这本书更多的是提供了一个思考的“方向盘”，而不是一个具体的“导航地图”。
拿到《架构真经(原书第2版)》这本书，我原本是抱着一种“求知若渴”的态度，期待能从中提炼出一些能让我的项目经验更上一层楼的“内功心法”。然而，翻阅了前面一些章节后，我发现这本书的切入点比我想象的要更加宏观和基础。它并没有直接深入到某个特定技术栈的框架设计或者性能调优的细节，而是更多地从“为什么”和“是什么”的角度出发，探讨了架构设计的底层逻辑和指导原则。 书中花了相当大的篇幅来阐述“领域驱动设计”的理念，这让我有些意外。我原本以为“真经”会聚焦于更为通用的设计模式，比如如何组织微服务、如何处理分布式事务等等。但《架构真经》却花了大量笔墨去讲解如何理解业务的本质，如何通过识别领域和子领域来划分系统的边界，以及如何用通用的语言来描述这些概念。这部分内容虽然重要，但对于我这种急于解决实际问题的开发者来说，前期可能显得有些“纸上谈兵”。我更希望看到的是如何将这些抽象概念落地到具体的代码实现中，或者提供一些可供参考的架构图和案例分析。当然，也可能是我的期望值过高，希望它能成为一本“万能手册”。