持续演进的Cloud Native：云原生架构下微服务最佳实践-图书

推荐1
收藏3
浏览1.1K

持续演进的Cloud Native：云原生架构下微服务最佳实践

书　　号：978-7-121-35120-4
出版日期：2018-10-30
页　　数：316
开　　本：16(185*235)
出版状态：上市销售
维护人：张春雨

纸质版￥79.00

云化架构是一个全新概念，包含微服务、十二因子、敏捷基础设施和持续交付这些新老热点。而Cloud Native则是目前实现云化架构最有希望的技术解决方案，其建筑在传统Cloud的三层（IaaS、PaaS、SaaS）概念之上，其中敏捷基础设施对应IaaS部分，微服务则可以对应PaaS和SaaS部分。本书内容基于Cloud Native原理展开，重点描述云化架构的组成部分，及其相关理论和实践。本书来自作者在实际工作的经验积累，内容既有经典理论，又有丰富的实战案例，更不乏关键问题的完整解决方案。

华为架构领军人物考察大量微服务失败案例，直指“架构-研发流程-团队文化”全局体系，实现从交付型软件到云服务的进化。

序

架构没有绝对的对与错
在技术的领域里，并不存在“上帝”。没有人的每句话都是对的，没有人的所有思想都能被别人所接受。
我经常在公司范围内培训，首先是灌输架构思想和解决方案，然后会在实战演练中模拟一个比较简单的业务场景，把所有人分成4个团队，每个团队大概有10个人。结果发现，每个团队最终形成的架构图总有很大差异，很难评价一个团队的做法是对是错。例如，是要拆分为3个服务，还是5个服务，他们有各自的理由，除非比较明显的问题，否则你很难以一个理由去否定另一个理由。原因只是各个团队站在了不同的维度综合判断、权衡，形成了自己认为满意的架构方案。因此，架构没有绝对的对与错，只是在不同的角度做出的决定而已。
架构很难被衡量
每个公司的管理层都希望尽可能地去衡量架构的先进性，希望认清差距，向着好的架构方向不断演进。然而架构很难被衡量，须同时具备差距特别明显、制定指标的人能力达到一定高度、业务场景比较接近这三条才有可能衡量。当然我们可以去制定一些指标，这些指标应该是参考性的，作为一个自检项，而不是评价标准。从这个角度看，并不是符合Cloud Native就是好的，不符合就是差的，当不符合时，你的理由是什么？你站在问题的哪个角度？
Martin Fowler曾说：“优秀的技术人员的观点胜过任何度量，尽管它是主观的。”
因为你无法统一每个人关注的点，以及对各自关注的点的重视程度，所以架构很难被衡量。
架构需要持续演进
在传统企业中，架构设计是一个很重要且很耗费时间的过程，需要经过很多轮审核，架构文档动辄几百页，而且这个文档绝对不能有没考虑到的问题，必须面面俱到、接近完美。例如，目前系统还没有用户，就要为未来1千万的用户耗费精力解决性能问题，而且软件永远有你想象不到的问题发生。实际上我们描述的是一种静止的架构，这种架构每次变更都需要耗费巨大的成本。如果此时恰好出现了一个基于敏捷思想的竞争对手，则会形成一种鲜明的对比，他们不去考虑太长时间之后的事，出现什么问题就解决什么问题，因为有可能一年以后这个项目死了，也有可能用户人数突破1亿，系统需要进行大规模重构。总之，未来是不确定的。可见，架构是锤炼出来的，而不仅是设计出来的。
反应速度是传统企业的硬伤，这不是通过加班就能解决的。可以看一下互联网巨头们每年的发布次数，动辄每年发布几百万乃至上千万次，每个服务每天都在发生变化，每周可能都会上线。在如今这个快速发展的世界里，你无法依赖一个人去做所有的决策。这就需要发挥所有成员的主观能动性，也就是说，架构应该交给一线决策。回到前面提到的问题，服务怎么拆分更好？我想只有深入了解需求、场景、目标甚至自身条件之后才能做出决策。并且，架构的演进不是一蹴而就的，而是一个长期发展的过程。
变革需要坚决
历史上的变革大多阻力重重，因为一旦变革就意味着打破原有的“默契”，打破原有的“潜规则”，而“顽固派”通常是原有文化的受益者，他们通常不会反对变革，而是通过“我们不能完全照抄，要走出适合我们的路”来促成妥协。如果变革过程中遇到任何风吹草动，就更会给“顽固派”各种理由“走自己的路”。这也就是为什么我们熟知世界领先IT企业的技术、研发流程和企业文化，而就是学不会的原因。
这时候需要的是企业领导者的果断、坚决。只要方向没错，就要坚持，决不动摇。下面这段话是马云对刘振飞（阿里技术保障部负责人）关于阿里云内部争议的回复，反映了一个领导者在企业变革过程中起到的作用。
在王坚加入阿里之前，我跟教授（指曾鸣）讨论公司的未来，觉得云计算和大数据代表未来，对国家和社会的发展有长远的意义，所以我们要干，这是第一点。但是怎么做云计算、大数据？我们谁也不知道。现在来了个人叫王坚，他说：“我知道怎么做”，为什么不支持呢？这是第二点。第三点，即使万一做失败了，那也没关系，咱们的人倒下70%，还有30%活着，咱们活下来的人打扫战场，换个方向继续干，总要把它做出来。
写代码不同于搬砖
如果是搬砖，那么效率高的人和效率低的人之间的差距不会太大，因此每个人每天的工资都是相对固定的。但是在如今这个知识爆炸的时代，对于从事软件行业的群体来说，效率高者的工作效率比效率低者的可能高出几十倍、几百倍，优秀的人能写出更高质量的代码，能够预测问题。而在这个行业越是优秀的人才越是稀缺，因此很多互联网公司都愿意花大价钱去招一些更优秀的人。
优秀的人不愿意来，不一定是因为钱。花钱雇佣优秀的人是一方面，怎样管理这些人又是另外一方面，用管理搬砖者的方式来管理他们是不行的，管理优秀的人需要给予他们更多的信任，需要营造一种公开透明、自由高效的环境。
关于本书
为什么会出现Cloud Native这个概念呢？无论是云化、平台化，还是微服务架构，又或者是敏捷开发、自动化，都只是描述了几个点，而Cloud Native更像是一个面，通过它把这些点都关联起来了。某几个点做得很好而忽略了其他点通常会走入误区。例如，某些团队只关注服务拆分，而忽略了工具、组织对微服务的影响，最终效果并不理想。又如，要提升系统的可用性，只是从技术的角度去考虑是不够的，还要考虑如何通过自动化测试提升可用性，如何通过Code Review提升可用性，以及当故障发生时如何快速修复。我希望通过个人的工作经历以书的方式传递一些这方面的经验教训。
本书分别从架构、研发流程、团队文化三个角度全面论述Cloud Native，因为只有三方面配合才能达到理想的效果。我见到过无数失败的案例，绝大多数都是因为考虑得比较片面，例如单纯从架构角度进行变革，或者单纯从研发流程角度变革。我们希望模仿Google、Facebook、Amazon、Netflix等领先企业，但是往往高估了架构的影响力，而低估了研发流程和团队文化的影响力。实际上，研发流程和团队文化对架构有着非常重要的影响。本书以Cloud Native的起源、诉求及组成开始，全面描述了Cloud Native的各个方面。从架构角度阐述了如何实施微服务架构，如何构建敏捷基础设施及平台服务。同时，从可用性、可扩展性、性能、一致性等角度描述了微服务架构中产生的问题及解决方案。最后，分别描述了Cloud Native下的研发流程和团队文化。
本书比较适合技术管理者、架构师和有一定基础的技术人员阅读，特别是传统软件企业的技术领导者，以及希望向互联网公司转型的或者转型失败的企业技术领导者。此书将帮助这些人少走弯路。还有一些比较有经验的高级研发人员，阅读此书也利于系统掌握Cloud Native的关键技能。无论如何，都希望此书能给你带来较好的体验，使你获得启发。
书中的内容大多来自我的工作经验，不免存在遗漏及错误，欢迎指正。读者可以直接发送邮件到我的邮箱（41309975@qq.com），在此提前表示感谢。
感谢工作中的各位同事、生活中的各位好友，正是他们的支持和鼓励，才让本书完成。更要感谢我的家人，特别是我的妻子和女儿，是她们的拥抱和灿烂的笑容让我坚定了信念。

王启军

轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。
? 提交勘误：您对书中内容的修改意见可在提交勘误处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。
? 交流互动：在页面下方读者评论处留下您的疑问或观点，与我们和其他读者一同学习交流。
页面入口：http://www.broadview.com.cn/35120

目录

第1章综述 1
1.1 Cloud Native的起源 1
1.2 Cloud Native的组成 4
1.3 Cloud Native背后的诉求 5
1.4 如何衡量Cloud Native的能力 5
1.5 Cloud Native的原则 6
第2章微服务架构 11
2.1 微服务架构的起源 11
2.2 为什么采用微服务架构 12
2.2.1 单体架构与微服务架构 12
2.2.2 什么时候开始微服务架构 14
2.2.3 如何决定微服务架构的拆分粒度 14
2.3 微服务设计原则 15
2.4 微服务架构实施的先决条件 17
2.4.1 研发环境和流程上的转变 17
2.4.2 拆分前先做好解耦 18
2.5 微服务划分模式 20
2.5.1 基于业务复杂度选择服务划分方法 20
2.5.2 基于数据驱动划分服务 21
2.5.3 基于领域驱动划分服务 22
2.5.4 从已有单体架构中逐步划分服务 23
2.5.5 微服务拆分策略 24
2.5.6 如何衡量服务划分的合理性 25
2.6 微服务划分反模式 26
2.7 微服务API设计 28
2.7.1 优秀API的设计原则 28
2.7.2 服务间通信——RPC 28
2.7.3 序列化——Protobuf 30
2.7.4 服务间通信——RESTful 33
2.7.5 通过Swagger实现RESTful 36
2.7.6 通过Spring Boot、Springfox、Swagger实现RESTful 41
2.7.7 HTTP协议的进化——HTTP/2 46
2.7.8 HTTP/2和Protobuf的组合——gRPC 48
2.8 微服务框架 53
2.9 基于Dubbo框架实现微服务 54
2.10 基于Spring Cloud框架实现微服务 58
2.11 服务发现场景下的ZooKeeper与Etcd 67
2.12 微服务部署策略 68
2.12.1 服务独享数据库 69
2.12.2 服务独享虚拟机/容器 70
2.13 为什么总觉得微服务架构很别扭 70
第3章敏捷基础设施及公共基础服务 73
3.1 传统基础设施面临的挑战 73
3.2 什么是敏捷基础设施 74
3.3 基于容器的敏捷基础设施 75
3.3.1 容器VS虚拟机 76
3.3.2 安装Docker 77
3.3.3 部署私有Docker Registry 79
3.3.4 基于Spring Boot、Maven、Docker构建微服务 79
3.3.5 基于docker-compose管理容器 84
3.4 基于公共基础服务的平台化 85
3.5 监控告警服务 86
3.5.1 监控数据采集 87
3.5.2 监控数据接收模式 87
3.5.3 通过时间序列数据库存储监控数据 88
3.5.4 开源监控系统实现Prometheus 88
3.5.5 通过Prometheus和Grafana监控服务 90
3.6 分布式消息中间件服务 96
3.6.1 分布式消息中间件的作用 97
3.6.2 业界常用的分布式消息中间件 98
3.6.3 Kafka的设计原理 99
3.6.4 为什么Kafka性能高 100
3.6.5 Kafka的数据存储结构 102
3.6.6 如何保证Kafka不丢消息 104
3.6.7 Kafka跨数据中心场景集群部署模式 106
3.7 分布式缓存服务 108
3.7.1 分布式缓存的应用场景 109
3.7.2 业界常用的分布式缓存Memcached 110
3.7.3 业界常用的分布式缓存——Redis 111
3.7.4 Redis常用的分布式缓存集群模式 112
3.7.5 基于Codis实现Redis分布式缓存集群 116
3.8 分布式任务调度服务 118
3.8.1 通过Tbschedule实现分布式任务调度 119
3.8.2 通过Elastic-Job实现分布式任务调度 123
3.9 如何生成分布式ID 126
3.9.1 UUID 126
3.9.2 SnowFlake 127
3.9.3 Ticket Server 128
3.9.4 小结 129
第4章可用性设计 130
4.1 综述 130
4.1.1 可用性和可靠性的关系 130
4.1.2 可用性的衡量标准 131
4.1.3 什么降低了可用性 131
4.2 逐步切换 132
4.2.1 影子测试 132
4.2.2 蓝绿部署 133
4.2.3 灰度发布/金丝雀发布 134
4.3 容错设计 135
4.3.1 消除单点 136
4.3.2 特性开关 136
4.3.3 服务分级 137
4.3.4 降级设计 138
4.3.5 超时重试 139
4.3.6 隔离策略 152
4.3.7 熔断器 153
4.4 流控设计 157
4.4.1 限流算法 157
4.4.2 流控策略 159
4.4.3 基于Guava限流 160
4.4.4 基于Nginx限流 162
4.5 容量预估 163
4.6 故障演练 164
4.7 数据迁移 165
4.7.1 逻辑分离，物理不分离 166
4.7.2 物理分离 166
第5章可扩展性设计 168
5.1 加机器能解决问题吗 168
5.2 横向扩展 169
5.3 AKF扩展立方体 170
5.4 如何扩展长连接 172
5.5 如何扩展数据库 175
5.5.1 X轴扩展——主从复制集群 175
5.5.2 Y轴扩展——分库、垂直分表 176
5.5.3 Z轴扩展——分片（sharding） 177
5.5.4 为什么要带拆分键 182
5.5.5 分片后的关联查询问题 183
5.5.6 分片扩容（re-sharding） 184
5.5.7 精选案例 187
5.6 如何扩展数据中心 190
5.6.1 两地三中心和同城多活 190
5.6.2 同城多活 191
5.6.3 异地多活 192
第6章性能设计 194
6.1 性能指标 195
6.2 如何树立目标 195
6.3 如何寻找平衡点 196
6.4 如何定位瓶颈点 197
6.5 服务通信优化 198
6.5.1 同步转异步 198
6.5.2 阻塞转非阻塞 199
6.5.3 序列化 200
6.6 通过消息中间件提升写性能 201
6.7 通过缓存提升读性能 202
6.7.1 基于ConcurrentHashMap实现本地缓存 203
6.7.2 基于Guava Cache实现本地缓存 204
6.7.3 缓存的常用模式 205
6.7.4 应用缓存的常见问题 207
6.8 数据库优化 208
6.8.1 通过执行计划分析瓶颈点 208
6.8.2 为搜索字段创建索引 209
6.8.3 通过慢查询日志分析瓶颈点 210
6.8.4 通过提升硬件能力优化数据库 211
6.9 简化设计 212
6.9.1 转移复杂度 212
6.9.2 从业务角度优化 212
第7章一致性设计 214
7.1 问题起源 214
7.2 基础理论 215
7.2.1 什么是分布式事务 216
7.2.2 CAP定理 218
7.2.3 BASE理论 219
7.2.4 Quorum机制（NWR模型） 219
7.2.5 租约机制（Lease） 220
7.2.6 状态机（Replicated State Machine） 221
7.3 分布式系统的一致性分类 222
7.3.1 以数据为中心的一致性模型 223
7.3.2 以用户为中心的一致性模型 226
7.3.3 业界常用的一致性模型 229
7.4 如何实现强一致性 230
7.4.1 两阶段提交 230
7.4.2 三阶段提交（3PC） 231
7.5 如何实现最终一致性 232
7.5.1 重试机制 232
7.5.2 本地记录日志 233
7.5.3 可靠事件模式 233
7.5.4 Saga事务模型 235
7.5.5 TCC事务模型 237
7.6 分布式锁 238
7.6.1 基于数据库实现悲观锁和乐观锁 239
7.6.2 基于ZooKeeper的分布式锁 241
7.6.3 基于Redis实现分布式锁 242
7.7 如何保证幂等性 244
7.7.1 幂等令牌（Idempotency Key） 244
7.7.2 在数据库中实现幂等性 246
第8章未来值得关注的方向 247
8.1 Serverless 247
8.1.1 什么是Serverless 247
8.1.2 Serverless的现状 248
8.1.3 Serverless的应用场景 249
8.2 Service Mesh 250
8.2.1 什么是Service Mesh 250
8.2.2 为什么需要Service Mesh 252
8.2.3 Service Mesh的现状 253
8.2.4 Istio架构分析 255
第9章研发流程 258
9.1 十二因子 258
9.2 为什么选择DevOps 261
9.3 自动化测试 263
9.3.1 单元测试 263
9.3.2 TDD 264
9.3.3 提交即意味着可测试 265
9.4 Code Review 265
9.4.1 Code Review的意义 265
9.4.2 Code Review的原则 266
9.4.3 Code Review的过程 267
9.5 流水线 267
9.5.1 持续交付 267
9.5.2 持续部署流水线 268
9.5.3 基于开源打造流水线 268
9.5.4 Amazon的流水线 271
9.5.5 开发人员自服务 271
9.6 为什么需要AIOps 272
9.7 基于数据和反馈持续改进 273
9.8 拥抱变化 274
9.9 代码即设计 274
第10章团队文化 276
10.1 为什么团队文化如此重要 276

10.2 组织结构 278
10.2.1 团队规模导致的问题 278
10.2.2 康威定律 278
10.2.3 扁平化的组织 279
10.2.4 独裁的管理方式还是民主的管理方式 280
10.2.5 民主的团队如何做决策 282
10.3 环境氛围 282
10.3.1 公开透明的工作环境 282
10.3.2 学习型组织 283
10.3.3 减少正式的汇报 284
10.3.4 高效的会议 284
10.3.5 量化指标致死 286
10.4 管理风格 287
10.4.1 下属请假你会拒绝吗 287
10.4.2 为什么你招不到你想要的人 288
10.4.3 得到了所有人的认可，说明你并不是一个好的管理者 291
10.4.4 尽量避免用自己的权力去做决策 291
10.4.5 一屋不扫也可助你“荡平天下” 292
10.4.6 如何留下你想要的人 293
10.5 经典案例 294
10.5.1 Instagram的团队文化 294
10.5.2 Netflix的团队文化 294

全部展开

本书勘误

页码：201 • 行数：14 • 印次： 1

MQ把依赖关系从强依赖变成若依赖，这里“若依赖”应该是“弱依赖”

huihawk 提交于 2018/11/26 10:08:25

张春雨确认于 2019/4/12 13:34:21

读者评论

第10页，在“演进式设计原则”部分，关于架构设计、功能、可用性的论述，需要商榷。“客户的需求并不是最初设计的”，设计和需求的关系，以及如何有效地做好需求工程，这是软件工程的基本任务，和架构的关系不是很大，当然，对没有预见到的需求，好的架构要具有适应性和扩展性。

warestar发表于 2019/5/7 16:33:25

图书分类

高可靠系统构建指南：服务稳定性建设与技术债务治理

特色专题

帮助