云原生

鲍里斯·肖勒（Boris Scholl）是Azure计算团队的产品架构师，专注于下一代分布式系统平台和应用程序模型的研究。自2011年以来，他一直从事Azure开发工具和平台方面的工作，担任不同的产品研发角色。在离开微软18个月之后，Boris于2018年重新加入Azure计算团队，领导一个研发团队开发基于Kubernetes和服务网格的微服务平台。

特伦特·斯旺森（Trent Swanson）是专注于云和边缘技术的软件架构师。作为Full Scale 180的联合创始人和顾问，他与微软的一些大客户合作，帮助他们将应用迁移上云，或在云中构建应用。他一直致力于利用Docker、无服务器技术和微服务架构来设计、构建和运行大型应用程序。

彼得·加索维奇（Peter Jausovec）是一位软件工程师，在软件开发和技术领域拥有十多年的经验。在他的职业生涯中，...

(展开全部)

鲍里斯·肖勒（Boris Scholl）是Azure计算团队的产品架构师，专注于下一代分布式系统平台和应用程序模型的研究。自2011年以来，他一直从事Azure开发工具和平台方面的工作，担任不同的产品研发角色。在离开微软18个月之后，Boris于2018年重新加入Azure计算团队，领导一个研发团队开发基于Kubernetes和服务网格的微服务平台。

特伦特·斯旺森（Trent Swanson）是专注于云和边缘技术的软件架构师。作为Full Scale 180的联合创始人和顾问，他与微软的一些大客户合作，帮助他们将应用迁移上云，或在云中构建应用。他一直致力于利用Docker、无服务器技术和微服务架构来设计、构建和运行大型应用程序。

彼得·加索维奇（Peter Jausovec）是一位软件工程师，在软件开发和技术领域拥有十多年的经验。在他的职业生涯中，他曾担任过各种角色。近年来，他一直致力于开发分布式系统上的云原生解决方案。

前言 1
第1章 云原生简介 5
1.1 分布式系统 5
1.1.1 分布式系统的误区 5
1.1.2 CAP定理 8
1.2 十二要素应用 8
· · · · · · (更多)

前言 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
· · · · · · (收起)