这本书是2017年的，有些旧，毕竟springcloud更新速度还是挺快的，不过基础的东西变化不太大。
读后感：这本书语言风趣，用来入门还是可以的。这本书的侧重点不在于技术，而是在于工作经验，难得的好书。
这本书一共11章，216页，算是很精简了，介绍肯定不全面，也不会太深入，但是对于想快速了解springcloud的人，比如我，就很适合。
第一部分 微服务解惑篇
第一章、微服务架构
第二章、为何选择微服务
第三章、拆分
第四章、如何使用微服务
第五章、微服务的朋友圈
第二部分 技术实现篇
第六章 Spring Boot
第七章 Spring Cloud
第八章 其他相关技术和工具
第九章 测试相关
第三部分 项目实战篇
第十章 三个典型系统案例
第11章 开发管理‘
第一章：微服务架构
微服务的特点：组件化（面向单一的服务、业务功能集中、小组件五脏俱全，对内高内聚，对外低耦合）、独立自治（团度独立、技术选型灵活、数据库分离、独立部署、容错）、灵活易扩展、流程化（拆分成流水线）
缺点：
1、各个开发团队之间，沟通困难
2、时效性不好
3、一致性不好
4、开发重复的功能
5、架构和维护更复杂，需要投入更多精力
难点：
1、落地：包括PAAS、Docker等环境准备，这个直接用阿里云即可，可忽略
2、规划：梳理业务，进行微服务划分，这部分比较重要，但是也不算艰难，有个熟悉业务的人就好
3、开发、测试、运维，包括如下：
接口规范、契约一致性、服务编排、容错、运营管理
第二章、如何选择微服务
第三章、如何拆分
先了解拆分等原则、粒度和边界问题，然后分析业务，自然而然就知道哪里该拆，拆成什么样。
根据1：数据模型和业务模型
根据2：金字塔结构图
关键指标：
1、拆分公共服务
2、拆分重点业务
3、对系统影响大大业务功能
粒度不是越细越好，一个微服务是同一种业务能力，是一系列功能的组合，而不是小到一个功能。
已解决实际问题为出发点避免为拆而拆，拆的时候要考虑拆的意义，以及拆完之后维护的难度。
边界一定要清晰，分工一定要明确：一个微服务只负责自己的一块业务
如果不清楚，那么步子小一点，拆分的少一点，慢慢拆。
第四章、如何使用微服务
如何规划：全局性，针对性，良性发展（技术架构促进业务的发展），格局大
第五章、微服务的朋友圈
1、容器解决了微服务的部署问题
2、DevOps，我一直在考虑一个开发到底需不需要学习运维领域的k8s，原来这种人还是需要的
3、全栈式开发
第六章、Spring boot
第七章、Spring cloud（这一章是重点）
注册中心Eureka：
网关Zuul：提供一个统一的服务出口，同时负责鉴权、认证、安全、跳转等作用
正向代理代理的是客户端，反向代理代理的是服务端；
正向代理，服务端不知道客户端是谁
反向代理，客户端不知道服务端是谁
如何区分？就看这个代理是客户的（比如VPN）还是服务商的（比如nginx）。
客户端负载均衡 Ribbon：主要功能是提供客户端的软件负载均衡算法，将各服务连接起来，有连接超时、重试等功能
断路器Hystrix：失败则调用fallback接口
分布式配置中心 Spring Cloud Config：
本地存储配置的方式通过设置属性spring.profiles.active=native 来实现。
资源文件的命名按照如下规范进行。
I {application} / {profile}[/ {label}]
I {application}-{profile} .yml
I {label} / {application }-{profile} .yml
I {application }-{profile} .properties
I {label}/ {application }-{profile} .properties
label 是可选的，如trunk 、branch 等。
服务之间调用 Feign：
Feign 内部集成了Ribbon ，所以它自带负载均衡功能。
FeignClient 里面己经包含了Hystrix ， 所以不需要增加Hystrix 的依赖，也不需要开启＠EnableCircuitBreaker。
服务追踪 Sleuth：一个请求是一个traceID，每经过一个服务是一个spanID
日志聚合Zipkin:需要配合Sleuth使用
第八章、其他相关技术和工具
Liquibase 是一个用于跟踪、管理和应用数据库变化的开源的数据库重构工具。它将所有数据库的变化（包括结构和数据）都保存在XML 、JSON 等格式的文件中，便于版本控制。
Swagger 的好处在于接口可视化，在线文档和API 始终同步，以及可以对接口进行测试。
权限 Spring Security：
微服务架构的通信方式：Kafka，rabbitMQ
服务编排：这个还是用k8s吧。
第九章、单元测试
Junit
Mock：框架mockito
Mock 与lnjectMocks 的区别：
代码质量管理工具：Sonar
第三部分、项目实战篇
第十章、三个典型系统案例
1、梳理业务，画金字塔图和业务泳道图
2、拆取公共服务（包括基础服务、规则服务、验证服务、计算服务等）
3、拆分业务主体，如果业务影响大，可以采用分批逃跑法
4、其他：收取前端和数据库的判断逻辑，更新插件（比如消息中间件），更改接口调用方式等
第11章、开发管理
管理原则：
1、小团队易于管理，沟通成本低，交付质量容易控制
2、尽量不要使用虚拟团队、远程协作
3、部署服务时应该分批上，不要一次性上太多，容易定位问题
每日站会：
1、昨天工作进展
2、遇到的问题
3、今天准备做什么
代码质量：
1、不断优化，持续改进，减少重复代码和难以理解的代码
2、尽可能正规的单元测试
3、不确定的需求要确认，不确定的方案要请他人审核
工作方式：
1、别急着动手，先明确要做什么，为什么做，怎么做
2、别急着动手，业务需求细节要理解准确，否则请确认该需求的细节，不重要又难以实现的细节是否可以砍掉或换个方式
3、别急着动手，方案设计要适当，不确定时要请他人（业务大牛和技术大牛）审核
4、别急着提交，单元测试和自测要全面
开发人员的工作原则：
1、先找轮子，找不到就开发可复用的轮子
2、边开发边清理边优化边写单元测试
3、尽可能增加代码而不是修改现有代码
4、业务功能一般照着做，有个参照物，不容易出错
5、不仅要知道如何做，还要知道为什么做
6、经常对开发内容进行讨论，避免理解不一致的情况
BA（Business Analyst）的职责：
需求要明确，让每个人知道要做什么和为什么做。
SA（System Analyst）的职责：
选择技术、框架、标准化工具，管理代码质量，提供工具类。