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

《持续演进的Cloud Native：云原生架构下微服务最佳实践》从架构、研发流程、团队文化三个角度详细介绍了如何构建Cloud Native。作者长期活跃在研发一线，具有丰富的架构设计经验，也曾亲身经历过很多失败的架构设计，如很多团队在实施微服务架构的时候，只强调拆分服务，根本没有理解微服务架构应该怎么做。《持续演进的Cloud Native：云原生架构下微服务*实践》就是想告诉读者，除了拆分服务，还要把哪些事做好，例如基础设施、一致性、性能、研发流程、团队文化等。

《不断演变的Cloud Native：云原生态构架下微服务最好实践》共分成10 章，第1 章从总体上描述了Cloud Native 的渊源、构成及标准等；从第2 章到第7 章重中之重描述了微服务架构、灵巧基础设施建设及公共基础服务项目、易用性、可扩展性、性能、一致性等层面的设计方案实践；第8 章介绍了Serverless 和Service Mesh；第9 章介绍了怎样搭建产品研发步骤；第10 章介绍了怎样基本建设企业文化。

这书希望给技术性管理人员、系统架构师和有一定基本的专业技术人员出示协助，非常是希望更改产品研发方式，从交货型手机软件衔接到云服务器的传统式软件行业开发人员，该书将协助你事半功倍。

目录

• 第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