SpringBoot+SpringCloud面試題整理：

什麼是SpringBoot？
1、用來簡化spring初始搭建和開發過程使用特定的方式進行配置(properties或者yml文件)
2、創建獨立的spring引用程序main方法運行
3、嵌入Tomcat無需部署war包，直接打成jar包nohup java -jar – & 啓動就好
4、簡化了maven的配置
4、自動配置spring添加對應的starter自動化配置
SpringBoot常用的starter：
1、spring-boot-starter-web(嵌入Tomcat和web開發需要的servlet和jsp支持)
2、spring-boot-starter-data-jpa(數據庫支持)
3、spring-boot-starter-data-Redis(Redis支持)
4、spring-boot-starter-data-solr(solr搜索應用框架支持)
5、mybatis-spring-boot-starter(第三方mybatis集成starter)
SpringBoot自動配置原理：
1、@EnableAutoConfiguration這個註解會"猜"你將如何配置spring，前提是你已經添加了jar依賴項，如果spring-boot-starter-web已經添加Tomcat和SpringMVC，這個註釋就會自動假設您在開發一個web應用程序並添加相應的spring配置，會自動去maven中讀取每個starter中的spring.factories文件，該文件裏配置了所有需要被創建spring容器中bean
2、在main方法中加上@SpringBootApplication和@EnableAutoConfiguration
SpringBoot starter工作原理：
1、SpringBoot在啓動時掃描項目依賴的jar包，尋找包含spring.factories文件的jar
2、根據spring.factories配置加載AutoConfigure
3、根據@Conditional註解的條件，進行自動配置並將bean注入到Spring Context
SpringBoot的優點：
1、減少開發、測試時間和努力
2、使用JavaConfig有助於避免使用XML
3、避免大量的maven導入和各種版本衝突
4、提供意見發展方法
5、通過提供默認值快速開始開發
6、沒有單獨的web服務器需要，這就意味着不再需要啓動Tomcat、Glassfish或其他任何東西
7、需要更少的配置，因爲沒有web.xml文件。只需添加用@Configuration註釋的類，然後添加用@Bean註釋的方法，Spring將自動加載對象並像以前一樣對其進行管理。甚至可以將@Autowired添加到bean方法中，以使用Spring自動裝入需要的依賴關係中
Springcloud解決那些問題：
配置管理、（註冊中心eureka、zk）、服務發現、服務註冊、斷路器、路由策略、全局鎖、分佈式會話、客戶端調用、接口網關（zuul）、服務管理系統
SpringBoot與Springcloud：
1>、SpringBoot簡化了xml配置，快速整合框架
2>、Springcloud是一套微服務解決方案—RPC遠程調用
3>、關係Springcloud依賴與SpringBoot（web組件用的SpringMVC），爲什麼Springcloud會依賴與SpringBoot？因爲Springcloud寫接口就是SpringMVC接口
4>、SpringBootproperties和yml中可以使用${random}設置一些隨機值
服務的調用：
rest、feign（均使用httpclient技術），負載均衡ribbon
服務調用的原理：
服務首先註冊到註冊中心eureka中(註冊一個名字通過名字調用)
負載均衡
ribbon，先去註冊中心取到對應的服務，然後交給我ribbon
配置詳解：
1>、eureka.client.register-with-eureka：是否向註冊中心註冊自己，註冊爲true反之爲false
2>、eureka.client.fetch-registry： 是否需要去檢索服務，檢索爲true反之爲false
3>、eureka.client.serviceUrl.defaultZone : 指定服務註冊中心的地址
Eureka：
1>、eureka可分爲三個角色：服務發現者、服務註冊者、註冊發現中心，但是這三個角色並不和實際部署的模型是一對一的關係
2>、所有的網絡通信都是基於http(s)協議的
3>、Eureka和AWS是緊密結合的，無論是配置還是源碼，比如Region、zone…，Region可以通過配置文件進行配置，如果不配置默認使用us-east-1。同樣Zone也可以配置，若不配置默認使用defaultZone
高可用配置：
Eureka server 的高可用實際上就是將自己作爲服務向其他服務註冊中心註冊自己，這樣就可以形成一組互相註冊的服務註冊中心，以實現服務清單的互相同步，達到高可用效果。
微服務：
以前所有的代碼都放在同一個工程中、部署在同一個服務器、同一項目的不同模塊不同功能互相搶佔資源，微服務就是將工程根據不同的業務規則拆分成微服務，部署在不同的服務器上，服務之間相互調用，java中有的微服務有dubbo(只能用來做微服務)、springcloud( 提供了服務的發現、斷路器等)。
微服務的特點：
按業務劃分爲一個獨立運行的程序，即服務單元
服務之間通過HTTP協議相互通信
自動化部署
可以用不同的編程語言
可以用不同的存儲技術
服務集中化管理
微服務是一個分佈式系統
微服務的優勢：
1、將一個複雜的業務拆分爲若干小的業務，將複雜的業務簡單化，新人只需要瞭解他所接管的服務的代碼，減少了新人的學習成本。
2、由於微服務是分佈式服務，服務於服務之間沒有任何耦合。微服務系統的微服務單元具有很強的橫向拓展能力。
3、服務於服務之間採用HTTP網絡通信協議來通信，單個服務內部高度耦合，服務與服務之間完全獨立，無耦合。這使得微服務可以採用任何的開發語言和技術來實現，提高開發效率、降低開發成本。
4、微服務是按照業務進行拆分的，並有堅實的服務邊界，若要重寫某一業務代碼，不需瞭解所以業務，重寫簡單。
5、微服務的每個服務單元是獨立部署的，即獨立運行在某個進程中，微服務的修改和部署對其他服務沒有影響。
6、微服務在CAP理論中採用的AP架構，具有高可用分區容錯特點。高可用主要體現在系統7x24不間斷服務，他要求系統有大量的服務器集羣，從而提高系統的負載能力。分區容錯也使得系統更加健壯。
微服務的不足：
1、微服務的複雜度：構建一個微服務比較複雜，服務與服務之間通過HTTP協議或其他消息傳遞機制通信，開發者要選出最佳的通信機制，並解決網絡服務差時帶來的風險。
2、分佈式事物：將事物分成多階段提交，如果一階段某一節點失敗仍會導致數據不正確。如果事物涉及的節點很多，某一節點的網絡出現異常會導致整個事務處於阻塞狀態，大大降低數據庫的性能。
3、服務劃分：將一個完整的系統拆分成很多個服務，是一件非常困難的事，因爲這涉及了具體的業務場景
4、服務部署：最佳部署容器Docker
微服務和SOA的關係：
微服務相對於和ESB聯繫在一起的SOA輕便敏捷的多，微服務將複雜的業務組件化，也是一種面向服務思想的體現。對於微服務來說，它是SOA的一種體現，但是它比ESB實現的SOA更加輕便、敏捷和簡單。
springcloud如何實現服務註冊與發現？
服務發佈時指定對應的服務名(IP地址和端口號)，將服務註冊到註冊中心(eureka和zookeeper)，但是這一切是Springcloud自動實現的，只需要在SpringBoot的啓動類上加上@EnableDisscoveryClient註解，同一服務修改端口就可以啓動多個實例調用方法：傳遞服務名稱通過註冊中心獲取所有的可用實例，通過負載均衡策略(Ribbon和Feign)調用對應的服務
Ribbon和Feign的區別：
Ribbon添加的maven依賴是spring-starter-ribbon，使用@RibbonClient(value=“服務名稱”)使用RestTemplate調用遠程服務對應的方法，
Feign添加的maven依賴是spring-starter-feign，服務提供方提供對外接口，調用方使用，在接口上使用FeignClient(“指定服務名”)，
具體區別：
1、啓動類使用的註解不同，Ribbon使用的是@RibbonClient，Feign使用的是@EnableFeignClients
2、服務的指定位置不同，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明
3、調用方式不同，Ribbon需要自己構建http請求，模擬http請求然後使用RestTemplate發送給其他服務，步驟比較繁瑣。Feign則是在Ribbon的基礎上進行了一次改進，採用接口調用的方式，將需要調用的其他服務的方法定義成抽象方法即可，不需要自己構建http請求，不過要注意的是抽象方法的註解、方法簽名要和提供方的完全一致。
雪崩效應：
分佈式系統中的服務通信依賴於網絡，網絡不好，必然會對分佈式系統帶來很大的影響。在分佈式系統中，服務之間相互依賴，如果一個服務之間出現了故障或者網絡延遲，在高併發的情況下，會導致線程阻塞，在很短的時間內該服務的線程資源會消耗殆盡，最終使得該服務不可用。由於服務的相互依賴，可能會導致整個系統的不可用，這就是“雪崩效應”。爲了防止此類事件的發生，分佈式系統必然要採取相應的措施，如熔斷機制（Springcloud採用的是Hystrix）
熔斷機制：
1、當一個服務出現故障時，請求失敗次數超過設定的閥值（默認50）之後，該服務就會開啓熔斷器，之後該服務就不進行任何業務邏輯操作，執行快速失敗，直接返回請求失敗的信息。其他依賴於該服務的服務就不會因爲得不到響應而造成線程阻塞，這是除了該服務和依賴於該服務的部分功能不可用外，其他功能正常。
2、熔斷器還有一個自我修復機制，當一個服務熔斷後，經過一段時間（5s）半打開熔斷器。半打開的熔斷器會檢查一部分請求（只能有一個請求）是否正常，其他請求執行快速失敗，檢查的請求如果響應成功，則可判斷該服務正常了，就可關閉該服務的熔斷器，反之則繼續打開熔斷器。這種自我熔斷機制和自我修復機制可以使程序更加健壯、也可以爲開發和運維減少很多不必要的工作。
3、熔斷組件往往會提供一系列的監控，如：服務可用與否、熔斷器是否被打開、目前的吞吐量、網絡延遲狀態的監控等，從而可以讓開發人員和運維人員的瞭解服務的狀況。
Eureka基礎架構：
1>、服務註冊中心：Eureka提供的服務端，提供服務註冊與發現的功能
1>>、失效剔除：對於那些非正常下線的服務實例（內存溢出、網絡故障導致的），服務註冊中心不能收到“服務下線”的請求，爲了將這些無法提供服務的實例從服務列表中剔除，Eureka Server在啓動的時候會創建一個定時任務，默認每隔一段時間（默認60s）將當前清單中超時（默認90s）沒有續約的服務剔除出去。
2>>、自我保護：Eureka Server 在運行期間，會統計心跳失敗的比例在15分鐘之內是否低於85%，如果出現低於的情況（生產環境由於網絡不穩定會導致），Eureka Server會降當前的實例註冊信息保護起來，讓這些實例不過期，儘可能保護這些註冊信息，但是在這保護期間內實例出現問題，那麼客戶端就很容易拿到實際上已經不存在的服務實例，會出現調用失敗的情況，所以客戶端必須有容錯機制，比如可以使用請求重試、斷路器等機制。
在本地進行開發時可以使用 eureka.server.enable-self-preseervation=false參數來關閉保護機制，以確保註冊中心可以將不可用的實例剔除。
2>、服務提供者：提供服務的應用，可以是SpringBoot應用也可以是其他的技術平臺且遵循Eureka通信機制的應用。他將自己提供的服務註冊到Eureka，以供其他應用發現，（如：service層）
1>>、服務註冊：服務提供者在啓動的時候會通過發送Rest請求的方式將自己註冊到Eureka Server（服務註冊中心）中，同時帶上自身服務的一些元數據，Eureka Server 接收到這個Rest請求後，將元數據存儲在一個雙層結構Map中，第一層的key是服務名，第二層key是具體服務的實例名
2>>、服務同步：若有兩個或兩個以上的Eureka Server（服務註冊中心）時，他們之間是互相註冊的，當服務提供者發送註冊請求到一個服務註冊中心時，它會將該請求轉發到集羣中相連的其他註冊中心，從而實現註冊中心間的服務同步，這樣服務提供者的服務信息可以通過任意一臺服務中心獲取到
3>>、服務續約：在註冊完服務之後，服務提供者會維護一個心跳來持續告訴Eureka Server：“我還活着”，以防止Eureka Server的“剔除任務”將該服務實例從服務列表中排除出去。配置：eureka.instance.lease-renewal-in-seconds=30(續約任務的調用間隔時間，默認30秒，也就是每隔30秒向服務端發送一次心跳，證明自己依然存活)，eureka.instance.lease-expiration-duration-in-seconds=90(服務失效時間，默認90秒，也就是告訴服務端，如果90秒之內沒有給你發送心跳就證明我“死”了，將我剔除)
3>、服務消費者：消費者應用從服務註冊中心獲取服務列表，從而使消費者可以知道去何處調用其所需要的服務，如：Ribbon實現消費方式、Feign實現消費方式
1>>、獲取服務：當啓動服務消費者的時候，它會發送一個Rest請求給註冊中心，獲取上面註冊的服務清單，Eureka Server會維護一份只讀的服務清單來返回給客戶端，並且每三十秒更新一次
2>>、服務調用：在服務消費者獲取到服務清單後，通過服務名可以獲得具體提供服務的實例名和該實例的元信息，採用Ribbon實現負載均衡
3>>、服務下線：當服務實例進行正常的關閉操作時，它會觸發一個服務下線的Rest請求給Eureka Server，告訴服務註冊中心“我要下線了”。服務端接收到請求之後，將該服務狀態設置爲下線，並把下線時間傳播出去。
Eureka和zookeeper都可以提供服務註冊與發現的功能，兩者的區別：
Zookeeper保證了CP(C：一致性，P：分區容錯性)，Eureka保證了AP(A：高可用，P：分區容錯)
1、Zookeeper-----當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用的。也就是說服務註冊功能對高可用性要求比較高，但是zk會出現這樣的一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘的節點會重新選leader。問題在於，選取leader的時間過長(30~120s)，且選取期間zk集羣都不可用，這樣就會導致選取期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務最終恢復，但是漫長的選擇時間導致的註冊長期不可用是不能容忍的
2、Eureka則看明白這一點，因此再設計的優先保證了高可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響到正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端再向某個Eureka註冊時如果發現連接失敗，則會自動切換至其他節點，只要有一臺Eureka還在，就能保證註冊服務的可用(保證可用性)，只不過查到的信息可能不是最新的(不保證一致性)。除此之外Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時就會出現以下幾種情況：
1>、Eureka不再從註冊列表移除因爲長時間沒收到心跳而應該過期的服務
2>、Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(保證當前節點可用)
3>、當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中
Eureka還有客戶端緩存功能(Eureka分爲客戶端程序和服務器端程序兩個部分，客戶端程序負責向外提供註冊與發現服務接口)。所以即便Eureka集羣中所有節點都失效，或者發生網絡分隔故障導致客戶端不能訪問任何一臺Eureka服務器；Eureka服務的消費者任然可以通過Eureka客戶端緩存來獲取所有的服務註冊信息。甚至最極端的環境下，所有正常的Eureka節點都不對請求產生響應也沒有更好的服務器解決方案來解決這種問題時；得益於Eureka的客戶端緩存技術，消費者服務仍然可以通過Eureka客戶端查詢與獲取註冊服務信息，這點很重要，因此Eureka可以很好的應對網絡故障導致部分節點失去聯繫的情況，而不像Zookeeper那樣使整個註冊服務癱瘓。
CAP理論：
1、Consistency：指數據的強一致性。如果寫入某個數據成功，之後讀取，讀到的都是新寫入的數據；如果寫入失敗，讀到的都不是寫入失敗的數據。
2、Availability：指服務的可用性
3、Partition-tolerance：指分區容錯
Ribbon和Nginx的區別：
Nginx性能好，但Ribbon可以剔除不健康節點，Nginx剔除比較麻煩，Ribbon是客戶端負載均衡，Nginx是服務端負載均衡
服務註冊與發現：
服務註冊就是向服務註冊中心註冊一個服務實例，服務提供者將自己的服務信息（服務名、IP地址等）告知註冊中心。服務發現是服務消費另一個服務時，註冊中心將服務的實例返回給服務消費者，一個服務既是服務提供者又是服務消費者。
服務註冊中心健康檢查機制，當一個服務實例註冊成功以後，會定時向註冊中心發送一個心跳證明自己可用，若停止發送心跳證明服務不可用將會別剔除。若過段時間繼續想註冊中心提供心跳，將會重新加入服務註冊中心列表中。
服務的負載均衡：
爲什麼要用：微服務是將業務代碼拆分爲很多小的服務單元，服務之間的相互調用通過HTTP協議來調用，爲了保證服務的高可用，服務單元往往都是集羣化部署的，那麼消費者該調用那個服務提供者的實例呢？
介紹：服務消費者集成負載均衡組件，該組件會向服務消費者獲取服務註冊列表信息，並隔一段時間重新刷新獲取列表。當服務消費者消費服務時，負載均衡組件獲取服務提供者所有實例的註冊信息，並通過一定的負載均衡策略（可以自己配置）選擇一個服務提供者實例，向該實例進行服務消費，這樣就實現了負載均衡。