描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787111757467
序1
前言3
第0章 导论11
0.1 架构之旅11
0.2 API简介12
0.3 真实示例：会议系统案例研究13
0.3.1 会议案例研究中的 API 类型14
0.3.2 改进会议系统的原因15
0.3.3 从分层架构到API建模15
0.3.4 案例研究：演进步骤15
0.3.5 API 基础设施和流量模式17
0.3.6 会议系统案例研究的路线图17
0.4 使用C4图表18
0.4.1 C4上下文关系图18
0.4.2 C4容器图18
0.4.3 C4 组件图18
0.5 使用架构决策记录19
0.5.1 参会者演进ADR20
0.5.2 精通API：ADR指南20
0.6 小结21
第一部分 设计、构建和测试API
第1章 设计、构建和规范API25
1.1 案例研究：设计参会者API25
1.2 REST介绍26
1.2.1 通过示例介绍REST和HTTP26
1.2.2 Richardson成熟度模型27
1.3 RPC API介绍28
1.4 GraphQL简要介绍29
1.5 REST API标准和结构29
1.5.1 集合和分页31
1.5.2 过滤集合32
1.5.3 错误处理32
1.5.4 ADR指南：选择API标准33
1.6 使用OpenAPI规范定义REST API33
1.7 OpenAPI规范的实际应用34
1.7.1 代码生成34
1.7.2 OpenAPI验证34
1.7.3 示例和模拟35
1.7.4 检测变更35
1.8 API版本控制35
1.8.1 语义化版本控制36
1.8.2 OpenAPI规范和版本控制37
1.9 用gRPC实现RPC38
1.10 交互建模和API格式选择40
1.10.1 高流量服务40
1.10.2 大尺寸交互负载40
1.10.3 HTTP/2的性能优势41
1.10.4 旧格式处理41
1.11 指南：交互建模41
1.12 同时使用多个规范42
1.12.1 是否存在黄金规范42
1.12.2 合并规范的挑战43
1.13 小结43
第2章 API接口测试45
2.1 本章的会议系统场景46
2.2 测试策略46
2.2.1 测试四象限47
2.2.2 测试金字塔48
2.2.3 用于测试策略的ADR指南50
2.3 契约测试50
2.3.1 契约测试的益处51
2.3.2 契约的实现方式51
2.3.3 ADR指南：契约测试55
2.4 API组件测试56
2.4.1 契约测试和组件测试的比较57
2.4.2 案例研究：用组件测试进行验证57
2.5 API集成测试58
2.5.1 使用存根服务器的好处和方法59
2.5.2 ADR指南：集成测试60
2.5.3 容器化测试组件：Testcontainers61
2.5.4 案例研究：使用Testcontainers验证集成61
2.6 端到端测试62
2.6.1 自动化端到端验证63
2.6.2 端到端测试的类型64
2.6.3 ADR指南：端到端测试64
2.7 小结65
第二部分 API流量管理
第3章 API网关：入口流量管理69
3.1 API网关是唯一解决方案吗69
3.2 指南：代理、负载均衡器或API网关70
3.3 案例研究：向消费者提供参会者服务71
3.4 什么是API网关71
3.5 API网关能提供哪些功能72
3.6 在哪里部署API网关72
3.7 API网关如何在网络边缘与其他技术集成73
3.8 为何使用API网关74
3.8.1 减少耦合：前端和后端之间的适配器/外观75
3.8.2 简化调用方式：聚合/转换后端服务75
3.8.3 保护API免受过度使用和滥用：威胁检测和防范76
3.8.4 了解API是如何被使用的：可观测性77
3.8.5 将API作为产品进行管理：API生命周期管理78
3.8.6 商业化API：账户管理、计费和支付79
3.9 API网关的现代史80
3.9.1 20世纪90年代以后：硬件负载均衡器80
3.9.2 21世纪00年代以后：软件负载均衡器80
3.9.3 21世纪00年代中期：应用程序交付控制器81
3.9.4 21世纪10年代初：第一代API网关82
3.9.5 2015年以后：第二代API网关82
3.10 当前API网关分类83
3.10.1 传统企业网关84
3.10.2 微服务/微网关84
3.10.3 服务网格网关84
3.10.4 不同类型API网关比较84
3.11 案例研究：使用API网关改进会议系统85
3.11.1 在Kubernetes中安装Ambassador Edge Stack87
3.11.2 配置URL路径到后端服务的映射87
3.11.3 使用基于主机的路由配置映射88
3.12 部署API网关：了解和管理故障88
3.12.1 API网关成为单点故障89
3.12.2 检测问题并接管89
3.12.3 解决事故和故障89
3.12.4 防范风险90
3.13 常见的API网关实现陷阱90
3.13.1 API网关回路91
3.13.2 API网关作为ESB91
3.13.3 从上到下都是“乌龟”（API网关）91
3.14 选择API网关92
3.14.1 明确需求92
3.14.2 自建还是购买92
3.14.3 ADR指南：选择API网关92
3.15 小结93
第4章 服务网格：服务间流量管理95
4.1 服务网格是唯一解决方案吗95
4.2 指南：你应该采用服务网格吗96
4.3 案例研究：把议程功能提取成服务96
4.4 什么是服务网格98
4.5 服务网格能提供什么功能99
4.6 服务网格部署在何处100
4.7 服务网格如何与其他网络技术集成100
4.8 为何使用服务网格102
4.
世界是普遍联系和永恒发展的。
自IT行业诞生以来，世界始终处于快速的变革与演进之中。无论是基础设施、编程语言，还是设计思想和架构模式，都在持续迭代和完善。即使是那些使用尖端技术构建的软件系统，也可能在短时间内显得不够先进。这样的高速变化，虽然有时会让人觉得有些力不从心，但正是这种持续的进步和创新，构成了此行业的独特魅力。它意味着新机会的不断涌现、软件生态的持续改进，以及技术门槛的不断降低，为互联网时代和AI时代创造了无数可能性。
API是Application Programming Interface（应用程序编程接口）的缩写，是应用程序世界相互连接的桥梁。AWS将API定义为“两个软件组件使用一组定义和协议相互通信的机制”，IBM则将API定义为“一组定义的规则，使不同的应用程序能够相互通信”。我国金融标准化技术委员会发布的《商业银行应用程序接口安全管理规范》（JR/T 0185—2020）中则将API定义为“一组预先定义好的功能，开发者可通过该功能（或功能的组合）便捷地访问相关服务，而无须关注服务的设计与实现”。
我们综合这几个定义可以看到这个应用程序世界桥梁的真正目的和定义：
目的：用来为开发者在无须关注服务的设计与实现的情况下便捷地访问相关服务。
定义：不同的应用程序使用一组定义规则和协议相互通信的机制。
2023年初在机械工业出版社华章分社有关老师的推荐下，我们很幸运地接触到了这本书，书中用前瞻性的思维和全局视角详细阐释了当前最先进的基于API的架构设计方法和技术。其独到之处不仅在于对现有最主流技术的介绍，更在于其所采用的方法论既可以帮助读者升级和完善现有系统，也为读者应对未来变革提供了指南。其中的C4架构图、ADR和DFD等都是在大型企业架构设计中得到广泛应用的简明却功能强大的实用工具。不同于其他仅停留在理论层面的书籍，本书以一个虚拟的案例贯穿始终，即如何通过小步快跑的策略将一个用三层架构方式设计的传统应用系统迭代为一个基于API的现代架构。本书分为四部分，共10章，囊括了设计、测试、运维、安全、部署和发布等整个软件生命周期的各个环节，其中第一部分介绍API的设计、构建和测试，第二部分介绍如何开展API流量管理，第三部分阐述API运维、发布和安全管理之道，第四部分介绍API架构的迭代演进。本书内容贴近实践，易于理解和应用。此外，书中的大量引用、深度阅读链接和工具推荐，不仅彰显了三位作者的深厚学识和实战经验，更为读者提供了丰富的延伸阅读和实际操作参考。
三位作者都是资深开发人员，也各有所长—有的擅长API架构设计和实施，有的是曾获得Java Champion的Java社区的关键影响者；有的熟悉安全架构，在摩根士丹利这样的世界级投行负责系统开发—他们基于各自的理论积累和项目实践为本书做出了贡献。
当我们第一次接触这本书时，便被其内容吸引，心生将其翻译成中文的愿望，以便国内的同行能从中受益。在数月的翻译过程中，我们深刻感受到了本书的实用价值。事实上，书中的许多内容我们已经在实际工作中采纳并取得了显著的效果。
在此衷心感谢施勇、许惊皞、付晓岩、杜军、徐鸣、马成明、王劲松、马欢、黄勇、张礼立、刘安、张海涛、胡萍、贾瑞起、黄磊等15位来自云计算、应用开发、网络安全、数据管理、科技创投、电子商务等方面的前辈和专家给我们在翻译过程中和成稿后的专业意见，他们的意见为我们探索API架构在各相关领域的应用价值提供了动力。
我们由衷感谢出版社的支持与信任，并期待中文版能早日与大家见面。
序
10 多年前，当我在英国《金融时报》构建第一个 API 时，并没有那么多API。我们实现 的是单体架构，API 仅供外部第三方访问我们的内容。
然而现在，API 无处不在，它们是成功构建系统的核心。
这是因为，在过去的 10 年里，有几件事结合在一起改变了软件开发的方式。
首先，我们可用的技术发生了变化。云计算的兴起为我们提供了自助式、按需配置的服 务。自动化构建和部署管道使我们能够进行持续集成和部署，容器及其相关技术（如编 排）让我们能够在分布式系统中运行大量小型、独立的服务。
为什么我们要那么做？因为研究表明，成功的软件开发组织具有松耦合的架构和独立自 主的团队。这里的“成功”是指对企业产生积极影响：增加市场份额、改进生产效率和 提升盈利能力。
现在的架构往往更加松耦合、分布式，并且围绕 API 构建。你希望 API 易于发现、有较 强一致性且不会给消费者带来问题，即使消费者执行了意外操作或彻底离开。任何其他 解决方案都会将工作耦合在一起，减缓团队的开发速度。
在这本书中，James 、Daniel 和 Matthew 提供了一份全面且实用的指南，教你如何构建 高效的 API 架构。内容涵盖多个领域，从如何构建和测试单个 API 到如何部署它们的生 态系统，以及如何对它们进行有效的发布和运维，最重要的是如何使用 API 来演进你的 架构。我在《金融时报》构建的第一批 API 已经不存在了，我们从头开始重新构建了那 些系统。那样做代价不菲，James 、Daniel 和 Matthew 提供了一个模板，教你如何应对 不可避免的变化，并使用 API 作为关键工具来演进你的系统。
软件架构被定义为那些既重要又难以改变的决策。这些决策将决定你项目的成败。
作者的关注点不是抽象的架构，而是如何在你自己的组织中应用架构。决定采用 API 网
关还是服务网格，以及具体选择哪一款产品，都是你应该谨慎对待并仔细评估的难以回 退的决策。James 、Daniel 和 Matthew 在他们认为适当的地方给出了明确的、有见地的 指导，而在不太明确的地方，他们提供了一个框架来帮助你根据自己的情况做出最佳 选择。
他们用一个实用的现实案例研究来说明概念，并展示如何在实践中真正运用这些概念。 该案例研究在整本书中不断演进，就像真实的系统一样。作者通过这种方式说明你不必 一开始就把所有工作都做好，而是可以逐步演进你的架构，逐步提取服务，并在需要时 添加 API 网关和服务网格等工具。
我在构建第一个 API 时犯了很多错误。我希望当时有这样一本书，能帮助我了解自己可 能会在哪里犯错，并引导我做出明智的决策。
我向任何在以 API 为核心的系统上担任领导工作的人推荐这本书。有了它，你将能够为 组织中的每个 API 构建团队开发一套标准化的工具和规范。
—Sarah Wells ，
QCon 伦敦会议联席主席，独立顾问，前《金融时报》技术总监， 2022 年 9 月于英国雷丁
前言
我们为什么要撰写本书
2020 年初，我们参加了纽约的 O’Reilly 软件架构大会，期间James 和 Matthew 举办了 一场关于 API 和 API 网关的研讨会。James 和 Daniel 相识于伦敦 Java 社区，与许多有 关架构的活动一样，我们聚在一起讨论对 API 架构的想法和理解。当我们在走廊上交谈 时，有几位会议代表过来与我们交流他们在 API 方面的经验，也有人询问我们关于 API 的想法和建议。这时，我们认为撰写一本关于 API 主题的书有助于将我们在会议上讨论 的内容与其他架构师分享。
你为什么应该阅读本书
本书旨在提供关于设计、运维和演进 API 架构的全景图。我们通过文字和一个配套的案 例研究分享了我们的经验和建议，本书中的案例研究模拟了真实的活动管理会议系统， 该系统使参会者能够查看和预订演讲会议场次。该案例研究贯穿全书，目的是让你能够 将抽象的概念转化为实际的应用。如果你只想粗略地看一下这个案例研究的整个演进过 程，可以直接参考第 10 章的内容。
我们相信允许你自行决策的重要性，为此，我们将：
? 明确给出可行的建议和指导。
? 强调可能遇到的注意事项和问题。
? 提供一个架构决策记录（Architecture Decision Record ，ADR）指南注 1 ，以在特定 的架构情况下提供最佳决策，并提供相关考虑因素的指导（因为有时答案“因情况 而异”）。
? 推荐参考资料和有价值的文章，以便你深入阅读。
本书不仅是一本全新的技术书籍。我们认为，覆盖现有架构并以演进的方式逐步转向更 合适的 API 架构，将给你带来最大的收益。同时，我们也尽可能地介绍了API 架构领域 中的前沿技术和对未来发展的展望。
目标读者
尽管我们在编写本书时关于目标读者已经有了一个最初的角色设想，但在写作和审校过 程中还是出现了三个关键角色：开发人员、半路出家的架构师、解决方案架构师或企业 架构师。我们在下文概述了这些角色， 目的是希望你不仅能认同这些角色，而且还能通 过这些角色所提供的不同视角来阅读每一章。
开发人员
你很可能已经有几年的专业编码经验，并对常见的软件开发挑战、模式和最佳实践有很 好的理解。你越来越意识到，软件行业正朝着构建面向服务的架构（SOA）和采用云服 务的方向发展，这意味着构建和运营 API 正迅速成为一项核心技能。你渴望了解更多关 于设计有效 API 和测试它们的知识。你希望探索各种不同的实现方法（例如同步与异步 通信）和技术，并学习如何提出正确的问题和评估不同方法的最佳使用场景。
半路出家的架构师
你很可能已经从事软件开发多年，并经常担任团队负责人或常驻软件架构师（即使没有 官方职称）。你理解核心的架构概念，比如高内聚性和低耦合性的设计，并将其应用于 软件开发的各个方面，包括设计、测试和运维系统。
你意识到，你的角色越来越专注于将系统组合起来以满足客户需求。这可能包括内部构 建的应用程序和第三方 SaaS 类型的服务。API 在成功地将你的系统与外部系统集成方面 起着重要作用。你希望了解更多相关的支撑技术（例如 API 网关、服务网格等），并且 还想了解如何运维和保护基于 API 的系统。
解决方案架构师 / 企业架构师
你已经设计和构建企业软件系统多年，并且很可能在你的职位或角色描述中包含“架构 师”一词。你对软件交付的整体情况负责，并通常在大厂或集团公司环境中工作。
你认识到最新一代基于服务的架构风格对软件的设计、集成和治理所带来的变化，并且 认为 AP
评论
还没有评论。