本书旨在能够提供一些基础知识，来帮助开发者和架构师更从容地开启云原生应用之旅。本书首先介绍一些分布式系统的基本原理及其与云原生应用的关系，然后再进一步介绍容器和函数等相关技术，接着，本书会介绍服务间的通信模式、服务的弹性和数据模式，并讨论在什么情况下应该使用这些技术，最后会总结一些经验性的东西，例如如何结合DevOps方法，怎么兼顾可移植性，以及一些最佳实践。这些最佳实践对于打造一个成功的云原生应用是非常有帮助的。这本书不会手把手教你如何实现一个满足特定业务需求的云原生应用。但是在读完这本书之后，你一定会知道如何去设计、构建和运维一个成功的云原生应用。

无

不同公司和行业的精神领袖常常会重述Watts Humphrey的观点：“任何企业最终都将变成一家软件企业。”他对形势的判断确实非常准确。软件正在冲击每个企业的现状，悄然改变着世界。Netflix彻底颠覆了我们收看电视和电影的习惯，Uber改变了运输业，而Airbnb正在挑战酒店业。这一切在几年前还是不可想象的，但现在各种创新企业正借助软件的力量渗透到各行各业中去，并为这些行业带来新的思维方式和商业模式。
前面提到的这几家公司常常被称为“诞生在云上的公司”，这句话的意思是这些公司的产品都是在各类云服务的基础上构建的。在云上构建这些服务使得公司能够快速响应市场，满足客户需求。云计算可以带来很多好处，比如可以快速更新和修改、易于使用新技术，并利用云端资源的集群优势来降低成本，改善经济效益。以云原生的方式构建的服务还可能带来新的商业模式。利用这些服务，公司可以重新审视现有的商业模式并考虑向新的业务模式转变，例如基于订阅的商业模式。我们通常把这类服务称为云原生应用。
随着云原生应用的成功和普及，越来越多的企业开始采用云原生架构来开发软件，有些甚至把云原生的理念运用到了传统企业软件中。
容器、函数和数据是云原生应用的核心。对于这些特定的技术，已经有很多书去阐述了。云原生应用整合了所有这些技术，使得云计算的优势得到了充分发挥。作为作者，我们看到有很多人正努力尝试利用这些技术来设计和开发云原生应用，因此我们决定写这本书。其目的是提供一些基础知识，来帮助开发者和架构师更从容地开启云原生应用设计之旅。
本书一开始先讲基础知识，让读者了解一些分布式系统的基本原理及其与云原生应用的关系。然后再进一步介绍容器和函数等相关技术。接着，本书介绍服务间的通信模式、服务的弹性和数据模式，并讨论在什么情况下应该使用这些技术。最后，会总结一些经验性的东西，例如如何结合DevOps方法、如何兼顾可移植性，以及一些最佳实践。这些最佳实践对于打造一个成功的云原生应用是非常有帮助的。
这本书不会手把手教你如何实现一个满足特定业务需求的云原生应用。但是在读完这本书之后，你应该会知道如何去设计、构建和运维一个成功的云原生应用。在你去实现一些业务需求的时候，操作指南固然很有用，然而系统地理解云原生应用的基本原理和构建方法，才能使你的团队掌握打造成功的云原生应用的能力。
排版约定
本书的排版遵循以下约定：
斜体（Italic）
表示URL、电子邮件地址、文件名和文件扩展名。
等宽字体（Constant width）
用于程序示例，以及段落中引用的程序元素，如变量或函数名称、数据库、数据类型、环境变量、语句声明和关键字。
等宽粗体（Constant width bold）
表示应由用户输入的命令或其他文本。
等宽斜体（Constant width italic）
表示应替换成用户提供的值或由上下文确定的值。
该图标表示提示或者建议。
该图标表示一般说明。
该图标表示警告或警示。
O'Reilly在线学习平台（O扲eilly Online Learning）
近40年来，O'Reilly Media致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。
我们拥有独一无二的专家和革新者组成的庞大网络，他们通过图书、文章、会议和我们的在线学习平台分享他们的知识和经验。O扲eilly的在线学习平台允许你按需访问现场培训课程、深入的学习路径、交互式编程环境，以及O扲eilly和200多家其他出版商提供的大量文本和视频资源。有关的更多信息，请访问http://oreilly.com。
联系我们
请把你对本书的意见和疑问发给出版社：
美国：
O'Reilly Media，Inc.
1005 Gravenstein Highway North
Sebastopol，CA 95472
中国：
北京市西城区西直门南大街2号成铭大厦C座807室（100035）
奥莱利技术咨询（北京）有限公司
如果你对本书有任何评论或技术疑问，欢迎发送电子邮件到bookquestions@oreilly.com。
要了解O'Reilly的图书、培训课程、会议和新闻的更多信息，请访问我们的网站，地址是
http://www.oreilly.com。
我们的Facebook页面：http://facebook.com/oreilly。
我们的Twitter页面：http://twitter.com/oreillymedia。
我们的YouTube页面：http://www.youtube.com/oreillymedia。
致谢
我们要感谢O扲eilly的编辑Nicole Taché，以及技术审稿人和预览版的审稿人对本书的宝贵贡献。此外，我们要感谢Haishi Bai和Bhushan Nene，他们提出的细致评论和建议提高了这本书的质量。
Boris要感谢他的妻子Christina以及他的孩子Marie和Anton，感谢他们在他写书的时候给予的理解和支持。
Trent要感谢他的妻子Lisa和他的儿子Mark，感谢他们在这段时间的支持与理解。
Peter要感谢他的妻子Nives，正因为有她的支持、鼓励和理解，Peter才能把几乎所有的业余时间都花在写书上。

计算机/云计算

开发者们刚开始接触云端服务开发的时候或多或少都会遇到一些障碍。既要学习分布式系统的知识，又要熟悉像容器和函数计算这样的新技术，还要综合运用这些知识来构建云原生应用实在是件令人望而生畏的事情。本书可以帮助你掌握构建云原生应用的方法，比如消息通信、事件通知和DevOps等。
本书介绍了构建现代云原生应用的架构模块。你将学会如何使用微服务、容器、无服务器架构、函数计算等技术，并挑选合适的存储类型，同时考虑可移植性等问题。你会从云原生应用的基础知识开始，一步步地了解设计、开发和运维云原生应用的整个
过程。
? 探讨设计云原生应用所需的技术。
? 介绍容器和函数计算的区别，并学习它们的适用场景。
? 有针对性地设计应用来满足数据相关的需求。
? 学习DevOps的基础知识和一些开发、测试、运维实践。
? 学习一些构建和管理云原生应用的技巧、方法和实践。
? 理解构建一个具有可移植性的应用所需的代价，并且学会对需求做出取舍。
Boris Scholl是Azure计算团队的产品架构师，专注于下一代分布式系统平台和应用程序模型的研究。
Trent Swanson是Full Scale 180的联合创始人和顾问。他帮助了不少微软的大客户把应用迁移上云，或在云中构建应用。
Peter Jausovec是一名软件工程师，在软件开发和技术领域有10多年的经验。

[美]鲍里斯·肖勒（Boris Scholl） 特伦特·斯旺森（Trent Swanson） 彼得·加索维奇（Peter Jausovec） 著：鲍里斯·肖勒（Boris Scholl）是Azure计算团队的产品架构师，专注于下一代分布式系统平台和应用程序模型的研究。自2011年以来，他一直从事Azure开发工具和平台方面的工作，担任不同的产品研发角色。在离开微软18个月之后，Boris于2018年重新加入Azure计算团队，领导一个研发团队开发基于Kubernetes和服务网格的微服务平台。
特伦特·斯旺森（Trent Swanson）是专注于云和边缘技术的软件架构师。作为Full Scale 180的联合创始人和顾问，他与微软的一些大客户合作，帮助他们将应用迁移上云，或在云中构建应用。他一直致力于利用Docker、无服务器技术和微服务架构来设计、构建和运行大型应用程序。
彼得·加索维奇（Peter Jausovec）是一位软件工程师，在软件开发和技术领域拥有十多年的经验。在他的职业生涯中，他曾担任过各种角色。近年来，他一直致力于开发分布式系统上的云原生解决方案。

随着“云计算”的兴起，越来越多的公司开始“上云”。很多公司的上云之路是从传统应用的迁移开始的，但越来越多的创新企业开始直接基于云基础设施来设计、开发新一代应用。于是“云原生应用”这个概念这两年也变得愈发火热。这种“诞生在云上的公司”往往具备很多不同寻常的特质，这使其具有快速爆发的潜力。利用公有云丰富的IaaS、PaaS和SaaS产品，公司可以实现业务的高度弹性，也便于实现数据驱动的运营。毫无疑问，“云原生”正悄然改变着软件开发的传统思维和模式。
随着云原生的成功和普及，我们可以看到除了创新企业，被软件渗透的各行各业也都开始关注这一领域，并进行尝试。云原生这个概念涵盖的内容很广泛，也有很多新的框架和工具可以使用。传统开发人员和架构师在接触云原生这个概念后往往会从寻找一个时髦的框架和工具开始云原生之旅。译者本人也不例外。但随着使用的深入，越来越多的困难和挑战会随之而来。和所有技术一样，云原生也不是一颗“银弹”。其本质是一个理念，而在这个理念的背后是云计算、容器、函数计算等核心技术，而这些技术扩展开又会涉及很多特定的技术和最佳实践。市面上已经有很多书在阐述这些特定的技术了，但是能够把这些技术综合起来，围绕云原生去系统地介绍这些技术的基础概念和知识、应用场景和最佳实践，是这本书最大的特色。
作为一名云计算领域的老兵，翻译这本书的过程也是我翻新知识的过程。翻译的过程中很容易会将新的概念、技术与我已经了解的老概念和技术联系起来，帮我理清其中的关系。本书不是一本可供你查阅所有细节的工具书，也不是一本让你看得津津有味却又无从下手的纯理论书，它更像一本参考手册，你可以从中了解云原生的前世今生，也可以了解其核心应用场景，更重要的是它还总结了很多经验性的东西，这些最佳实践就像最后的临门一脚，让你能够快速从理论走入实践。
本书的翻译前后花了两个多月的时间，为了保证专业词汇翻译的准确性，在翻译的过程中我查阅了大量相关资料。同时部分专业词汇也保留了英文，对于大多数专业人员而言，这些英文词汇往往比中文更容易理解。在翻译中，我尽量使用平直的语言，对部分内容做了意译，希望能使读者更顺畅地去理解书中的内容。然而，个人的时间和能力有限，书中难免会存在疏漏和不尽如人意之处，希望各位同仁不吝赐教，不胜感激。
最后，我想感谢思岚科技CTO黄珏珅、运维负责人陈轶群对本书翻译提供的帮助和指导。同时也感谢我的家人，在我将大量业余时间投入翻译的时候义无反顾地承担起了大部分家庭事务。没有你们的帮助和支持，我无法顺利地完成翻译工作。
愿各位读者能从本书中获益。

季奔牛
2020年2月25日

前言 1
第1章 云原生简介 5
1.1 分布式系统 5
1.1.1 分布式系统的误区 5
1.1.2 CAP定理 8
1.2 十二要素应用 8
1.3 可用性和服务等级协议 11
1.4 本章小结 12
第2章 云原生基础 13
2.1 容器 13
2.1.1 容器隔离等级 15
2.1.2 容器编排 16
2.1.3 Kubernetes概述 17
2.1.4 Kubernetes和容器 20
2.2 无服务器架构 21
2.3 函数计算 22
2.4 从虚拟机到云原生 23
2.4.1 提升和转变 23
2.4.2 应用的现代化改造 24
2.4.3 应用的优化 26
2.5 微服务 26
2.5.1 微服务架构的优势 27
2.5.2 微服务架构带来的挑战 29
2.6 本章小结 31
第3章 云原生应用的设计 33
3.1 云原生应用的基础 33
3.1.1 精益运营 33
3.1.2 安全性 35
3.1.3 可靠性与可用性 36
3.1.4 可扩展性与成本 37
3.2 云原生与传统架构的对比 37
3.3 函数计算与服务 41
3.3.1 函数计算的使用场景 42
3.3.2 使用函数计算的考虑因素 42
3.3.3 函数与服务的组合运用 43
3.4 API设计与版本控制 45
3.4.1 API的前后兼容 46
3.4.2 语义版本号 47
3.5 服务间的通信 48
3.5.1 通信协议 48
3.5.2 消息协议 50
3.5.3 序列化的考虑因素 50
3.5.4 幂等性 51
3.5.5 请求与响应 52
3.5.6 发布者与订阅者 53
3.5.7 发布者/订阅者模式与请求/响应模式间的选择 55
3.5.8 同步与异步 56
3.6 网关 56
3.6.1 路由 57
3.6.2 聚合 58
3.6.3 卸载 59
3.6.4 网关的实现 60
3.7 出口网关 60
3.8 服务网格 60
3.9 架构示例 69
3.10 本章小结 73
第4章 数据处理 75
4.1 数据存储系统 76
4.1.1 对象、文件和磁盘 77
4.1.2 数据库 78
4.1.3 流和队列 80
4.1.4 区块链 81
4.1.5 数据存储的选择 81
4.2 多数据存储下的数据 84
4.2.1 捕获数据更改 85
4.2.2 将更改作为事件写入更改日志 87
4.2.3 事务监管 88
4.2.4 事务回滚 90
4.2.5 提取、转换和加载 90
4.2.6 微服务和数据湖 91
4.3 客户端访问数据 94
4.3.1 受限的客户令牌（代客密钥） 94
4.3.2 细粒度访问控制的数据库服务 95
4.3.3 GraphQL数据服务 96
4.4 可快速伸缩的数据 97
4.4.1 数据分片 98
4.4.2 数据缓存 98
4.4.3 内容分发网络 99
4.5 数据分析 101
4.5.1 数据流 101
4.5.2 批处理 101
4.5.3 对象存储上的数据湖 102
4.5.4 数据湖和数据仓库 102
4.5.5 分布式查询引擎 103
4.6 Kubernetes中的数据库 104
4.6.1 存储卷 104
4.6.2 StatefulSet 106
4.6.3 DaemonSet 107
4.7 本章小结 107
第5章 DevOps 109
5.1 什么是DevOps 109
5.1.1 协作 109
5.1.2 自动化 110
5.1.3 精益原则和流程 110
5.1.4 度量 111
5.1.5 分享 111
5.2 测试 112
5.2.1 测试替身 113
5.2.2 自动化测试金字塔 113
5.2.3 不同测试类型的适用时机 118
5.2.4 测试节奏 119
5.2.5 在生产环境中测试 120
5.3 开发环境和工具 122
5.3.1 开发工具 123
5.3.2 开发环境 126
5.3.3 本地开发环境 126
5.3.4 本地开发环境结合远端集群 127
5.3.5 Skaffold开发工作流 127
5.3.6 将远端集群路由到本地开发环境 129
5.3.7 云端开发环境 129
5.4 持续集成/持续交付 130
5.4.1 源代码管理 131
5.4.2 构建阶段 132
5.4.3 测试阶段 132
5.4.4 部署阶段 134
5.4.5 发布阶段 136
5.4.6 发布后阶段 137
5.5 监控 137
5.5.1 收集指标 139
5.5.2 服务的可观测性 145
5.6 配置管理 149
5.6.1 单一环境变量 151
5.6.2 多环境变量 151
5.6.3 将配置数据放入存储卷中 152
5.6.4 密钥保存 152
5.6.5 部署配置 154
5.7 持续集成/持续交付流程示例 156
5.8 本章小结 159
第6章 最佳实践 161
6.1 迈向云原生 161
6.1.1 找个合理的理由打破巨石应用 161
6.1.2 先解耦简单的服务 162
6.1.3 学会小规模的运维 162
6.1.4 使用防损层模式 162
6.1.5 使用刀砍模式 162
6.1.6 准备一个数据迁移策略 164
6.1.7 重写所有模板代码 164
6.1.8 重新考虑框架、语言、数据结构和数据存储 164
6.1.9 淘汰老代码 164
6.2 确保弹性 164
6.2.1 用重试来解决瞬时故障 165
6.2.2 使用有限次的重试 165
6.2.3 用断路器来处理非瞬时故障 166
6.2.4 优雅地降级 166
6.2.5 使用隔离模式 166
6.2.6 实现健康及就绪检查 166
6.2.7 为容器设定CPU和内存限制 166
6.2.8 实现限速和限流 167
6.3 确保安全性 167
6.3.1 安全性需求同其他需求一样重要 167
6.3.2 在设计时就考虑安全性 167
6.3.3 授予最小访问权限 167
6.3.4 使用独立的账号、订阅和租客 167
6.3.5 安全地存储所有密钥 168
6.3.6 模糊化数据 168
6.3.7 传输数据加密 168
6.3.8 使用联合身份管理 168
6.3.9 使用基于角色的访问控制 168
6.3.10 Kubernetes pod的隔离 169
6.4 处理数据 169
6.4.1 使用托管数据库和数据分析服务 169
6.4.2 使用最符合数据需求的存储 169
6.4.3 将数据保存在多个地域或可用区中 170
6.4.4 使用数据分区和复制以提高扩展性 170
6.4.5 避免过度获取及频繁的I/O操作 170
6.4.6 不要把业务逻辑放在数据库中执行 170
6.4.7 使用类生产环境数据来测试 170
6.4.8 处理瞬时故障 171
6.5 性能和伸缩性 171
6.5.1 设计可扩展的无状态服务 171
6.5.2 使用平台的自动伸缩功能 171
6.5.3 使用缓存 172
6.5.4 用分区来实现超出服务限制的扩容 172
6.6 函数计算 172
6.6.1 编写单一用途的函数 172
6.6.2 避免串联函数 172
6.6.3 函数应保持轻量和简单 173
6.6.4 实现无状态函数 173
6.6.5 分离函数入口和函数的业务逻辑 173
6.6.6 避免长时间运行的函数 173
6.6.7 用队列解决跨函数通信问题 173
6.7 运维 173
6.7.1 部署和发布是两项独立的活动 174
6.7.2 部署的内容要尽量小 174
6.7.3 组件层级的CI/CD定义 174
6.7.4 应用部署的一致性 174
6.7.5 采用零宕机发布 174
6.7.6 不要变更部署后的架构 174
6.7.7 使用容器化构建 175
6.7.8 用代码来描述基础设施 175
6.7.9 使用命名空间来组织Kubernetes中的服务 175
6.7.10 环境间的隔离 175
6.7.11 分隔函数源代码 175
6.7.12 关联代码提交和部署 175
6.8 日志、监控及告警 175
6.8.1 使用统一的日志系统 176
6.8.2 使用关联ID 176
6.8.3 在日志记录中包含上下文 176
6.8.4 统一的结构化日志格式 176
6.8.5 适当地标记指标 176
6.8.6 避免告警疲劳 177
6.8.7 定义基于重点性能指标的告警 177
6.8.8 在生产环境中持续测试 177
6.8.9 从基础的指标开始 178
6.9 服务通信 178
6.9.1 设计时考虑前后兼容性 178
6.9.2 封装好服务避免泄露内部细节 179
6.9.3 优先考虑异步通信 179
6.9.4 使用高效的序列化技术 179
6.9.5 使用队列和流来应对高负载和流量高峰 180
6.9.6 用批处理来提高请求处理的效率 180
6.9.7 拆分大的消息 180
6.10 容器 180
6.10.1 将镜像存储在可信的注册服务器中 180
6.10.2 充分利用Docker的构建缓存 181
6.10.3 不要使用特权模式运行容器 181
6.10.4 使用显式的容器镜像标签 181
6.10.5 保持小的容器镜像 181
6.10.6 单个容器只运行一个应用 182
6.10.7 使用可信镜像仓库中经过验证的镜像 182
6.10.8 对镜像进行漏洞扫描 182
6.10.9 不要将数据保存在容器中 183
6.10.10 永远不要在容器中存放密钥和配置 183
6.11 本章小结 183
第7章 可移植性 185
7.1 为什么要使应用可移植 185
7.2 可移植性的代价 186
7.3 何时及如何实现可移植性 187
7.3.1 标准化的接口 188
7.3.2 共用的服务和功能 189
7.3.3 抽象和分层 189
7.3.4 第三方服务商的托管服务 191
7.3.5 可移植性工具 192
7.3.6 把Kubernetes作为可移植性层 194
7.4 本章小结 196