王福强 著
很多 SOA 实施成熟度比较好的企业，已经在使用和实施微服务了。只不过，它们只是在闷声发大财，并不介意是否有一个比较时髦的名词来明确表述 SOA 的这个发展演化趋势罢了。
微服务其实就是服务化思路的一种最佳实践方向，遵循 SOA 的思路，各个企业在服务化治理的道路上走的时间长了。踩的坑多了，整个软件交付链路上各个环节的基础设施逐渐成熟了，微服务自然而然就延生了。
当然，之所以叫微服务，是与之前的服务化思路和实践相比较而来的。早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元（一般称为 Monolith），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。
“大一统”的服务化实践并非不能满足要求，也不是不好，只是它有自己存在的合理场景。对于 Monolith 服务来说，如果团队不大，软件复杂度不高，那么使用 Monolith 的形式进行服务化治理是比较合适的，而且，这种方式对运维和各种基础设施的要求也不高。
但是，随着软件系统的复杂度持续飙升，软件交付的效率要求更高，投入的人力以及各项资源越来越多，基于 Monolith 的服务化思路就开始“捉襟见肘”。
微服务的好处
独立
多语言生态
挑战
通过标准化，可以重复使用开发阶段打造的一系列环境和工具支持。
通过标准化，可以复用整个微服务交付链路的各项基础设施
通过标准化，可以减少采购差异导致的成本上升，同时更加高效地利用硬件资源。
通过标准化，可以用标准的协议和格式来治理和维护数量庞大的微服务。
增加一种语言生态用于微服务的开发和交付，是否有必要重新搭建一套研发/测试环境？
是否还要围绕这种语言打造一系列工具还提升日常开发的效率？
还要围绕搭建一套针对微服务的交付链路基础设施
还要提供这种语言特定的硬件以及运维支撑工具和平台
Spring IoC
IoC ( Inversion Of Control )
DL ( Dependency Lookup ) 依赖查找：当前软件实体主动去某个服务注册地查找其依赖的那些服务
DI ( Dependency Injection )：当前软件实体被动接受其依赖的其他组件被 IoC 容器注入。
context.getBean(...) 实际上就是做的 DL 的工作。
Spring IoC 容器中发生的事是：
阶段一：收集和注册，构建和收集 bean 定义的阶段
队段二：分析和组装，收集后容器中的 bean 是一个个独立的，无关联。实际上他们是有依赖关系的。所以这步做的事是分析 bean 的关系，组装它们。
@SpringBootApplication 是一个复合结构
其中有三块最主要：
@Configuration
就是 JavaConfig 形式下 Spring IoC 容器的配置类使用的那个 @Configuration
@EnableAutoConfiguration
借助 @Import 的支持，收集和注册特定场景相关的 Bean 定义。
@ComponentScan
自动扫描并加载符合条件的组件或 bean 定义，最终将这些 bean 定义加载到容器中。
Spring Boot 的启动过程看起来很长，其实很多都是一些事件通知的扩展点，如果将一些逻辑暂时忽略，就精简成上面几步。
SpringBoot 主要影响很大的二个层面
1，基于 spring 框架的“约定优先于配置（COC）”理念以及最佳实践之路。
2，提供了针对日常企业应用研发各种场景的 spring-boot-starter 自动配置依赖模块。
我们可以将对 SpringBoot 行为可以进行干预的配置方式划分为几类：
1，命令行参数（Command Line Args）
2，系统环境变量（Environment Variables）
3，位于文件系统中的配置文件
4，位于 classpath 中的配置文件
5，固化到代码中的配置项。
web api 规范：
提供显式的强类型封装方式或隐式的自动转换方式的功能实现
提供 api 文档相关功能的配置和设置
提供统一的 web api 访问错误处理逻辑。
微服务监控：
多节点=》集中存储=》分析=》报警=》人工干预
一本好书。讲的很有条理，逻辑清晰。