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機制的核心還是"解耦"。