春节假期过后，为了消除假期综合征，就花了一两天读了这本《SpringBoot 揭秘：快速构建微服务体系》，简单的感悟如下：
- 整本书内容不多，前三章关于 Springboot 的论述 不错，后两章（Scala + SpringBoot）有狗尾续貂之嫌；
- 看得出来作者还是希望表达一些技术理念的，但很多地方没有展开，所以整本书给人一种泛泛而谈的感觉；
- 这本书其实可以浓缩为3~5篇博客。
如果没有接触过 Springboot 和微服务，那么这本书还是值得一读的。
以下为几条读书笔记。
微服务的核心竞争力？
总的来说，微服务实践的核心竞争力就在于，我们是否围绕微服务的整个交付链路打造了一整套的支撑性工具和平台生态体系。
Spring的单例注入
依赖注入的都是同一个
Singleton的对象实例，那这是如何做到的？笔者一开始以为 Spring 框架会通过解析 JavaConfig 的代码结构，然后通过解析器转换加上反射等方式完成这一目的，但实际上 Spring 框架的设计和实现者采用了另一种更通用的方式，这在 Spring 的参考文档中有说明，即通过拦截配置类的方法调用来避免多次初始化同一类型对象的问题，一旦拥有拦截逻辑的子类发现当前方法没有对应的类型实例时才会去请求父类的同一方法来初始化对象实例，否则直接返回之前的对象实例。
使用 DL 代替 DI 实现 注入
如果我们想同时使用
Actor以及Spring IoC，那么，我建议所有 Actor 的定义都像以上 CandleSticker 定义那样，传递ApplicationContext给Actor定义，让其使用DL（Dependency Lookup）的模式来使用容器中提供的各种服务依赖（类似上例代码中的val candleStickRepository=context.getBean（classOf[CandleStickRepository]）），主要原因在于Actor的生命周期是短暂而易变的，而ApplicationContext以及其中的各项依赖服务则不然，如果硬要使用依赖注入的方式（DI-Dependency Injection），难免有点儿“削足适履”之嫌。
IoC其实有两种方式，一种就是DI，而另一种是DL，即 Dependency Lookup（依赖查找），前者是当前软件实体被动接受其依赖的其他组件被IoC容器注入，而后者则是当前软件实体主动去某个服务注册地查找其依赖的那些服务。