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

Spring Cloud底層原理

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

有了業(yè)務(wù)場(chǎng)景之后，咱們就一起來(lái)看看Spring Cloud微服務(wù)架構(gòu)中，這幾個(gè)組件如何相互協(xié)作，各自發(fā)揮的 作用以及其背后的原理。二、Spring Cloud核心組件：Eureka訂單服務(wù)想要調(diào)用庫(kù)存服務(wù)、倉(cāng)儲(chǔ)服務(wù)，或者是積分服務(wù)，怎么調(diào)用？1.訂單服務(wù)壓根兒就不知道人家?guī)齑娣?wù)在哪臺(tái)機(jī)器上啊！他就算想要發(fā)起一個(gè)請(qǐng)求，都不知道發(fā)送給誰(shuí)， 有心無(wú)力！2.這時(shí)候，就輪到Spring Cloud Eureka出場(chǎng)了。Eureka是微服務(wù)架構(gòu)中的注冊(cè)中心，專門負(fù)責(zé)服務(wù)的注冊(cè) 與發(fā)現(xiàn)。

庫(kù)存服務(wù)、倉(cāng)儲(chǔ)服務(wù)、積分服務(wù)中都有一個(gè)Eureka Client組件，這個(gè)組件專門負(fù)責(zé)將這個(gè)服務(wù)的信息注冊(cè) 到Eureka Server中。說(shuō)白了，就是告訴Eureka Server，自己在哪臺(tái)機(jī)器上，監(jiān)聽著哪個(gè)端口。而 Eureka Server是一個(gè)注冊(cè)中心，里面有一個(gè)注冊(cè)表，保存了各服務(wù)所在的機(jī)器和端口號(hào)訂單服務(wù)里也有一個(gè)Eureka Client組件，這個(gè)Eureka Client組件會(huì)找Eureka Server問(wèn)一下：庫(kù)存服務(wù)在 哪臺(tái)機(jī)器啊？監(jiān)聽著哪個(gè)端口啊？倉(cāng)儲(chǔ)服務(wù)呢？積分服務(wù)呢？然后就可以把這些相關(guān)信息從Eureka Server的 注冊(cè)表中拉取到自己本地緩存起來(lái)。這時(shí)如果訂單服務(wù)想要調(diào)用庫(kù)存服務(wù)，不就可以找自己本地的Eureka Client問(wèn)一下庫(kù)存服務(wù)在哪臺(tái)機(jī)器？ 監(jiān)聽哪個(gè)端口嗎？收到響應(yīng)后，緊接著就可以發(fā)送一個(gè)請(qǐng)求過(guò)去，調(diào)用庫(kù)存服務(wù)扣減庫(kù)存的那個(gè)接口！同理， 如果訂單服務(wù)要調(diào)用倉(cāng)儲(chǔ)服務(wù)、積分服務(wù)，也是如法炮制。總結(jié)一下： 1.Eureka Client：負(fù)責(zé)將這個(gè)服務(wù)的信息注冊(cè)到Eureka Server中 2.Eureka Server：注冊(cè)中心，里面有一個(gè)注冊(cè)表，保存了各個(gè)服務(wù)所在的機(jī)器和端口號(hào)三、Spring Cloud核心組件：Feign現(xiàn)在訂單服務(wù)確實(shí)知道庫(kù)存服務(wù)、積分服務(wù)、倉(cāng)庫(kù)服務(wù)在哪里了，同時(shí)也監(jiān)聽著哪些端口號(hào)了。但是新問(wèn)題又 來(lái)了：難道訂單服務(wù)要自己寫一大堆代碼，跟其他服務(wù)建立網(wǎng)絡(luò)連接，然后構(gòu)造一個(gè)復(fù)雜的請(qǐng)求，接著發(fā)送請(qǐng)求 過(guò)去，最后對(duì)返回的響應(yīng)結(jié)果再寫一大堆代碼來(lái)處理嗎？

看完上面的代碼什么感覺(jué)？是不是感覺(jué)整個(gè)世界都干凈了，又找到了活下去的勇氣！沒(méi)有底層的建立連接、 構(gòu)造請(qǐng)求、解析響應(yīng)的代碼，直接就是用注解定義一個(gè) FeignClient接口，然后調(diào)用那個(gè)接口就可以了。 人家Feign Client會(huì)在底層根據(jù)你的注解，跟你指定的服務(wù)建立連接、構(gòu)造請(qǐng)求、發(fā)起靕求、獲取響應(yīng)、 解析響應(yīng)，等等。這一系列臟活累活，人家Feign全給你干了。Feign的一個(gè)關(guān)鍵機(jī)制就是使用了動(dòng)態(tài)代理。咱們一起來(lái)看看下面的圖，結(jié)合圖來(lái)分析： 1.首先，如果你對(duì)某個(gè)接口定義了@FeignClient注解，Feign就會(huì)針對(duì)這個(gè)接口創(chuàng)建一個(gè)動(dòng)態(tài)代理 2.接著你要是調(diào)用那個(gè)接口，本質(zhì)就是會(huì)調(diào)用 Feign創(chuàng)建的動(dòng)態(tài)代理，這是核心中的核心 3.Feign的動(dòng)態(tài)代理會(huì)根據(jù)你在接口上的@RequestMapping等注解，來(lái)動(dòng)態(tài)構(gòu)造出你要請(qǐng)求的服務(wù)的地址 4.最后針對(duì)這個(gè)地址，發(fā)起請(qǐng)求、解析響應(yīng)

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

五、Spring Cloud核心組件：Hystrix在微服務(wù)架構(gòu)里，一個(gè)系統(tǒng)會(huì)有很多的服務(wù)。以本文的業(yè)務(wù)場(chǎng)景為例：訂單服務(wù)在一個(gè)業(yè)務(wù)流程里需要調(diào)用三個(gè) 服務(wù)。現(xiàn)在假設(shè)訂單服務(wù)自己最多只有100個(gè)線程可以處理請(qǐng)求，然后呢，積分服務(wù)不幸的掛了，每次訂單服務(wù) 調(diào)用積分服務(wù)的時(shí)候，都會(huì)卡住幾秒鐘，然后拋出—個(gè)超時(shí)異常。咱們一起來(lái)分析一下，這樣會(huì)導(dǎo)致什么問(wèn)題？1.如果系統(tǒng)處于高并發(fā)的場(chǎng)景下，大量請(qǐng)求涌過(guò)來(lái)的時(shí)候，訂單服務(wù)的100個(gè)線程都會(huì)卡在請(qǐng)求積分服務(wù)這塊。 導(dǎo)致訂單服務(wù)沒(méi)有一個(gè)線程可以處理請(qǐng)求2.然后就會(huì)導(dǎo)致別人請(qǐng)求訂單服務(wù)的時(shí)候，發(fā)現(xiàn)訂單服務(wù)也掛了，不響應(yīng)任何請(qǐng)求了上面這個(gè)，就是微服務(wù)架構(gòu)中恐怖的服務(wù)雪崩問(wèn)題，如下圖所示：

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

六、Spring Cloud核心組件：Zuul

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

Spring Cloud

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

SpringCloud

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

?

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。