1.Spring FrameWork 与 Spring Boot 的区别和联系：
其实Spring Boot 内部还是通过Spring Framework 来实现的，Spring Boot 可以说是 Spring 的上层应用，因为 Spring Boot 内部又集成了一些其他组件，例如 Web容器之类。所以使用它开发项目的效率更高。使用注解开发也非常的方便，并且使用注解也是在Spring Boot 中约定俗成的一个规定。
2.Spring Boot 向对于 Spring Framework ,它的真正的优势在哪里呢？
Spring Boot 真正的优势在于它的 自动装配 , 可以看到在SpringBoot的启动类上的 @SpringBootApplication 注解内部有以下这些注解。最为重要的有三个：
（1）@SpringBootConfiguration：实质就是一个@Configuration，代表了一个配置类，相当于配置文件一样
（2）@EnableAutoConfiguration：代表开启Spring Boot 的自动装配机制，在Spring Boot中，看到开头带@EnableXXXXX的注解，表示开启框架中的某一项功能。
（3）@ComponentScan：自动扫描并加载符合条件的组件。
在@EnableAutoConfiguration注解中，最为重要的要属@Import注解，它可以将所有被@Configuration注解标注的，并且符合条件的配置类，都加载到Spring Boot 的IOC容器中。其内部使用到了Spring框架原有的一个工具类SpringFactoriesLoader，通过在指定的文件中加载配置(这里的指定文件代表使用@Configuration注解标注的类)，来达到自动装配的目的。
3.@Component注解是Spring Boot 中的基础组件，它的作用是-->如果在某一个类上标注了@Component注解，那么在Spring Boot 初始化的时候，会将当前类的实例化对象载入到IOC容器中。@Controller，@Service，@Repository注解，内部都运用了@Component。
从上图中可以看到，如果两个类同时实现了同一个接口，那么在使用接口注入时，IDE编译器会报错，因为有多个实现类，它不知道应该注入哪一个实现类。对于这一情况，我们可以在其中一个实现类上标注@Primary注解，这时在自动注入时就不会报错。
总结：其实以上的操作就是一种 "策略模式" 的具体应用，对于Service 而言，Controller层是调用方，就相当于客户端，它只需要以接口的形式来调用就可以了，并不需要关心具体使用的是哪一个实现类。所以使用策略模式可以做到-->调用方与实现类独立，可以达到实现类之间相互替换的作用。
4.@Configuration注解它的本质就相当于一个在Spring框架中的beans.xml，它通常与@Bean注解组合使用，那么如果当前方法上标注了@Bean注解，那么当前方法需要返回一个对象
@Configuration注解的真正用途：
问题：既然有了@Component注解，那么为什么还需要@Configuration注解呢？
答案：因为我们在编程时需要遵守OCP原则，在Spring，Spring Boot 中，他们使用配置文件的方式来达到OPC的目的，即：如果我们想要修改业务，那么尽可能的在配置文件中修改，然后通过动态读取配置文件的形式来达到修改业务的目的。使用@Component注解是无法满足这一需要的，所以我们需要使用@Configuration + @Bean 注解，同时通过@Value注解来动态的从配置文件中，向当前类的属性注入数据。使用配置类的形式可以让程序变得更加灵活。
Spring Boot中的具体应用：
我们在Spring Boot 中的.yml配置文件中写的一些配置，Spring Boot 内部也是通过@Configuration的形式来进行属性的注入，以及对象的实例化。如下图所示：我们配置的kafka相关的信息，那么它内部就会读取在配置文件中，以"spring.kafka"开头的信息，然后将属性一一对应上即可
在它的配置类上也同样标注了@Configuration注解，也同样使用了@Bean注解返回一个实例化对象，但是与我们上面的例子不同的是，它实例化对象的过程比较复杂，用到了工厂模式。但是大体的流程是一致的。
总结：其实向@Configuration这种方式是一种编程模式，使配置与具体的业务代码隔离开，利用这种思想，我们在任何系统中都可以写出遵守OPC原则的代码。
5. java的SPI机制在Spring Boot 中的实践：全称 Service Provider Interface，是为某一个接口寻找服务实现的机制。
它采用了"面向接口编程 + 策略模式 + 配置文件"的形式来实现动态加载，在Spring Boot中有很好的应用。可能在一个大型的项目中，一个模块会有多个不同的业务实现，那么系统的各个模块之间，应该依赖于接口，不应该依赖具体的实现类。根据不同的业务需求来切换到不同的业务实现中去。所以SPI机制的核心还是"解耦"。