什么是springboot1.用來簡化spring應用的初始搭建以及開發過程 使用特定的方式來進行配置（properties或yml文件）2.創建獨立的spring引用程序 main方法運行3.創建獨立的spring引用程序 main方法運行4.簡化maven配置5.自動配置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集成starterspringboot自動配置的原理 1.在spring程序main方法中 添加@SpringBootApplication或者@EnableAutoConfiguration 2.會自動去maven中讀取每個starter中的spring.factories文件 該文件里配置了所有需要被創建spring容器 中的beanspringboot讀取配置文件的方式springboot默認讀取配置文件為application.properties或者是application.ymlspringboot集成mybatis的過程 添加mybatis的starter maven依賴<dependency><groupId>org.mybatis.spring.boot</groupId><artifactId>mybatis-spring-boot-starter</artifactId><version>1.2.0</version></dependency>在mybatis的接口中 添加@Mapper注解在application.yml配置數據源信息springboot如何添加【修改代碼】自動重啟功能<dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-devtools</artifactId><optional>true</optional></dependency> </dependencies>什么是微服務以前的模式是 所有的代碼在同一個工程中 部署在同一個服務器中 同一個項目的不同模塊不同功能互相 搶占資源微服務 將工程根據不同的業務規則拆分成微服務 微服務部署在不同的機器上 服務之間進行相互調用Java微服務的框架有 dubbo（只能用來做微服務），spring cloud（提供了服務的發現，斷路器等）springcloud如何實現服務的注冊和發現1.服務在發布時 指定對應的服務名（服務名包括了IP地址和端口） 將服務注冊到注冊中心（eureka 或者zookeeper）2. 這一過程是springcloud自動實現 只需要在main方法添加@EnableDisscoveryClient 同一個服務 修改端口就可以啟動多個實例3. 調用方法：傳遞服務名稱通過注冊中心獲取所有的可用實例 通過負載均衡策略調用（ribbon和feign） 對應的服務ribbon和feign區別1.Ribbon添加maven依賴 spring-starter-ribbon 使用@RibbonClient(value="服務名稱") 使用RestTemplate調用遠程服務對應的方法2.feign添加maven依賴 spring-starter-feign 服務提供方提供對外接口 調用方使用 在接口上 使用@FeignClient("指定服務名")Ribbon和Feign的區別： Ribbon和Feign都是用于調用其他服務的，不過方式不同。1.啟動類使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。2.服務的指定位置不同，Ribbon是在@RibbonClient注解上聲明，Feign則是在定義抽象方法的接口中 使用@FeignClient聲明。3.調用方式不同，Ribbon需要自己構建http請求，模擬http請求然后使用RestTemplate發送給其他 服務，步驟相當繁瑣。Feign則是在Ribbon的基礎上進行了一次改進，采用接口的方式，將需要調用的 其他服務的方法定義成抽象方法即可，不需要自己構建http請求。不過要注意的是抽象方法的注解、 方法簽名要和提供服務的方法完全一致。springcloud斷路器的作用當一個服務調用另一個服務由于網絡原因或者自身原因出現問題時 調用者就會等待被調用者的響應當更多 的服務請求到這些資源時導致更多的請求等待 這樣就會發生連鎖效應（雪崩效應） 斷路器就是解決這一問題

Spring Cloud底層原理

概述毫無疑問，Spring Cloud是目前微服務架構領域的翹楚，無數的書籍博客都在講解這個技術。不過大多數講解 還停留在對Spring Cloud功能使用的層面，其底層的很多原理，很多人可能并不知曉。實際上，Spring Cloud是一個全家桶式的技術棧，包含了很多組件。也就是Eureka、Ribbon、 Feign、Hystrix、Zuul這幾個組件。一、業務場景介紹假設咱們現在開發一個電商網站，要實現支付訂單的功能，流程如下：1.創建一個訂單之后，如果用戶立刻支付了這個訂單，我們需要將訂單狀態更新為“已支付” 2.扣減相應的商品庫存 3.通知倉儲中心，進行發貨 4.給用戶的這次購物增加相應的積分針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大體思路如下： 1.用戶針對一個訂單完成支付之后，就會去找訂單服務，更新訂單狀態 2.訂單服務調用庫存服務，完成相應功能 3.訂單服務調用倉儲服務，完成相應功能 4.訂單服務調用積分服務，完成相應功能至此，整個支付訂單的業務流程結束下圖這張圖，清晰表明了各服務間的調用過程：

有了業務場景之后，咱們就一起來看看Spring Cloud微服務架構中，這幾個組件如何相互協作，各自發揮的 作用以及其背后的原理。二、Spring Cloud核心組件：Eureka訂單服務想要調用庫存服務、倉儲服務，或者是積分服務，怎么調用？1.訂單服務壓根兒就不知道人家庫存服務在哪臺機器上啊！他就算想要發起一個請求，都不知道發送給誰， 有心無力！2.這時候，就輪到Spring Cloud Eureka出場了。Eureka是微服務架構中的注冊中心，專門負責服務的注冊 與發現。

庫存服務、倉儲服務、積分服務中都有一個Eureka Client組件，這個組件專門負責將這個服務的信息注冊 到Eureka Server中。說白了，就是告訴Eureka Server，自己在哪臺機器上，監聽著哪個端口。而 Eureka Server是一個注冊中心，里面有一個注冊表，保存了各服務所在的機器和端口號訂單服務里也有一個Eureka Client組件，這個Eureka Client組件會找Eureka Server問一下：庫存服務在 哪臺機器啊？監聽著哪個端口啊？倉儲服務呢？積分服務呢？然后就可以把這些相關信息從Eureka Server的 注冊表中拉取到自己本地緩存起來。這時如果訂單服務想要調用庫存服務，不就可以找自己本地的Eureka Client問一下庫存服務在哪臺機器？ 監聽哪個端口嗎？收到響應后，緊接著就可以發送一個請求過去，調用庫存服務扣減庫存的那個接口！同理， 如果訂單服務要調用倉儲服務、積分服務，也是如法炮制。總結一下： 1.Eureka Client：負責將這個服務的信息注冊到Eureka Server中 2.Eureka Server：注冊中心，里面有一個注冊表，保存了各個服務所在的機器和端口號三、Spring Cloud核心組件：Feign現在訂單服務確實知道庫存服務、積分服務、倉庫服務在哪里了，同時也監聽著哪些端口號了。但是新問題又 來了：難道訂單服務要自己寫一大堆代碼，跟其他服務建立網絡連接，然后構造一個復雜的請求，接著發送請求 過去，最后對返回的響應結果再寫一大堆代碼來處理嗎？

看完上面的代碼什么感覺？是不是感覺整個世界都干凈了，又找到了活下去的勇氣！沒有底層的建立連接、 構造請求、解析響應的代碼，直接就是用注解定義一個 FeignClient接口，然后調用那個接口就可以了。 人家Feign Client會在底層根據你的注解，跟你指定的服務建立連接、構造請求、發起靕求、獲取響應、 解析響應，等等。這一系列臟活累活，人家Feign全給你干了。Feign的一個關鍵機制就是使用了動態代理。咱們一起來看看下面的圖，結合圖來分析： 1.首先，如果你對某個接口定義了@FeignClient注解，Feign就會針對這個接口創建一個動態代理 2.接著你要是調用那個接口，本質就是會調用 Feign創建的動態代理，這是核心中的核心 3.Feign的動態代理會根據你在接口上的@RequestMapping等注解，來動態構造出你要請求的服務的地址 4.最后針對這個地址，發起請求、解析響應

四、Spring Cloud核心組件：Ribbon說完了Feign，還沒完。現在新的問題又來了，如果人家庫存服務部署在了5臺機器上，如下所示：192.168.169:9000192.168.170:9000192.168.171:9000192.168.172:9000192.168.173:9000這下麻煩了！人家Feign怎么知道該請求哪臺機器呢？這時Spring Cloud Ribbon就派上用場了。Ribbon就是專門解決這個問題的。它的作用是負載均衡，會幫你在 每次請求時選擇一臺機器，均勻的把請求分發到各個機器上Ribbon的負載均衡默認使用的最經典的Round Robin輪詢算法。這是啥？簡單來說，就是如果訂單服務對庫存 服務發起10次請求，那就先讓你請求第1臺機器、然后是第2臺機器、第3臺機器、第4臺機器、第5臺機器，接著 再來—個循環，第1臺機器、第2臺機器。。。以此類推。此外，Ribbon是和Feign以及Eureka緊密協作，完成工作的，具體如下： 1.首先Ribbon會從 Eureka Client里獲取到對應的服務注冊表，也就知道了所有的服務都部署在了哪些機器 上，在監聽哪些端口號。 2.然后Ribbon就可以使用默認的Round Robin算法，從中選擇一臺機器 3.Feign就會針對這臺機器，構造并發起請求。對上述整個過程，再來一張圖，幫助大家更深刻的理解：

五、Spring Cloud核心組件：Hystrix在微服務架構里，一個系統會有很多的服務。以本文的業務場景為例：訂單服務在一個業務流程里需要調用三個 服務。現在假設訂單服務自己最多只有100個線程可以處理請求，然后呢，積分服務不幸的掛了，每次訂單服務 調用積分服務的時候，都會卡住幾秒鐘，然后拋出—個超時異常。咱們一起來分析一下，這樣會導致什么問題？1.如果系統處于高并發的場景下，大量請求涌過來的時候，訂單服務的100個線程都會卡在請求積分服務這塊。 導致訂單服務沒有一個線程可以處理請求2.然后就會導致別人請求訂單服務的時候，發現訂單服務也掛了，不響應任何請求了上面這個，就是微服務架構中恐怖的服務雪崩問題，如下圖所示：

如上圖，這么多服務互相調用，要是不做任何保護的話，某一個服務掛了，就會引起連鎖反應，導致別的服務 也掛。比如積分服務掛了，會導致訂單服務的線程全部卡在請求積分服務這里，沒有一個線程可以工作，瞬間 導致訂單服務也掛了，別人請求訂單服務全部會卡住，無法響應。但是我們思考一下，就算積分服務掛了，訂單服務也可以不用掛啊！為什么？我們結合業務來看：支付訂單的時候，只要把庫存扣減了，然后通知倉庫發貨就OK了如果積分服務掛了，大不了等他恢復之后，慢慢人肉手工恢復數據！為啥一定要因為一個積分服務掛了， 就直接導致訂單服務也掛了呢？不可以接受！現在問題分析完了，如何解決？Hystrix是隔離、熔斷以及降級的一個框架。啥意思呢？說白了，Hystrix會搞很多個小小的線程池，比如訂單 服務請求庫存服務是一個線程池，請求倉儲服務是一個線程池，請求積分服務是一個線程池。每個線程池里的 線程就僅僅用于請求那個服務。打個比方：現在很不幸，積分服務掛了，會咋樣？當然會導致訂單服務里的那個用來調用積分服務的線程都卡死不能工作了啊！但是由于訂單服務調用庫存服務、 倉儲服務的這兩個線程池都是正常工作的，所以這兩個服務不會受到任何影響。這個時候如果別人請求訂單服務，訂單服務還是可以正常調用庫存服務扣減庫存，調用倉儲服務通知發貨。 只不過調用積分服務的時候，每次都會報錯。但是如果積分服務都掛了，每次調用都要去卡住幾秒鐘干啥呢？ 有意義嗎？當然沒有！所以我們直接對積分服務熔斷不就得了，比如在5分鐘內請求積分服務直接就返回了， 不要去走網絡請求卡住幾秒鐘，這個過程，就是所謂的熔斷！那人家又說，兄弟，積分服務掛了你就熔斷，好歹你干點兒什么啊！別啥都不干就直接返回啊？沒問題，咱們 就來個降級：每次調用積分服務，你就在數據庫里記錄一條消息，說給某某用戶增加了多少積分，因為積分服務 掛了，導致沒增加成功！這樣等積分服務恢復了，你可以根據這些記錄手工加一下積分。這個過程，就是所謂的 降級。為幫助大家更直觀的理解，接下來用一張圖，梳理一下Hystrix隔離、熔斷和降級的全流程：

六、Spring Cloud核心組件：Zuul

Zuul，也就是微服務網關。這個組件是負責網絡路由的。不懂網絡路由？行，那我給你說說，如果沒有Zuul的 日常工作會怎樣？假設你后臺部署了幾百個服務，現在有個前端兄弟，人家請求是直接從瀏覽器那兒發過來的。打個比方：人家要 請求一下庫存服務，你難道還讓人家記著這服務的名字叫做inventory-service？部署在5臺機器上？就算人家 肯記住這一個，你后臺可有幾百個服務的名稱和地址呢？難不成人家請求一個，就得記住一個？你要這樣玩兒， 那真是友誼的小船，說翻就翻！上面這種情況，壓根兒是不現實的。所以一般微服務架構中都必然會設計一個網關在里面，像android、ios、 pc前端、微信小程序、H5等等，不用去關心后端有幾百個服務，就知道有一個網關，所有請求都往網關走， 網關會根據請求中的一些特征，將請求轉發給后端的各個服務。而且有一個網關之后，還有很多好處，比如可以做統一的降級、限流、認證授權、安全，等等。七、總結：最后再來總結一下，上述幾個Spring Cloud核心組件，在微服務架構中，分別扮演的角色：1.Eureka：各個服務啟動時，Eureka Client都會將服務注冊到Eureka Server，并且Eureka Client還可以 反過來從Eureka Server拉取注冊表，從而知道其他服務在哪里 2.Ribbon：服務間發起請求的時候，基于Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺 3.Feign：基于Feign的動態代理機制，根據注解和選擇的機器，拼接請求URL地址，發起請求 4.Hystrix：發起請求是通過Hystrix的線程池來走的，不同的服務走不同的線程池，實現了不同服務調用的 隔離，避免了服務雪崩的問題 5.Zuul：如果前端、移動端要調用后端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務通過一個電商業務場景，闡述了Spring Cloud微服務架構幾個核心組件的底層原理。我們將Spring Cloud的5個核心組件通過一張圖串聯起來，再來直觀的感受一下其底層的架構原理：

Spring Cloud

什么是Spring Cloud？一個生命周期短暫的微服務框架，用于快速構建執行有限數據處理的應用程序。使用Spring Cloud有什么優勢？使用Spring Boot開發分布式微服務時，我們面臨以下問題 1.與分布式系統相關的復雜性-這種開銷包括網絡問題，延遲開銷，帶寬問題，安全問題。 2.服務發現-服務發現工具管理群集中的流程和服務如何查找和互相交談。它涉及一個服務目錄， 在該目錄中注冊服務，然后能夠查找并連接到該目錄中的服務。 3.冗余-分布式系統中的冗余問題。 4.負載平衡 --負載平衡改善跨多個計算資源的工作負荷 5.性能-問題 由于各種運營開銷導致的性能問題。 6.部署復雜性-Devops技能的要求。服務注冊和發現是什么意思？Spring Cloud如何實現？Eureka服務注冊和發現可以在這種情況下提供幫助。由于所有服務都在Eureka服務器上注冊并通過調用Eureka 服務器完成查找，因此無需處理服務地點的任何更改和處理。負載平衡的意義什么？ 1.負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間并避免任何單一資源的過載。 2.使用多個組件進行負載平衡而不是單個組件可能會通過冗余來提高可靠性和可用性。什么是Hystrix？它如何實現容錯？ 1.Hystrix是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的 故障時，停止級聯故障并在復雜的分布式系統中實現彈性。2.通常對于使用微服務架構開發的系統，涉及到許多微服務。這些微服務彼此協作。什么是Netflix Feign？它的優點是什么？1.Feign是受到Retrofit，JAXRS-2.0和WebSocket啟發的java客戶端聯編程序。 2.使用功能區進行負載平衡。 3.獲取服務實例，然后獲取基本URL。 4.利用REST模板來使用服務。 前面的代碼如下

SpringCloud

1.SpringCloud和DubboSpringCloud和Dubbo都是現在主流的微服務架構SpringCloud是Apache旗下的Spring體系下的微服務解決方案Dubbo是阿里系的分布式服務治理框架從技術維度上,其實SpringCloud遠遠的超過Dubbo,Dubbo本身只是實現了服務治理,而SpringCloud現在以及 有21個子項目以后還會更多服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義服務的注冊中心來看,Dubbo使用了第三方的ZooKeeper作為其底層的注冊中心,實現服務的注冊和 發現,SpringCloud使用Spring Cloud Netflix Eureka實現注冊中心,當然SpringCloud也可以 使用ZooKeeper實現,但一般我們不會這樣做.服務網關,Dubbo并沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由網關,作為路由 服務器,進行消費者的請求分發,SpringCloud還支持斷路器2.技術選型 1)目前國內的分布式系統選型主要還是Dubbo畢竟國產,而且國內工程師的技術熟練程度高,并且Dubbo在其他維度 上的缺陷可以由其他第三方框架進行集成進行彌補 2)SpringCloud目前是國外比較流行,當然我覺得國內的市場也會慢慢的偏向SpringCloud,就連劉軍作為Dubbo 重啟的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,并不是起沖突3.Rest和RPC對比 1)微服務提出者馬丁福勒的論文的話可以發現其定義的服務間通信機制就是Http Rest 2)RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,我們需要為每一個微服務進行接口的定義,并通過 持續繼承發布,需要嚴格的版本控制才不會出現服務提供和調用之間因為版本不同而產生的沖突 3)而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是通過一個約定進行規范,但也有可能 出現文檔和接口不一致而導致的服務集成問題,但可以通過swagger工具整合,是代碼和文檔一體化解決,所以 REST在分布式環境下比RPC更加靈活 4)當當網的DubboX在對Dubbo的增強中增加了對REST的支持4.文檔質量和社區活躍度 1)SpringCloud社區活躍度遠高于Dubbo,畢竟由于梁飛團隊的原因導致Dubbo停止更新迭代五年,而中小型 公司無法承擔技術開發的成本導致Dubbo社區嚴重低落 2)而SpringCloud異軍突起,迅速占領了微服務的市場,背靠Spring混的風生水起 3)Dubbo經過多年的積累文檔相當成熟,對于微服務的架構體系各個公司也有穩定的現狀二.SpringBoot和SpringCloud1.SpringBoot是Spring推出用于解決傳統框架配置文件冗余,裝配組件繁雜的基于Maven的解決方案,旨在快速 搭建單個微服務2.而SpringCloud專注于解決各個微服務之間的協調與配置,服務之間的通信,熔斷,負載均衡等3.技術維度并相同,并且SpringCloud是依賴于SpringBoot的,而SpringBoot并不是依賴與SpringCloud, 甚至還可以和Dubbo進行優秀的整合開發總結: 1.SpringBoot專注于快速方便的開發單個個體的微服務2.SpringCloud是關注全局的微服務協調整理治理框架,整合并管理各個微服務,為各個微服務之間提供, 配置管理,服務發現,斷路器,路由,事件總線等集成服務3.SpringBoot不依賴于SpringCloud,SpringCloud依賴于SpringBoot,屬于依賴關系4.SpringBoot專注于快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架三.Eureka和ZooKeeper都可以提供服務注冊與發現的功能,請說說兩個的區別1.ZooKeeper保證的是CP,Eureka保證的是AP2.ZooKeeper在選舉期間注冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的3.Eureka各個節點是平等關系,只要有一臺Eureka就可以保證服務可用,而查詢到的數據并不是最新的自我保護機制會導致1.Eureka不再從注冊列表移除因長時間沒收到心跳而應該過期的服務2.Eureka仍然能夠接受新服務的注冊和查詢請求,但是不會被同步到其他節點(高可用)3.當網絡穩定時,當前實例新的注冊信息會被同步到其他節點中(最終一致性)Eureka可以很好的應對因網絡故障導致部分節點失去聯系的情況,而不會像ZooKeeper一樣使得整個注冊系統 癱瘓2.ZooKeeper有Leader和Follower角色,Eureka各個節點平等3.ZooKeeper采用過半數存活原則,Eureka采用自我保護機制解決分區問題4.Eureka本質上是一個工程,而ZooKeeper只是一個進程四.微服務之間是如何獨立通訊的遠程過程調用（Remote Procedure Invocation）也就是我們常說的服務的注冊與發現直接通過遠程過程調用來訪問別的service。優點： 簡單，常見,因為沒有中間件代理，系統更簡單缺點： 只支持請求/響應的模式，不支持別的，比如通知、請求/異步響應、發布/訂閱、發布/異步響應 降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的二、消息使用異步消息來做服務間通信。服務間通過消息管道來交換消息，從而通信。優點:把客戶端和服務端解耦，更松耦合提高可用性，因為消息中間件緩存了消息，直到消費者可以消費支持很多通信機制比如通知、請求/異步響應、發布/訂閱、發布/異步響應缺點:消息中間件有額外的復雜性20.什么是服務熔斷?什么是服務降級1.在復雜的分布式系統中,微服務之間的相互調用,有可能出現各種各樣的原因導致服務的阻塞,在高并發場景 下,服務的阻塞意味著線程的阻塞,導致當前線程不可用,服務器的線程全部阻塞,導致服務器崩潰,由于服務 之間的調用關系是同步的,會對整個微服務系統造成服務雪崩2.為了解決某個微服務的調用響應時間過長或者不可用進而占用越來越多的系統資源引起雪崩效應就需要 進行服務熔斷和服務降級處理。3.所謂的服務熔斷指的是某個服務故障或異常一起類似顯示世界中的“保險絲"當某個異常條件被觸發就直接 熔斷整個服務，而不是一直等到此服務超時。4.服務熔斷就是相當于我們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,通過維護一個自己的 線程池,當線程達到閾值的時候就啟動服務降級,如果其他請求繼續訪問就直接返回fallback的默認值21.微服務的優缺點分別是什么?說下你在項目開發中碰到的坑優點 1.每一個服務足夠內聚,代碼容易理解 2.開發效率提高,一個服務只做一件事 3.微服務能夠被小團隊單獨開發 4.微服務是松耦合的,是有功能意義的服務 5.可以用不同的語言開發,面向接口編程 6.易于與第三方集成 7.微服務只是業務邏輯的代碼,不會和HTML,CSS或者其他界面組合 8.開發中,兩種開發模式前后端分離全棧工程師 9.可以靈活搭配,連接公共庫/連接獨立庫缺點 1.多服務運維難度,隨著服務的增加,運維的壓力也在增大 2.多服務運維難度,隨著服務的增加,運維的壓力也在增大 3.服務間通信成本 4.數據一致性 5.系統集成測試 6.性能監控22.你所知道的微服務技術棧有哪些?請列舉一二維度(SpringCloud)服務開發 SpringBoot Spring SpringMVC服務配置與管理 Netfilx公司的Archaiusm,阿里的Diamond服務注冊與發現 Eureka,ZooKeeper服務調用 Rest,RPC,gRPC服務熔斷器 Hystrix服務負載均衡 Ribbon,Nginx服務接口調用 Feign消息隊列 Kafka,RabbitMq,ActiveMq服務配置中心管理 SpringCloudConfing服務路由(API網關) Zuul事件消息總線 SpringCloud Bus

?

總結

以上是生活随笔為你收集整理的springboot+springcloud相关问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。