Java常用框架面試題

主題	鏈接
Java基礎知識	面試題
Java集合容器	面試題
Java併發編程	面試題
Java底層知識	面試題
Java常用框架	面試題
計算機網絡	面試題
數據庫	面試題
RabbitMQ	面試題
Redis	面試題

Spring

什麼是Spring?

spring 是個Java企業級應用的開源開發框架。Spring主要用來開發Java應用，但是有些擴展是針對構建J2EE平臺的web應用。Spring 框架目標是簡化Java企業級應用開發，並通過POJO爲基礎的編程模型促進良好的編程習慣。

使用Spring框架的好處是什麼?

• 輕量：Spring 是輕量的，基本的版本大約2MB。
• 控制反轉：Spring通過控制反轉實現了鬆散耦合，對象們給出它們的依賴，而不是創建或查找依賴的對象們。
• 面向切面的編程(AOP)：Spring支持面向切面的編程，並且把應用業務邏輯和系統服務分開。
• 容器：Spring 包含並管理應用中對象的生命週期和配置。

解釋Spring支持的幾種bean的作用域

Spring框架支持以下五種bean的作用域：

• singleton : bean在每個Spring ioc 容器中只有一個實例。
• prototype：一個bean的定義可以有多個實例。
• request：每次http請求都會創建一個bean，該作用域僅在基於web的Spring ApplicationContext情形下有效。
• session：在一個HTTP Session中，一個bean定義對應一個實例。該作用域僅在基於web的Spring ApplicationContext情形下有效。
• global-session：在一個全局的HTTP Session中，一個bean定義對應一個實例。該作用域僅在基於web的Spring ApplicationContext情形下有效。

解釋Spring框架中bean的生命週期

1. 實例化Bean：
   對於BeanFactory容器，當客戶向容器請求一個尚未初始化的bean時，或初始化bean的時候需要注入另一個尚未初始化的依賴時，容器就會調用createBean進行實例化。對於ApplicationContext容器，當容器啓動結束後，通過獲取BeanDefinition對象中的信息，實例化所有的bean。
2. 設置對象屬性（依賴注入）：
   實例化後的對象被封裝在BeanWrapper對象中，緊接着，Spring根據BeanDefinition中的信息 以及 通過BeanWrapper提供的設置屬性的接口完成依賴注入。
3. 處理Aware接口：
   接着，Spring會檢測該對象是否實現了xxxAware接口，並將相關的xxxAware實例注入給Bean：
   ①如果這個Bean已經實現了BeanNameAware接口，會調用它實現的setBeanName(String beanId)方法，此處傳遞的就是Spring配置文件中Bean的id值；
   ②如果這個Bean已經實現了BeanFactoryAware接口，會調用它實現的setBeanFactory()方法，傳遞的是Spring工廠自身。
   ③如果這個Bean已經實現了ApplicationContextAware接口，會調用setApplicationContext(ApplicationContext)方法，傳入Spring上下文；
4. BeanPostProcessor：
   如果想對Bean進行一些自定義的處理，那麼可以讓Bean實現了BeanPostProcessor接口，那將會調用postProcessBeforeInitialization(Object obj, String s)方法。
5. InitializingBean 與 init-method：
   如果Bean在Spring配置文件中配置了 init-method 屬性，則會自動調用其配置的初始化方法。
6. 如果這個Bean實現了BeanPostProcessor接口，將會調用postProcessAfterInitialization(Object obj, String s)方法；由於這個方法是在Bean初始化結束時調用的，所以可以被應用於內存或緩存技術；
   以上幾個步驟完成後，Bean就已經被正確創建了，之後就可以使用這個Bean了。
7. DisposableBean：當Bean不再需要時，會經過清理階段，如果Bean實現了DisposableBean這個接口，會調用其實現的destroy()方法；
8. destroy-method：

Spring框架中的單例bean是線程安全的嗎？Spring如何處理線程併發問題？

Spring框架並沒有對單例bean進行任何多線程的封裝處理。關於單例bean的線程安全和併發問題需要開發者自行去搞定。但實際上，大部分的Spring bean並沒有可變的狀態(比如Serview類和DAO類)，所以在某種程度上說Spring的單例bean是線程安全的。如果你的bean有多種狀態的話（比如 View Model 對象），就需要自行保證線程安全。最淺顯的解決辦法就是將多態bean的作用域由“singleton”變更爲“prototype”。

在一般情況下，只有無狀態的Bean纔可以在多線程環境下共享，在Spring中，絕大部分Bean都可以聲明爲singleton作用域，因爲Spring對一些Bean中非線程安全狀態採用ThreadLocal進行處理，解決線程安全問題。

什麼是依賴注入？什麼是控制反轉？

本質上IoC和DI是同一思想下不同維度的表現 ,用通俗的話說就是，IoC是bean的註冊，DI是bean的初始化
Ioc—Inversion of Control，即“控制反轉”，不是什麼技術，而是一種設計思想。在Java開發中，Ioc意味着將你設計好的對象交給容器控制，而不是傳統的在你的對象內部直接控制。如何理解好Ioc呢？理解好Ioc的關鍵是要明確“誰控制誰，控制什麼，爲何是反轉（有反轉就應該有正轉了），哪些方面反轉了”，那我們來深入分析一下：
　　●誰控制誰，控制什麼：傳統Java SE程序設計，我們直接在對象內部通過new進行創建對象，是程序主動去創建依賴對象；而IoC是有專門一個容器來創建這些對象，即由Ioc容器來控制對象的創建；誰控制誰？當然是IoC容器控制了對象；控制什麼？那就是主要控制了外部資源獲取（不只是對象包括比如文件等）。
　　●爲何是反轉，哪些方面反轉了：有反轉就有正轉，傳統應用程序是由我們自己在對象中主動控制去直接獲取依賴對象，也就是正轉；而反轉則是由容器來幫忙創建及注入依賴對象；爲何是反轉？因爲由容器幫我們查找及注入依賴對象，對象只是被動的接受依賴對象，所以是反轉；哪些方面反轉了？依賴對象的獲取被反轉了。
IoC很好的體現了面向對象設計法則之一—— 好萊塢法則：“別找我們，我們找你”；即由IoC容器幫對象找相應的依賴對象並注入，而不是由對象主動去找。

DI—Dependency Injection，即“依賴注入”：組件之間依賴關係由容器在運行期決定，形象的說，即由容器動態的將某個依賴關係注入到組件之中。依賴注入的目的並非爲軟件系統帶來更多功能，而是爲了提升組件重用的頻率，併爲系統搭建一個靈活、可擴展的平臺。通過依賴注入機制，我們只需要通過簡單的配置，而無需任何代碼就可指定目標需要的資源，完成自身的業務邏輯，而不需要關心具體的資源來自何處，由誰實現。

什麼是AOP？AOP的實現原理？

AOP是OOP的補充，當我們需要爲多個對象引入一個公共行爲，比如日誌，操作記錄等，就需要在每個對象中引用公共行爲，這樣程序就產生了大量的重複代碼，使用AOP可以完美解決這個問題。

切面：攔截器類，其中會定義切點以及通知
切點：具體攔截的某個業務點。
通知：切面當中的方法，聲明通知方法在目標業務層的執行位置，通知類型如下：
前置通知：@Before 在目標業務方法執行之前執行
後置通知：@After 在目標業務方法執行之後執行
返回通知：@AfterReturning 在目標業務方法返回結果之後執行
異常通知：@AfterThrowing 在目標業務方法拋出異常之後
環繞通知：@Around 功能強大，可代替以上四種通知，還可以控制目標業務方法是否執行以及何時執行

Spring 支持的事務管理類型有哪些？你在項目中使用哪種方式？怎麼理解全局事務和局部事務？

Spring的事務傳播行爲：
Spring事務的傳播行爲說的是，當多個事務同時存在的時候，spring如何處理這些事務的行爲。

• PROPAGATION_REQUIRED：如果當前沒有事務，就創建一個新事務，如果當前存在事務，就加入該事務，該設置是最常用的設置。
• PROPAGATION_SUPPORTS：支持當前事務，如果當前存在事務，就加入該事務，如果當前不存在事務，就以非事務執行。‘
• PROPAGATION_MANDATORY：支持當前事務，如果當前存在事務，就加入該事務，如果當前不存在事務，就拋出異常。
• PROPAGATION_REQUIRES_NEW：創建新事務，無論當前存不存在事務，都創建新事務。
• PROPAGATION_NOT_SUPPORTED：以非事務方式執行操作，如果當前存在事務，就把當前事務掛起。
• PROPAGATION_NEVER：以非事務方式執行，如果當前存在事務，則拋出異常。
• PROPAGATION_NESTED：如果當前存在事務，則在嵌套事務內執行。如果當前沒有事務，則按REQUIRED屬性執行。

Spring中的隔離級別：

• ISOLATION_DEFAULT：這是個 PlatfromTransactionManager默認的隔離級別，使用數據庫默認的事務隔離級別。
• ISOLATION_READ_UNCOMMITTED：讀未提交，允許另外一個事務可以看到這個事務未提交的數據。
• ISOLATION_READ_COMMITTED：讀已提交，保證一個事務修改的數據提交後才能被另一事務讀取，而且能看到該事務對已有記錄的更新。
• ISOLATION_REPEATABLE_READ：可重複讀，保證一個事務修改的數據提交後才能被另一事務讀取，但是不能看到該事務對已有記錄的更新。
• ISOLATION_SERIALIZABLE：一個事務在執行的過程中完全看不到其他事務對數據庫所做的更新。

局部事務是特定於一個單一的事務資源，如一個 JDBC 連接，而全局事務可以跨多個事務資源事務，如在一個分佈式系統中的事務。

Spring中，如果是異步線程，那麼會在同一個事務中嗎？

因爲線程不屬於spring託管，故線程不能夠默認使用spring的事務,也不能獲取spring注入的bean在被spring聲明式事務管理的方法內開啓多線程，多線程內的方法不被事務控制。

Spring中，事務傳播中將事務掛起是怎麼實現的？

例如： 方法A支持事務，方法B不支持事務，即PROPAGATION_NOT_SUPPORTED

1. 方法A調用方法B
2. 在方法A開始運行時，系統爲它建立Transaction，方法A中對於數據庫的處理操作，會在該Transaction的控制之下。
3. 方法A調用方法B，方法A打開的Transaction將掛起，方法B中任何數據庫操作，都不在該Transaction的管理之下。
4. 當方法B返回，方法A繼續運行，之前的Transaction恢復，後面的數據庫操作繼續在該Transaction的控制之下 提交或回滾。

參考鏈接

Spring中，事務傳播特性中的嵌入事務，是怎麼實現？

PROPAGATION_NESTED是默認的傳播級別，也就是有事務就用這個事務，沒有就新建一個。注意這裏有一個叫做 savePoint 保存點的東西：savePoint 有個計數器，保存在 ConnectionHolder 裏面，如果需要創建保存點，就會通過它操作 Connection 去啓用保存點，如果我們報了錯，可以回滾到此保存點，比如這一小段代碼 SAVEPOINT_1，裏面有一個內嵌事務， SAVAPOINT_2，執行這個內嵌出錯，我們可以回滾 SAVAPOINT_2，而 SAVEPOINT_1 不受影響。

Spring 提供的事務管理器都有哪些？他們共同實現的父接口是什麼？

• 在創建 MapperProxy 時，spring 爲其注入了一個 sqlSession 用於 sql執行，但是這個 sqlSession 是一個代理對象，叫做 sqlSessionTemplate，它會自動選擇我們該使用哪個 sqlSession 去執行
• 在執行時，spring 切面在執行事務之前，會創建一個叫做 TransactionInfo 的對象，此對象會根據事務傳播等級來控制是否創建新連接，是否掛起上一個連接，將信息保存在 TransactionSynchronizationManager
• 到了真正需要創建或者獲取 sqlSession 時，spring 重寫的 TransactionFactory 會優先去 TransactionSynchronizationManager 中拿連接對象。

事務管理的框架是由抽象事務管理器 AbstractPlatformTransactionManager 來提供的，而具體的底層事務處理實現，由 PlatformTransactionManager 的具體實現類來實現，如事務管理器 DataSourceTransactionManager。不同的事務管理器管理不同的數據資源 DataSource，比如 DataSourceTransactionManager 管理 JDBC 的 Connection。RabbitTransactionManager管理消息隊列

參考鏈接

Spring 框架中都用到了哪些設計模式？

• 工廠設計模式 : Spring使用工廠模式通過 BeanFactory、ApplicationContext 創建 bean 對象。
• 代理設計模式 : Spring AOP 功能的實現。
• 單例設計模式 : Spring 中的 Bean 默認都是單例的。
• 模板方法模式 : Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 結尾的對數據庫操作的類，它們就使用到了模板模式。
• 包裝器設計模式 : 我們的項目需要連接多個數據庫，而且不同的客戶在每次訪問中根據需要會去訪問不同的數據庫。這種模式讓我們可以根據客戶的需求能夠動態切換不同的數據源。
• 觀察者模式: Spring 事件驅動模型就是觀察者模式很經典的一個應用。
• 適配器模式 :Spring AOP 的增強或通知(Advice)使用到了適配器模式、spring MVC 中也是用到了適配器模式適配Controller。

參考鏈接

Spring 如何設計容器的，BeanFactory和ApplicationContext的關係詳解

Spring 中關於 IOC 的特定實現是什麼？
特定的實現是 BeanFactory 和 ApplicationContext。

它們是以什麼方式來實現的？
其實從它們的類圖就可以發現，它們其實都會通過組合和繼承。如上面所說的，這樣的好處在於提高各個類的職能，使其更加專注於其技能，也便於外部進行擴展。如果 BeanFactory 和 ApplicationContext 都是容器的話，
那麼它們究竟誰纔是底層 IOC 容器？還有它們面對真實的場景是什麼？
BeanFactory 和 ApplicationContext 皆爲 IOC 的實現。但是 BeanFactory 是專注於提供最核心最基礎的 IOC 功能，而 ApplicationContext 是面向企業級別應用而集成更多便於開發的特性的 IOC 實現。它們兩個專注方向不同，非多餘實現，互不影響。

Spring MVC

什麼是MVC？

Spring MVC的主要組件？

1. 前端控制器 DispatcherServlet（不需要程序員開發）作用：接收請求、響應結果，相當於轉發器，有了DispatcherServlet 就減少了其它組件之間的耦合度。
2. 處理器映射器HandlerMapping（不需要程序員開發）作用：根據請求的URL來查找Handler
3. 處理器適配器HandlerAdapter，注意：在編寫Handler的時候要按照HandlerAdapter要求的規則去編寫，這樣適配器HandlerAdapter纔可以正確的去執行Handler。
4. 處理器Handler（需要程序員開發）
5. 視圖解析器 ViewResolver（不需要程序員開發）作用：進行視圖的解析，根據視圖邏輯名解析成真正的視圖（view）
6. 視圖View（需要程序員開發jsp）

Spring mvc 的執行流程

1. 用戶發送請求至前端控制器DispatcherServlet；
2. DispatcherServlet收到請求後，調用HandlerMapping處理器映射器，請求獲取Handle；
3. 處理器映射器根據請求url找到具體的處理器，生成處理器對象及處理器攔截器(如果有則生成)一併返回給DispatcherServlet；
4. DispatcherServlet 調用 HandlerAdapter處理器適配器；
5. HandlerAdapter 經過適配調用 具體處理器(Handler，也叫後端控制器)；
6. Handler執行完成返回ModelAndView；
7. HandlerAdapter將Handler執行結果ModelAndView返回給DispatcherServlet；
8. DispatcherServlet將ModelAndView傳給ViewResolver視圖解析器進行解析；
9. ViewResolver解析後返回具體View；
10. DispatcherServlet對View進行渲染視圖（即將模型數據填充至視圖中）
11. DispatcherServlet響應用戶。

SpringWebFlux和SpringMVC有什麼區別

什麼是WebFlux

是一個異步非阻塞的Web框架,它能夠充分利用多核CPU的硬件資源去處理大量的併發請求
優勢:內部使用的是響應式編程，以Reactor庫爲基礎，基於異步和事件驅動，可以讓我們在不擴充硬件資源的前提下，提升系統的吞吐量和伸縮性。
不能使接口的響應時間縮短，它僅僅能夠提升吞吐量和伸縮性。

應用場景

特別適合在IO密集型的服務中，比如微服務網關。
PS: IO 密集型包括：磁盤IO密集型, 網絡IO密集型，微服務網關就屬於網絡 IO 密集型，使用異步非阻塞式編程模型，能夠顯著地提升網關對下游服務轉發的吞吐量。

選WebFlux還是Spring MVC

WebFlux不是 Spring MVC的替代方案！雖然 WebFlux 也可以被運行在 Servlet 容器上（需是 Servlet 3.1+ 以上的容器），但是 WebFlux 主要還是應用在異步非阻塞編程模型，而 Spring MVC 是同步阻塞的，如果你目前在 Spring MVC 框架中大量使用非同步方案，那麼，WebFlux 纔是你想要的，否則，使用 Spring MVC 纔是你的首選。
在微服務架構中，Spring MVC 和 WebFlux 可以混合使用，比如已經提到的，對於那些 IO 密集型服務(如網關)，我們就可以使用 WebFlux 來實現。

異同點
參考鏈接

MyBatis

Mybatis優缺點，適用場景

一、Mybatis 優點：上手容易、提供xml標籤、支持動態SQL編程，Mapper映射，支持對象與數據庫的ORM字段關係映射

Mybatis 缺點：

SQL語句的編寫工作量較大，尤其是字段多、關聯表多時，更是如此，對開發人員編寫SQL語句的功底有一定要求。
SQL語句依賴於數據庫，導致數據庫移植性差，不能隨意更換數據庫
當希望對象的持久化對應用程序完全透明是，不適合使用Mybatis
當數據庫有移植需求或需要支持多種數據庫時，不適合使用Mybatis
Mybatis 應用場景：適用於表關聯較多的項目，持續維護開發迭代較快的項目，需求變化較多的項目，如互聯網項目

二、Spring Data JPA 應用場景：傳統項目或者關係模型較爲清晰穩定的項目，建議JPA（比如DDD設計中的領域層）

Spring Data JPA：一般會和Hibernate一起使用

三、Hibernate 入門門檻較高，不需要寫SQL，SQL會自動生成

Hibernate 缺點：sql的優化比較困難 Hibernate 應用場景：適用與需求變化不多的中小型項目中，比如後臺管理，erp,orm,oa 四、比較 hibernate是面向對象的，而MyBatis是面向關係的

數據分析型的OLAP應用適合用MyBatis，事務處理型OLTP應用適合用JPA。 越是複雜的業務，越需要領域建模，建模用JPA實現最方便靈活。但是JPA想用好，門檻比較高，不懂DDD的話，就會淪爲增刪改查了。 複雜的查詢應該是通過CQRS模式，通過異步隊列建立合適查詢的視圖，通過視圖避免複雜的Join，而不是直接查詢領域模型。 從目前的趨勢來看OLAP交給NoSQL數據庫可能更合適

Hibernate的DAO層開發比MyBatis簡單，Mybatis需要維護SQL和結果映射。 Hibernate對對象的維護和緩存要比MyBatis好，對增刪改查的對象的維護要方便。 Hibernate數據庫移植性很好，MyBatis的數據庫移植性不好，不同的數據庫需要寫不同SQL。 Hibernate有更好的二級緩存機制，可以使用第三方緩存。MyBatis本身提供的緩存機制不佳

JDBC編程有哪些不足之處，MyBatis是如何解決這些問題的？

1、JDBC：數據庫鏈接創建、釋放頻繁造成系統資源浪費從而影響系統性能，如果使用數據庫鏈接池可解決此問題。

MyBatis：在SqlMapConfig.xml中配置數據鏈接池，使用連接池管理數據庫鏈接。

2、JDBC：Sql語句寫在代碼中造成代碼不易維護，實際應用sql變化的可能較大，sql變動需要改變java代碼。

MyBatis：將Sql語句配置在XXXXmapper.xml文件中與java代碼分離。
3、JDBC：向sql語句傳參數麻煩，因爲sql語句的where條件不一定，可能多也可能少，佔位符需要和參數一一對應。

MyBatis： Mybatis自動將java對象映射至sql語句。
4，JDBC：對結果集解析麻煩，sql變化導致解析代碼變化，且解析前需要遍歷，如果能將數據庫記錄封裝成pojo對象解析比較方便。

MyBatis：Mybatis自動將sql執行結果映射至java對象。

請說說MyBatis的工作原理

1. 讀取 MyBatis 配置文件：mybatis-config.xml 爲 MyBatis 的全局配置文件，配置了 MyBatis的運行環境等信息，例如數據庫連接信息。
2. 加載映射文件。映射文件即 SQL 映射文件，該文件中配置了操作數據庫的 SQL 語句，需要在 MyBatis 配置文件 mybatis-config.xml 中加載。mybatis-config.xml 文件可以加載多個映射文件，每個文件對應數據庫中的一張表。
3. 構造會話工廠：通過 MyBatis 的環境等配置信息構建會話工廠 SqlSessionFactory。
4. 創建會話對象：由會話工廠創建 SqlSession 對象，該對象中包含了執行 SQL 語句的所有方法。
5. Executor 執行器：MyBatis 底層定義了一個 Executor 接口來操作數據庫，它將根據 SqlSession 傳遞的參數動態地生成需要執行的 SQL 語句，同時負責查詢緩存的維護。
6. MappedStatement 對象：在 Executor 接口的執行方法中有一個 MappedStatement 類型的參數，該參數是對映射信息的封裝，用於存儲要映射的 SQL 語句的 id、參數等信息。
7. 輸入參數映射：輸入參數類型可以是 Map、List 等集合類型，也可以是基本數據類型和 POJO 類型。輸入參數映射過程類似於 JDBC 對 preparedStatement 對象設置參數的過程。
8. 輸出結果映射：輸出結果類型可以是 Map、 List 等集合類型，也可以是基本數據類型和 POJO 類型。輸出結果映射過程類似於 JDBC 對結果集的解析過程。

Mybatis中${}與#{} 的區別是什麼？

#{}是預編譯處理，${}是字符串替換。

1. mybatis在處理#{}時，會將sql中的#{}替換爲?號，調用PreparedStatement的set方法來賦值。
2. mybatis在處理${}時，就是把${}替換成變量的值。
3. 使用#{}可以有效的防止SQL注入，提高系統安全性。原因在於：預編譯機制。預編譯完成之後，SQL的結構已經固定，即便用戶輸入非法參數，也不會對SQL的結構產生影響，從而避免了潛在的安全風險。
4. 預編譯是提前對SQL語句進行預編譯，而其後注入的參數將不會再進行SQL編譯。我們知道，SQL注入是發生在編譯的過程中，因爲惡意注入了某些特殊字符，最後被編譯成了惡意的執行操作。而預編譯機制則可以很好的防止SQL注入。

Mybatis是如何進行分頁的？分頁插件的原理是什麼？

Mybatis使用RowBounds對象進行分頁，它是針對ResultSet結果集執行的內存分頁，而非物理分頁，可以在sql內直接書寫帶有物理分頁的參數來完成物理分頁功能，也可以使用分頁插件來完成物理分頁。
分頁插件的基本原理是使用Mybatis提供的插件接口，實現自定義插件，在插件的攔截方法內攔截待執行的sql，然後重寫sql，根據dialect方言，添加對應的物理分頁語句和物理分頁參數。
舉例：select * from student，攔截sql後重寫爲：select t.* from (select * from student) t limit 0, 10

對MyBatis的緩存的理解？簡單的說一下MyBatis的一級緩存和二級緩存？

• 一級緩存: 基於 PerpetualCache 的 HashMap 本地緩存，其存儲作用域爲 Session，當 Session flush 或 close 之後，該 Session 中的所有 Cache 就將清空，默認打開一級緩存。
• 二級緩存與一級緩存其機制相同，默認也是採用 PerpetualCache，HashMap 存儲，不同在於其存儲作用域爲 Mapper(Namespace)，並且可自定義存儲源，如 Ehcache。默認不打開二級緩存，要開啓二級緩存，使用二級緩存屬性類需要實現Serializable序列化接口(可用來保存對象的狀態),可在它的映射文件中配置
• 對於緩存數據更新機制，當某一個作用域(一級緩存 Session/二級緩存Namespaces)的進行了C/U/D 操作後，默認該作用域下所有 select 中的緩存將被 clear。

Spring Boot

Spring Boot 中如何解決跨域問題 ?
跨域可以在前端通過 JSONP 來解決，但是 JSONP 只可以發送 GET 請求，無法發送其他類型的請求，在 RESTful 風格的應用中，就顯得非常雞肋，因此我們推薦在後端通過 （CORS，Cross-origin resource sharing） 來解決跨域問題。這種解決方案並非 Spring Boot 特有的，在傳統的 SSM 框架中，就可以通過 CORS 來解決跨域問題，只不過之前我們是在 XML 文件中配置 CORS ，現在可以通過實現WebMvcConfigurer接口然後重寫addCorsMappings方法解決跨域問題。

Spring Cloud

優缺點，適用場景

優點：

• 產出於Spring大家族，Spring在企業級開發框架中無人能敵，來頭很大，可以保證後續的更新、完善
• 組件豐富，功能齊全。Spring Cloud 爲微服務架構提供了非常完整的支持。例如、配置管理、服務發現、斷路器、微服務網關等；
• Spring Cloud 社區活躍度很高，教程很豐富，遇到問題很容易找到解決方案
• 服務拆分粒度更細，耦合度比較低，有利於資源重複利用，有利於提高開發效率
• 可以更精準的制定優化服務方案，提高系統的可維護性
• 減輕團隊的成本，可以並行開發，不用關注其他人怎麼開發，先關注自己的開發
• 微服務可以是跨平臺的，可以用任何一種語言開發
• 適於互聯網時代，產品迭代週期更短

缺點：

• 微服務過多，治理成本高，不利於維護系統
• 分佈式系統開發的成本高（容錯，分佈式事務等）對團隊挑戰大

主要項目

Spring Cloud Config：集中配置管理工具，分佈式系統中統一的外部配置管理，默認使用Git來存儲配置，可以支持客戶端配置的刷新及加密、解密操作。

Spring Cloud Netflix：

• Netflix OSS 開源組件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心組件。
• Eureka：服務治理組件，包括服務端的註冊中心和客戶端的服務發現機制；
• Ribbon：負載均衡的服務調用組件，具有多種負載均衡調用策略；
• Hystrix：服務容錯組件，實現了斷路器模式，爲依賴服務的出錯和延遲提供了容錯能力；
• Feign：基於Ribbon和Hystrix的聲明式服務調用組件；
• Zuul：API網關組件，對請求提供路由及過濾功能。

Spring Cloud Bus：用於傳播集羣狀態變化的消息總線，使用輕量級消息代理鏈接分佈式系統中的節點，可以用來動態刷新集羣中的服務配置。

Spring Cloud Consul：基於Hashicorp Consul的服務治理組件。

Spring Cloud Security：安全工具包，對Zuul代理中的負載均衡OAuth2客戶端及登錄認證進行支持。

Spring Cloud Sleuth：Spring Cloud應用程序的分佈式請求鏈路跟蹤，支持使用Zipkin、HTrace和基於日誌（例如ELK）的跟蹤。

Spring Cloud Stream：輕量級事件驅動微服務框架，可以使用簡單的聲明式模型來發送及接收消息，主要實現爲Apache Kafka及RabbitMQ。

Spring Cloud Task：用於快速構建短暫、有限數據處理任務的微服務框架，用於嚮應用中添加功能性和非功能性的特性。

Spring Cloud Zookeeper：基於Apache Zookeeper的服務治理組件。

Spring Cloud Gateway：API網關組件，對請求提供路由及過濾功能。

Spring Cloud OpenFeign：基於Ribbon和Hystrix的聲明式服務調用組件，可以動態創建基於Spring MVC註解的接口實現用於服務調用，在Spring Cloud 2.0中已經取代Feign成爲了一等公民。

什麼是 Hystrix？它如何實現容錯？

Hystrix是一個實現了超時機制和斷路模式的工具類庫。
Hystrix是由Netflix開源的一個延遲和容錯庫，用於隔離訪問遠程系統、服務或者第三方庫，防止級聯失敗，從而提升系統的可用性與容錯性。Hystrix主要通過以下幾點實現延遲和容錯。
1 包裹請求：使用HystrixCommand包裹對依賴的調用邏輯，每個命令在獨立線程中執行。這使用了設計模式中的“命令模式”。
2 跳閘機制：當某服務的錯誤率超過一定的閾值時，Hystrix可以自動或手動跳閘，停止請求該服務一段時間。
3 資源隔離：Hystrix爲每個依賴都維護了一個小型的線程池（或者信號量）。如果該線程池已滿，發往該依賴的請求就被立即拒絕，而不是排隊等待，從而加速失敗判定。
4 監控：Hystrix可以近乎實時地監控運行指標和配置的變化，例如成功、失敗、超時、以及被拒絕的請求等。
5 回退機制：當請求失敗、超時、被拒絕，或當斷路器打開時，執行回退邏輯。回退邏輯由開發人員自行提供，例如返回一個缺省值。
6 自我修復：斷路器打開一段時間後，會自動進入“半開”狀態。

什麼是 Netflix Feign？

Feign是從Netflix中分離出來的輕量級項目，能夠在類接口上添加註釋，成爲一個REST API 客戶端。

Feign中對 Hystrix 有依賴關係。Feign只是一個便利的rest框架，簡化調用，最後還是通過ribbon在註冊服務器中找到服務實例，然後對請求進行分配。

什麼是 Spring Cloud Bus？

Spring Cloud Bus 對自己的定位是 Spring Cloud 體系內的消息總線，使用 message broker 來連接分佈式系統的所有節點。

什麼是Spring Cloud Gateway?

Spring Cloud Gateway 是 Spring Cloud 的一個全新項目，該項目是基於 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術開發的網關，它旨在爲微服務架構提供一種簡單有效的統一的 API 路由管理方式。

Spring Cloud Gateway 作爲 Spring Cloud 生態系統中的網關，目標是替代 Netflix Zuul，其不僅提供統一的路由方式，並且基於 Filter 鏈的方式提供了網關基本的功能，例如：安全，監控/指標，和限流。

相關概念:

Route（路由）：這是網關的基本構建塊。它由一個 ID，一個目標 URI，一組斷言和一組過濾器定義。如果斷言爲真，則路由匹配。
Predicate（斷言）：這是一個 Java 8 的 Predicate。輸入類型是一個 ServerWebExchange。我們可以使用它來匹配來自 HTTP 請求的任何內容，例如 headers 或參數。
Filter（過濾器）：這是org.springframework.cloud.gateway.filter.GatewayFilter的實例，我們可以使用它修改請求和響應。

什麼是Spring Cloud Config?

spring cloud config是spring cloud團隊創建的一個全新項目，用來爲分佈式系統中的基礎設施和微服務應用提供集中化的外部配置支持，它分爲服務端和客戶端兩部分，其中服務端也稱爲分佈式配置中心，它是一個獨立的微服務應用，用來連接配置倉庫併爲客戶端提供獲取配置信息，加密/解密信息等訪問接口，而客戶端則是微服務架構中的各個微服務應用或基礎設施，它們通過指定的配置中心管理應用資源與業務相關的配置內容，並在啓動的時候從配置中心獲取和加載配置信息。