Eureka服務(wù)注冊(cè)與發(fā)現(xiàn)

是什么

Eureka是Netflix的一個(gè)子模塊，也是核心模塊之一。Eureka是一個(gè)基本REST的服務(wù)，用戶定位服務(wù)，以實(shí)現(xiàn)云端中間層服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移。服務(wù)注冊(cè)和發(fā)現(xiàn)對(duì)于微服務(wù)架構(gòu)來(lái)說(shuō)是非常重要的，有了服務(wù)發(fā)現(xiàn)與注冊(cè)，只需要使用服務(wù)的標(biāo)識(shí)符，就可以訪問(wèn)到服務(wù)，而不需要修改服務(wù)調(diào)用的配置文件了，功能類似于doubo的注冊(cè)中心，比如Zookeeper.
　　遵守AP原則

三大特色

1.Eureka Server提供服務(wù)注冊(cè)和發(fā)現(xiàn)。
　　2.Service Provider服務(wù)提供方將自身服務(wù)注冊(cè)到Eureka，從而使服務(wù)消費(fèi)方能夠找到。
　　3.Service Consumer服務(wù)消費(fèi)方從Eureka獲取注冊(cè)服務(wù)列表，從而能夠消費(fèi)服務(wù)

基本構(gòu)架

Spring Cloud封裝了Netflix公司開(kāi)發(fā)Eureka模塊來(lái) 實(shí)現(xiàn)服務(wù)注冊(cè)和發(fā)現(xiàn)(請(qǐng)對(duì)比Zookeeper)
　　Eureka采用了C-S的設(shè)計(jì)架構(gòu)。Eureka Server作為服務(wù)注冊(cè)功能的服務(wù)器，它是服務(wù)注冊(cè)中心。
　　而系統(tǒng)中的其他微服務(wù)，使用Eureka的客戶端連接到Eureka Server并維持心跳連接。這樣系統(tǒng)的維護(hù)人員就可以通過(guò)Eureka Server來(lái)監(jiān)控系統(tǒng)中各個(gè)微服務(wù)是否正常運(yùn)行。SpringCloud的一些其他模塊(比如Zuul)就可以通過(guò)Eureka Server來(lái)實(shí)現(xiàn)系統(tǒng)中的其他微服務(wù)，并執(zhí)行相關(guān)的邏輯。

　　Eureka包含兩個(gè)組件：Eureka Server和Eureka Client
　　Eureka Server 提供服務(wù)注冊(cè)服務(wù)。各個(gè)節(jié)點(diǎn)啟動(dòng)后，會(huì)在EurekaServer中進(jìn)行注冊(cè)，這樣EurekaServer中的服務(wù)注冊(cè)表中將會(huì)存儲(chǔ)所有可用服務(wù)節(jié)點(diǎn)的信息，服務(wù)節(jié)點(diǎn)的信息可以在界面中直觀的看到。
　　Eureka Client 是一個(gè)Java客戶端，用于簡(jiǎn)化Eureka Server的交互，客戶端同時(shí)也具備一個(gè)內(nèi)置的、使用輪詢(round-robin)負(fù)載算法的負(fù)載均衡器。在應(yīng)用啟動(dòng)后，將會(huì)向Eureka Server發(fā)送心跳(默認(rèn)周期為30秒)。如果Eureka Server在多個(gè)心跳周期內(nèi)沒(méi)有接收到某個(gè)節(jié)點(diǎn)的心跳，EurekaServer將會(huì)從服務(wù)注冊(cè)表中把這個(gè)服務(wù)節(jié)點(diǎn)移除(默認(rèn)90秒)。 　　　　

自我保護(hù)

image

導(dǎo)致原因：某時(shí)刻某一個(gè)微服務(wù)不可用了，eureka不會(huì)立刻清理，依舊會(huì)對(duì)該微服務(wù)的信息進(jìn)行保存。

　　什么是自我保護(hù)模式？
　　默認(rèn)情況下，如果EurekaServer在一定時(shí)間內(nèi)沒(méi)有接收到某個(gè)微服務(wù)實(shí)例的心跳，EurekaServer將會(huì)注銷該實(shí)例(默認(rèn)90秒)。但是當(dāng)前網(wǎng)絡(luò)分區(qū)故障發(fā)生時(shí)，微服務(wù)與EurekaServer之間無(wú)法正常通信，以上行為可能變得非常危險(xiǎn)了：因?yàn)槲⒎?wù)本身其實(shí)是健康的，此時(shí)本不應(yīng)該注銷這個(gè)微服務(wù)。
　　Eureka通過(guò)“自我保護(hù)模式”來(lái)解決這個(gè)問(wèn)題：當(dāng)EurekaServer節(jié)點(diǎn)在短時(shí)間內(nèi)丟失過(guò)多客戶端時(shí)(可能發(fā)生了網(wǎng)絡(luò)分區(qū)故障)，那么這個(gè)節(jié)點(diǎn)就會(huì)進(jìn)入自我保護(hù)模式。一旦進(jìn)入該模式，EurekaServer就會(huì)保護(hù)服務(wù)注冊(cè)中心的信息，不再刪除服務(wù)注冊(cè)表捉的數(shù)據(jù)(也就不會(huì)注銷任何微服務(wù))。當(dāng)網(wǎng)絡(luò)故障收復(fù)后，該EurekaServer節(jié)點(diǎn)會(huì)自動(dòng)退出自我保護(hù)模式。
　　在自我保護(hù)模式中，EurekaServer會(huì)保護(hù)服務(wù)注冊(cè)表中的信息，不再注銷任何服務(wù)實(shí)例。當(dāng)它收到的心跳數(shù)重新恢復(fù)到閥值以上時(shí)，該EurekaServer節(jié)點(diǎn)就會(huì)自動(dòng)退出自我保護(hù)模式。它的設(shè)計(jì)哲學(xué)就是寧可保留錯(cuò)誤的服務(wù)注冊(cè)信息，也不盲目注銷任何可能健康的服務(wù)實(shí)例。一句話講：好死不如耐活著。
　　綜上，自我保護(hù)模式是一種應(yīng)對(duì)網(wǎng)絡(luò)異常的安全保護(hù)措施。它的架構(gòu)哲學(xué)是寧可同時(shí)保留所有的微服務(wù)(健康的微服務(wù)和不健康的微服務(wù)都會(huì)保留)，也不盲目注銷任何健康的微服務(wù)。使用自我保護(hù)模式，可以讓Eureka集群更加健壯、穩(wěn)定。

　　在Spring Cloud中，可以使用eureka.server.enable-self-preservation = false 禁用自我保護(hù)模式，不建議關(guān)閉

與Dobbo比較

image

image

服務(wù)發(fā)現(xiàn)

對(duì)于注冊(cè)進(jìn)eureka里面的微服務(wù)，可以通過(guò)服務(wù)發(fā)現(xiàn)來(lái)獲得該服務(wù)的信息 　　

作為服務(wù)注冊(cè)中心，eureka比zookeeper好在哪里？

著名的CAP理論指出，一個(gè)分布式系統(tǒng)不可能同時(shí)滿足C(一致性)，A(高可用), P(分區(qū)容錯(cuò)性)。由于分區(qū)容錯(cuò)性P在是分布式系統(tǒng)中必須要保證的，因此我們只能在A和C之間進(jìn)行權(quán)衡。
　　Zookeeper保證了CP，Eureka保證了AP.
　　Eureka各個(gè)節(jié)點(diǎn)是平等的；Zookeeper：一個(gè)領(lǐng)導(dǎo)者（leader），多個(gè)跟隨者（follower）組成的集群。集群中只要有半數(shù)以上(>)節(jié)點(diǎn)存活，Zookeeper集群就能正常服務(wù)。部署一般部署奇數(shù)臺(tái)
　　1.Zookeeper保證了CP
　　當(dāng)向注冊(cè)中心查詢服務(wù)列表時(shí)，我們可以容忍注冊(cè)中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用。也就是說(shuō)，服務(wù)注冊(cè)功能對(duì)高可用性要求比較高，但zk會(huì)出現(xiàn)這樣一種情況，當(dāng)master節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)故障與其他節(jié)點(diǎn)失去聯(lián)系時(shí)，剩余節(jié)點(diǎn)會(huì)重新選leader。問(wèn)題在于，選取leader時(shí)間過(guò)長(zhǎng)，30 ~ 120s，且選取期間zk集群都不可用，這樣就會(huì)導(dǎo)致選取期間注冊(cè)服務(wù)癱瘓。在云部署的環(huán)境下，因網(wǎng)絡(luò)問(wèn)題使得zk集群失去master節(jié)點(diǎn)是較大概率會(huì)發(fā)生的事，雖然服務(wù)能夠恢復(fù)，但是漫長(zhǎng)的選取時(shí)間導(dǎo)致的注冊(cè)長(zhǎng)期不可用是不能容忍的。
　　2.Eureka保證了AP
　　Eureka保證了可用性，Eureka各個(gè)節(jié)點(diǎn)是平等的，幾個(gè)節(jié)點(diǎn)掛掉不會(huì)影響正常節(jié)點(diǎn)的工作，剩余的節(jié)點(diǎn)仍然可以提供注冊(cè)和查詢服務(wù)。而Eureka的客戶端向某個(gè)Eureka注冊(cè)或發(fā)現(xiàn)是發(fā)生連接失敗，則會(huì)自動(dòng)切換到其他節(jié)點(diǎn)，只要有一臺(tái)Eureka還在，就能保證注冊(cè)服務(wù)可用，只是查到的信息可能不是最新的。除此之外，Eureka還有自我保護(hù)機(jī)制，如果在15分鐘內(nèi)超過(guò)85%的節(jié)點(diǎn)沒(méi)有正常的心跳，那么Eureka就認(rèn)為客戶端與注冊(cè)中心發(fā)生了網(wǎng)絡(luò)故障，此時(shí)會(huì)出現(xiàn)以下幾種情況：
　　　　①、Eureka不在從注冊(cè)列表中移除因?yàn)殚L(zhǎng)時(shí)間沒(méi)有收到心跳而應(yīng)該過(guò)期的服務(wù)。
　　　?、凇ureka仍然能夠接受新服務(wù)的注冊(cè)和查詢請(qǐng)求，但是不會(huì)被同步到其他節(jié)點(diǎn)上（即保證當(dāng)前節(jié)點(diǎn)仍然可用）
　　　　③、當(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è)微服務(wù)癱瘓。
　　Eureka可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況，而不會(huì)像zookeeper那樣整個(gè)注冊(cè)服務(wù)癱瘓

Ribbon負(fù)載均衡(客戶端)

配置完成后：完成真正的通知微服務(wù)名字從eureka上找到并訪問(wèn)

是什么

SpringCloud Ribbon是基于Netflix Ribbon實(shí)現(xiàn)的一套 客戶端 負(fù)載均衡的工具
　　簡(jiǎn)單的說(shuō)，Ribbon是Netflix發(fā)布的開(kāi)源項(xiàng)目，主要功能是提供客戶端的軟件負(fù)載均衡算法，將Netflix的中間層服務(wù)連接在一起。Ribbon客戶端組件提供一系列完善的配置項(xiàng)如何連接超時(shí)、重試等。簡(jiǎn)單的說(shuō)，就是在配置文件中列出Load Balancer(簡(jiǎn)稱LB)后面的所有的機(jī)器，Ribbon會(huì)自動(dòng)的幫助你基于某種規(guī)則(如簡(jiǎn)單輪詢，隨機(jī)連接等)去連接這些機(jī)器。我們也很容易使用Ribbon實(shí)現(xiàn)自定義的負(fù)載均衡算法。

能干嘛

LB(負(fù)載均衡)，在微服務(wù)或分布式集群中經(jīng)常用到的一種應(yīng)用。負(fù)載均衡簡(jiǎn)單的說(shuō)就是將用戶的請(qǐng)求平攤到多個(gè)服務(wù)上，從而達(dá)到系統(tǒng)的HA(高可用)。
　　常見(jiàn)的負(fù)載均衡有軟件Nginx，LVS，硬件F5等。
　　相應(yīng)的中間件，如doubbo和SpringCloud中均給我們提供了負(fù)載均衡，SpringCloud的負(fù)載均衡算法可自定義。

　　1.集中式LB
　　即在服務(wù)的消費(fèi)方和提供方之間使用獨(dú)立的LB設(shè)施(可以是硬件，如F5，也可以是軟件，如nginx)，由該設(shè)施負(fù)責(zé)把訪問(wèn)請(qǐng)求通過(guò)某種策略轉(zhuǎn)發(fā)至服務(wù)的提供方。

　　2.進(jìn)程內(nèi)LB
　　將LB邏輯集成到消費(fèi)方，消費(fèi)方從服務(wù)注冊(cè)中心獲知有哪些地址可用，然后自己再?gòu)倪@些地址中選擇出一個(gè)合適的服務(wù)器。
　　Ribbon屬于進(jìn)程內(nèi)LB，它只是一個(gè)類庫(kù)，集成于消費(fèi)方進(jìn)程，消費(fèi)方通過(guò)它來(lái)獲取到服務(wù)提供方的地址。

負(fù)載均衡

架構(gòu)說(shuō)明

image

Ribbon在工作時(shí)分成兩步：
　　1.先選擇EurekaServer，它優(yōu)先選擇在同一個(gè)區(qū)域內(nèi)負(fù)載較少的server。
　　2.再根據(jù)用戶指定的策略，在從server取到的服務(wù)注冊(cè)列表中選擇一個(gè)地址。
　　其中Ribbon提供了多種策略：如輪詢、隨機(jī)等。

　　總結(jié)：Ribbon其實(shí)就是一個(gè)軟負(fù)載均衡的客戶端組件，它可以和其他所需請(qǐng)求的客戶端結(jié)合使用，和eureka結(jié)合只是其中的一個(gè)實(shí)例

核心組件IRule：負(fù)載均衡算法

IRule: 根據(jù)特定算法從服務(wù)列表中選取一個(gè)要訪問(wèn)的服務(wù)
　　默認(rèn)有7種算法：
　　1.RoundRobinRule：輪詢
　　2.RandomRule：隨機(jī)
　　3.AvailabilityFilteringRule
　　4.WeightedResponseTimeRule
　　5.RetryRule：先按照RoundRobinRule的策略獲取服務(wù)，如果獲取服務(wù)失敗則在指定時(shí)間內(nèi)會(huì)進(jìn)行重試，獲取可用的服務(wù)
　　6.BestAvailableRule
　　7.ZoneAvoidanceRule

　　自定義算法：
　　自定義MySelfRule類不能在該主啟動(dòng)類當(dāng)前包及子包下。也就是不能放在@ComponentScan所掃描的當(dāng)前包下及子包下，（@SpringBootApplication 注解里有@ComponentScan）

Feign負(fù)載均衡

Feign是什么

Feign是一個(gè)聲明式WebService客戶端。使用Feign能讓編寫(xiě)Web Service客戶端更加簡(jiǎn)單，這的使用方法是定義一個(gè)接口，然后在上面添加注解，同時(shí)也支持JAX-RS標(biāo)準(zhǔn)的注解。Feign也支持可拔插式的編碼器和解碼器。SpringCloud對(duì)Feign進(jìn)行了封裝，使其支持了Spring MVC標(biāo)準(zhǔn)注解和HttpMessageConverters。Feign可以與Eureka和Ribbon組合使用以支持負(fù)載均衡。
　　Feign是一個(gè)聲明式的Web服務(wù)客戶端，使得編寫(xiě)Web服務(wù)客戶端變得非常容易，**只需要?jiǎng)?chuàng)建一個(gè)接口，然后在上面添加注解即可**。也就是面向接口編程
　　[官網(wǎng)資料](https://github.com/OpenFeign/feign)

Feign能干嘛

Feign旨在使編寫(xiě)Java Http客戶端變得更容易。
　　前面在使用Ribbon + RestTemplate時(shí)，利用RestTemplate對(duì)http請(qǐng)求的封裝處理，形成了一套模版化的調(diào)用方法。但是實(shí)際開(kāi)發(fā)中，由于對(duì)服務(wù)依賴的調(diào)用可能不止一處，往往一個(gè)接口會(huì)被多處調(diào)用，所以通常都會(huì)針對(duì)每個(gè)微服務(wù)自行封裝一些客戶端類來(lái)包裝這些依賴服務(wù)的調(diào)用。所以，F(xiàn)eign在些基礎(chǔ)上做了進(jìn)一步封裝，由他來(lái)幫助我們定義和實(shí)現(xiàn)依賴服務(wù)接口的定義。在Feign的實(shí)現(xiàn)下，我們只需要?jiǎng)?chuàng)建一個(gè)接口并使用注釋的方式來(lái)配置它(以前是在Dao接口上標(biāo)注Mapper注解，現(xiàn)在是一個(gè)微服務(wù)接口上面標(biāo)注一個(gè)Feign注解即可)，即可完成對(duì)服務(wù)提供方的接口綁定，簡(jiǎn)化了使用SpringCloud Ribbon時(shí)，自動(dòng)封裝服務(wù)調(diào)用客戶端的開(kāi)發(fā)量。 　　

實(shí)例說(shuō)明

Feign集成了Ribbon
　　利用Ribbon維護(hù)了SrpingCloud-dept的服務(wù)列表信息，并且通過(guò)輪詢實(shí)現(xiàn)了客戶端的負(fù)載均衡。而與Ribbon不同的是，**利用feign只需要定義服務(wù)綁定接口且以聲明式的方法**，優(yōu)雅而簡(jiǎn)單的實(shí)現(xiàn)了服務(wù)調(diào)用。
　　Feign通過(guò)接口的方法調(diào)用Rest服務(wù)(之前是Ribbon + RestTemplate)，該請(qǐng)求發(fā)送給Eureka服務(wù)器([http://Spring-cloud-dept/dept/list)，通過(guò)Feign直接找到服務(wù)接口，由于在進(jìn)行服務(wù)調(diào)用的時(shí)候融合了Ribbon技術(shù)，所以也支持負(fù)載均衡作用。](http://spring-cloud-dept/dept/list)%EF%BC%8C%E9%80%9A%E8%BF%87Feign%E7%9B%B4%E6%8E%A5%E6%89%BE%E5%88%B0%E6%9C%8D%E5%8A%A1%E6%8E%A5%E5%8F%A3%EF%BC%8C%E7%94%B1%E4%BA%8E%E5%9C%A8%E8%BF%9B%E8%A1%8C%E6%9C%8D%E5%8A%A1%E8%B0%83%E7%94%A8%E7%9A%84%E6%97%B6%E5%80%99%E8%9E%8D%E5%90%88%E4%BA%86Ribbon%E6%8A%80%E6%9C%AF%EF%BC%8C%E6%89%80%E4%BB%A5%E4%B9%9F%E6%94%AF%E6%8C%81%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E4%BD%9C%E7%94%A8%E3%80%82)

Hystrix斷路器

概述

分布式系統(tǒng)面臨的問(wèn)題

復(fù)雜分布式體系結(jié)構(gòu)中的應(yīng)用程序有數(shù)十個(gè)依賴關(guān)系，每個(gè)依賴關(guān)系某些時(shí)候不可避免地失敗
　　服務(wù)雪崩：
　　多個(gè)微服務(wù)之前調(diào)用的時(shí)候，假設(shè)微服務(wù)A調(diào)用微服務(wù)B和微服務(wù)C，微服務(wù)B和微微服務(wù)C又調(diào)用其他的微服務(wù)，這就是所謂的”扇出“.如果扇出的鏈路上某個(gè)微服務(wù)的調(diào)用響應(yīng)時(shí)間過(guò)長(zhǎng)或者不可用，對(duì)微服務(wù)A的調(diào)用就會(huì)占用越來(lái)越多的系統(tǒng)資源，進(jìn)而引起系統(tǒng)崩潰，所謂的”雪崩效應(yīng)”。
　　對(duì)于高流量的應(yīng)用來(lái)說(shuō)，單一的后端依賴可能會(huì)導(dǎo)致所有的服務(wù)器上的所有資源都會(huì)在幾秒內(nèi)飽和。比失敗更糟糕的是，這些應(yīng)用程序還可能導(dǎo)致服務(wù)之間的延遲增加，備份隊(duì)列，線程和其他系統(tǒng)資源緊張，導(dǎo)致整個(gè)系統(tǒng)發(fā)生更多的級(jí)聯(lián)故障。這些都表示需要對(duì)故障和延遲進(jìn)行隔離和管理，以便單個(gè)依賴關(guān)系的失敗，不能取消整個(gè)應(yīng)用程序或系統(tǒng)。

是什么

Hystrix是一個(gè)用于處理分布式系統(tǒng) **延遲** 和 **容錯(cuò)** 的開(kāi)源庫(kù)，在分布式系統(tǒng)里，許多依賴不可避免的會(huì)調(diào)用失敗，比如超時(shí)，異常等，Hystrix能夠保證在一個(gè)依賴出問(wèn)題的情況下，**不會(huì)導(dǎo)致整體服務(wù)失敗，避免級(jí)聯(lián)故障，以提高分布式系統(tǒng)的彈性**。
　　“斷路器”本身是一種開(kāi)關(guān)裝置，當(dāng)某個(gè)服務(wù)單元發(fā)生故障之后，通過(guò)斷路器的故障監(jiān)控(類似熔斷保險(xiǎn)絲)，**向調(diào)用方法回一個(gè)符合預(yù)期的、可處理的備選響應(yīng)(FallBack)，而不是長(zhǎng)時(shí)間的等待或者拋出調(diào)用方式無(wú)法處理的異常**，這樣就保證了服務(wù)調(diào)用方的線程不會(huì)被長(zhǎng)時(shí)間、不必要地占用，從而避免了故障在分布式系統(tǒng)中的蔓延，及至雪崩。
　　[官網(wǎng)資料](https://github.com/Netflix/Hystrix/wiki)

能干嘛

服務(wù)降級(jí)、服務(wù)熔斷、服務(wù)限流、接近實(shí)時(shí)的監(jiān)控

服務(wù)熔斷

熔斷機(jī)制是應(yīng)用雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制。
　　當(dāng)扇出鏈路的某個(gè)微服務(wù)不可用或者響應(yīng)時(shí)間太長(zhǎng)時(shí)，會(huì)進(jìn)行服務(wù)的降級(jí)，進(jìn)而熔斷該節(jié)點(diǎn)微服務(wù)的調(diào)用，快速返回“錯(cuò)誤”的響應(yīng)信息。當(dāng)檢測(cè)到該節(jié)點(diǎn)微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路。在SpringCloud框架里熔斷機(jī)制通過(guò)Hystrix實(shí)現(xiàn)。Hystrix會(huì)監(jiān)控微服務(wù)間調(diào)用的狀況，當(dāng)失敗的調(diào)用到一定閾值，缺省是 5秒內(nèi)20次調(diào)用失敗就會(huì)啟動(dòng)熔斷機(jī)制。
　　熔斷機(jī)制的注解是 @HystrixCommand.

服務(wù)降級(jí)

是什么：整體資源快不夠了，忍痛將某些服務(wù)先關(guān)掉，待渡過(guò)難關(guān)，再開(kāi)啟回來(lái)
　　服務(wù)降級(jí)處理是在 客戶端實(shí)現(xiàn)完成的，與服務(wù)端沒(méi)什么關(guān)系。
　　此時(shí)服務(wù)端provider已經(jīng)down了，但是我們做了服務(wù)降級(jí)處理，讓客戶端在服務(wù)端不可用時(shí)也會(huì)獲得提示信息而不會(huì)掛起耗死服務(wù)器

服務(wù)熔斷與服務(wù)降級(jí)總結(jié)

熔斷機(jī)制 是應(yīng)對(duì)雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制。當(dāng)扇出鏈路的某個(gè)微服務(wù)不可用或者響應(yīng)時(shí)間太長(zhǎng)時(shí)，會(huì)進(jìn)行服務(wù)降級(jí)，進(jìn)而熔斷該節(jié)點(diǎn)微服務(wù)的調(diào)用，快速返回“錯(cuò)誤”的響應(yīng)信息。當(dāng)檢測(cè)到該節(jié)點(diǎn)微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路。在SpringCloud框架里熔斷機(jī)制通過(guò)Hystrix實(shí)現(xiàn)，Hystrix會(huì)監(jiān)控微服務(wù)間調(diào)用的狀況，當(dāng)失敗的調(diào)用到一定閾值，缺省是5秒內(nèi)調(diào)用20次，如果失敗，就會(huì)啟動(dòng)熔斷機(jī)制。熔斷機(jī)制的注解是@HystrixCommand
　　服務(wù)降級(jí)，一般是從整體負(fù)荷考慮。就是當(dāng)某個(gè)服務(wù)熔斷之后，服務(wù)器將不再被調(diào)用，此時(shí)客戶端可以自己準(zhǔn)備一個(gè)本地的fallback回調(diào)，返回一個(gè)缺省值。這樣做，雖然水平下降，但好歹可用，比直接掛掉強(qiáng)。

　　服務(wù)熔斷：一般是某個(gè)服務(wù)故障或者異常引起，類似現(xiàn)實(shí)世界中的”保險(xiǎn)絲”，當(dāng)某個(gè)異常條件被觸發(fā)，直接熔斷整個(gè)服務(wù)，而不是一直等到此服務(wù)超時(shí)。
　　服務(wù)降級(jí)：所謂降級(jí)，一般是從整體負(fù)荷考慮。就是當(dāng)某個(gè)服務(wù)熔斷之后，服務(wù)器將不再被調(diào)用，此時(shí)客戶端可以自己準(zhǔn)備一個(gè)本地的fallbask回調(diào)，返回一個(gè)缺省值。這樣做，雖然服務(wù)水平下降，但好歹可用，比直接掛掉要強(qiáng)。

服務(wù)監(jiān)控HystrixDashboard

是什么

除了隔離依賴服務(wù)的調(diào)用以外，Hystrix還提供了 準(zhǔn)實(shí)時(shí)的調(diào)用監(jiān)控(Hystrix Dashboard)，Hystrix會(huì)持續(xù)記錄所有通過(guò)Hystrix發(fā)送的請(qǐng)求的執(zhí)行信息，并以統(tǒng)計(jì)報(bào)表的圖形的形式展示給用戶，包括每秒執(zhí)行多少請(qǐng)求、多少成功、多少失敗等。Netflix通過(guò)hystrix-metrics-event-stream項(xiàng)目實(shí)現(xiàn)了對(duì)以上指標(biāo)的監(jiān)控。SpringCloud也提供了Hystrix Dashboard的整合，對(duì)監(jiān)控內(nèi)容轉(zhuǎn)化成可視化界面。

觀察監(jiān)控窗口

啟動(dòng)后，http://localhost:9001/hystrix,可以看到頁(yè)面如下

image

監(jiān)控http://localhost:8001/hystrix.stream。如果看：7色、1圈、1線
　　7色：

image

1圈：實(shí)心圓：共有兩種含義。
　　　　顏色：代表實(shí)例的健康程度，健康度從綠色<黃色<橙色<紅色遞減。
　　　　大小：根據(jù)實(shí)例的請(qǐng)求流量發(fā)生變化，流量越大該實(shí)心圓越大。
　　　　通過(guò)該實(shí)心圓的展示，可以在大量的實(shí)例中快速的發(fā)現(xiàn) 故障實(shí)例和高壓力實(shí)例。

image

zuul路由網(wǎng)關(guān)

概述

是什么：
　　zuul包含了對(duì)請(qǐng)求的 **路由** 和 **過(guò)濾** 兩個(gè)最主要的功能：
　　其中路由功能能負(fù)責(zé)將外部請(qǐng)求轉(zhuǎn)發(fā)到具體的微服務(wù)實(shí)例上，是實(shí)現(xiàn)外部訪問(wèn)統(tǒng)一入口的基礎(chǔ)。而過(guò)濾器功能則對(duì)請(qǐng)求的處理過(guò)程進(jìn)行干預(yù)，是實(shí)現(xiàn)請(qǐng)求檢驗(yàn)、服務(wù)聚合等功能的基礎(chǔ)。Zuul和Eureka進(jìn)行整合，將Zuul自身注冊(cè)為Eureka服務(wù)治理下的應(yīng)用，同時(shí)從Eureka中獲得其他微服務(wù)的消息，也即以后的訪問(wèn)微服務(wù)都是通過(guò)Zuul跳轉(zhuǎn)后獲得。
　　注意：**Zuul服務(wù)最終還是會(huì)注冊(cè)進(jìn)Eureka**
　　**提供=代理 + 路由 + 過(guò)濾三大功能**

　　能干嘛：路由、過(guò)濾
　　[官網(wǎng)資源](https://github.com/Netflix/zuul/wiki)

分布式配置中心

概述

分布式系統(tǒng)面臨的：配置問(wèn)題

微服務(wù)意味著要將單體應(yīng)用中的業(yè)務(wù)拆分成一個(gè)個(gè)子服務(wù)，每個(gè)服務(wù)的粒度相對(duì)較小，因此系統(tǒng)中會(huì)出現(xiàn)大量的服務(wù)。由于每個(gè)服務(wù)都需要必要的配置信息才能運(yùn)行，所以一套集中式、動(dòng)態(tài)的配置管理設(shè)施是必不可少的。SpringCloud提供了ConfigServer來(lái)解決這個(gè)問(wèn)題，我們每一個(gè)微服務(wù)自己帶著一個(gè)application.yml，上百個(gè)配置文件的管理無(wú)法想象。

是什么

image

SpringCloud Config為微服務(wù)架構(gòu)中的微服務(wù)提供集中化的外部配置支持，配置服務(wù)器為 各個(gè)不同微服務(wù)應(yīng)用 的所有環(huán)境提供了　一個(gè)中心化的外部配置.
　　SpringCloud Config分為 服務(wù)端和客戶端兩部分。
　　服務(wù)端也稱為 分布式配置中心，它是一個(gè)獨(dú)立的微服務(wù)應(yīng)用，用來(lái)連接配置服務(wù)器并為客戶端提供獲得配置信息，加密/解密信息等訪問(wèn)接口。
　　客戶端則是通過(guò)指定的配置中心來(lái)管理應(yīng)用資源，以及與業(yè)務(wù)相關(guān)的配置內(nèi)容，并在啟動(dòng)的時(shí)候從配置中心獲取和加載配置信息。配置服務(wù)器默認(rèn)采用git來(lái)存儲(chǔ)配置信息，這樣就有助于對(duì)環(huán)境配置進(jìn)行版本管理，并且可以通過(guò)git客戶端工具來(lái)方便的管理和訪問(wèn)配置內(nèi)容。

能干嘛

1.集中管理配置文件
　　2.不同環(huán)境不同配置，動(dòng)態(tài)化的配置更新，分環(huán)境部署如dev/test/prod/beta/release
　　3.運(yùn)行期間動(dòng)態(tài)調(diào)整配置，不再需要在每個(gè)服務(wù)部署的機(jī)器上編寫(xiě)配置文件，服務(wù)會(huì)向配置中心統(tǒng)一拉取配置自己的信息
　　4.當(dāng)配置發(fā)生變動(dòng)時(shí)，服務(wù)不需要重啟即可感知到配置的變化并應(yīng)用新的配置
　　5.將配置信息以REST接口的形式暴露