微服務(wù)

微服務(wù)架構(gòu)是一種以一些微服務(wù)來替代開發(fā)單個(gè)大而全應(yīng)用的方法，每一個(gè)小服務(wù)運(yùn)行在自己的進(jìn)程里,并以輕量級(jí)的機(jī)制來通信, 通常是 HTTP RESTful API。微服務(wù)強(qiáng)調(diào)小快靈， 任何一個(gè)相對(duì)獨(dú)立的功能服務(wù)不再是一個(gè)模塊, 而是一個(gè)獨(dú)立的服務(wù)。
??微服務(wù)是一種生態(tài)，不是一種具體技術(shù)

微服務(wù)的特性

自主性（松耦合）

可以對(duì)微服務(wù)架構(gòu)中的每個(gè)組件服務(wù)進(jìn)行開發(fā)、部署、運(yùn)營(yíng)和擴(kuò)展，而不影響其他服務(wù)的功能。這些服務(wù)不需要與其他服務(wù)共享任何代碼或?qū)嵤?。各個(gè)組件之間的任何通信都是通過明確定義的 API 進(jìn)行的。

專用性

每項(xiàng)服務(wù)都是針對(duì)一組功能而設(shè)計(jì)的，并專注于解決特定的問題。如果開發(fā)人員逐漸將更多代碼增加到一項(xiàng)服務(wù)中并且這項(xiàng)服務(wù)變得復(fù)雜，那么可以將其拆分成多項(xiàng)更小的服務(wù)。

靈活擴(kuò)展

通過微服務(wù)，您可以獨(dú)立擴(kuò)展各項(xiàng)服務(wù)以滿足其支持的應(yīng)用程序功能的需求。這使團(tuán)隊(duì)能夠適當(dāng)調(diào)整基礎(chǔ)設(shè)施需求，準(zhǔn)確衡量功能成本，并在服務(wù)需求激增時(shí)保持可用性。

輕松部署

微服務(wù)支持持續(xù)集成和持續(xù)交付，可以輕松嘗試新想法，并可以在無(wú)法正常運(yùn)行時(shí)回滾。由于故障成本較低，因此可以大膽試驗(yàn)，更輕松地更新代碼，并縮短新功能的上市時(shí)間。

目前微服務(wù)的發(fā)展?fàn)顩r

目前主流的就是springCloud和dubbo了，那么我們對(duì)他們做一個(gè)對(duì)比：

Dubbo

一款高性能、輕量級(jí)的開源Java RPC框架，它提供了三大核心能力：面向接口的遠(yuǎn)程方法調(diào)用、智能容錯(cuò)、負(fù)載均衡，以及服務(wù)自動(dòng)注冊(cè)和發(fā)現(xiàn)。

節(jié)點(diǎn)角色說明：

Provider: 暴露服務(wù)的服務(wù)提供方。
Consumer: 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
Registry: 服務(wù)注冊(cè)與發(fā)現(xiàn)的注冊(cè)中心。（Dubbo種一般都是使用zookeeper作為注冊(cè)中心）
Monitor: 統(tǒng)計(jì)服務(wù)的調(diào)用次調(diào)和調(diào)用時(shí)間的監(jiān)控中心。
Container: 服務(wù)運(yùn)行容器。

調(diào)用關(guān)系說明：

服務(wù)容器負(fù)責(zé)啟動(dòng)，加載，運(yùn)行服務(wù)提供者。
服務(wù)提供者在啟動(dòng)時(shí)，向注冊(cè)中心注冊(cè)自己提供的服務(wù)。
服務(wù)消費(fèi)者在啟動(dòng)時(shí)，向注冊(cè)中心訂閱自己所需的服務(wù)。
注冊(cè)中心返回服務(wù)提供者地址列表給消費(fèi)者，如果有變更，注冊(cè)中心將基于長(zhǎng)連接推送變更數(shù)據(jù)給消費(fèi)者。
服務(wù)消費(fèi)者，從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺(tái)提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另一臺(tái)調(diào)用。
服務(wù)消費(fèi)者和提供者，在內(nèi)存中累計(jì)調(diào)用次數(shù)和調(diào)用時(shí)間，定時(shí)每分鐘發(fā)送一次統(tǒng)計(jì)數(shù)據(jù)到監(jiān)控中心。

SpringCloud與Dubbo的對(duì)比

SpringCould是基于SpringBoot的基礎(chǔ)上的一個(gè)微服務(wù)架構(gòu)。包括包服務(wù)發(fā)現(xiàn)（Eureka），斷路器（Hystrix），服務(wù)網(wǎng)關(guān)（Zuul），客戶端負(fù)載均衡（Ribbon）、服務(wù)跟蹤(Sleuth)、消息總線(Bus)、消息驅(qū)動(dòng)(Stream)、批量任務(wù)(Task)等。Spring Cloud拋棄了Dubbo 的RPC通信，采用的是基于HTTP的REST方式。
??Dubbo和Spring Cloud并不是完全的競(jìng)爭(zhēng)關(guān)系，兩者所解決的問題域不一樣：Dubbo的定位始終是一款RPC框架，而Spring Cloud的目的是微服務(wù)架構(gòu)下的一站式解決方案。

SpringCloud

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

Eureka包含兩個(gè)組件：Eureka Server和Eureka Client

Eureka Server提供服務(wù)發(fā)現(xiàn)能力，各個(gè)微服務(wù)啟動(dòng)時(shí)會(huì)向Eureka Server注冊(cè)自己的信息（服務(wù)名、IP、端口等），Eureka Server便存儲(chǔ)了這個(gè)信息。功能類似于zookeeper
Eureka Client 是一個(gè)Java客戶端，用于簡(jiǎn)化與Eureka的交互。
心跳機(jī)制：每個(gè)微服務(wù)啟動(dòng)后， 會(huì)每個(gè)一定時(shí)間（默認(rèn)30s）向Eureka Server 發(fā)送心，讓其知道自己扔健康存活。如果Eureka Server在一定時(shí)間內(nèi)（默認(rèn)90s）沒有收到某個(gè)微服務(wù)實(shí)例的心跳，Eureka Server就會(huì)注銷該實(shí)例
Eureka集群：默認(rèn)情況下，Eureka Server也是Eureka Client，多個(gè)Eureka Server之間通過復(fù)制方式，來實(shí)現(xiàn)服務(wù)注冊(cè)表中的數(shù)據(jù)同步。Eureka Client會(huì)緩存服務(wù)注冊(cè)表中的信息， 無(wú)須每次都請(qǐng)求Eureka Server查詢，緩解了Eureka Server的壓力；即使Eureka Server所有節(jié)點(diǎn)都宕機(jī)，服務(wù)消費(fèi)者依然可以查詢自己緩存中的信息找到去調(diào)用服務(wù)提供者。
自我保護(hù)機(jī)制：若是因?yàn)榫W(wǎng)絡(luò)原因，通過心跳機(jī)制判讀該服務(wù)已死導(dǎo)致實(shí)例被注銷時(shí)，這是不被允許的。因此自我保護(hù)機(jī)制來解決這個(gè)問題，當(dāng)EurekaServer節(jié)點(diǎn)短時(shí)間內(nèi)丟失過多客戶端（網(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ù)時(shí)，該EurekaServer節(jié)點(diǎn)會(huì)退出自我保護(hù)機(jī)制。自我保護(hù)機(jī)制使Eureka集群更加的穩(wěn)定與健壯。

CAP原則

CAP原則又稱CAP定理，指的是在一個(gè)分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可得兼。CAP原則是NOSQL（Redis、mongdb）數(shù)據(jù)庫(kù)的基石。

一致性（Consistency）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否同樣的值。（等同于所有節(jié)點(diǎn)訪問同一份最新的數(shù)據(jù)副本）
可用性（Availability）：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請(qǐng)求。（對(duì)數(shù)據(jù)更新具備高可用性）
分區(qū)容錯(cuò)性（Partition tolerance）：以實(shí)際效果而言，分區(qū)相當(dāng)于對(duì)通信的時(shí)限要求。系統(tǒng)如果不能在時(shí)限內(nèi)達(dá)成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當(dāng)前操作在C和A之間做出選擇（集群下必須要保證P）。

CAP三個(gè)特性只能滿足其中兩個(gè)：

CA without P：如果不要求P（不允許分區(qū)），則C（強(qiáng)一致性）和A（可用性）是可以保證的。但放棄P的同時(shí)也就意味著放棄了系統(tǒng)的擴(kuò)展性，也就是分布式節(jié)點(diǎn)受限，沒辦法部署子節(jié)點(diǎn)，這是違背分布式系統(tǒng)設(shè)計(jì)的初衷的。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)RDBMS：Oracle、MySQL就是CA。

CP without A：如果不要求A（可用），相當(dāng)于每個(gè)請(qǐng)求都需要在服務(wù)器之間保持強(qiáng)一致，而P（分區(qū)）會(huì)導(dǎo)致同步時(shí)間無(wú)限延長(zhǎng)(也就是等待數(shù)據(jù)同步完才能正常訪問服務(wù))，一旦發(fā)生網(wǎng)絡(luò)故障或者消息丟失等情況，就要犧牲用戶的體驗(yàn)，等待所有數(shù)據(jù)全部一致了之后再讓用戶訪問系統(tǒng)。設(shè)計(jì)成CP的系統(tǒng)其實(shí)不少，最典型的就是分布式數(shù)據(jù)庫(kù)，如Redis、HBase等。對(duì)于這些分布式數(shù)據(jù)庫(kù)來說，數(shù)據(jù)的一致性是最基本的要求，因?yàn)槿绻B這個(gè)標(biāo)準(zhǔn)都達(dá)不到，那么直接采用關(guān)系型數(shù)據(jù)庫(kù)就好，沒必要再浪費(fèi)資源來部署分布式數(shù)據(jù)庫(kù)。

AP wihtout C：要高可用并允許分區(qū)，則需放棄一致性。一旦分區(qū)發(fā)生，節(jié)點(diǎn)之間可能會(huì)失去聯(lián)系，為了高可用，每個(gè)節(jié)點(diǎn)只能用本地?cái)?shù)據(jù)提供服務(wù)，而這樣會(huì)導(dǎo)致全局?jǐn)?shù)據(jù)的不一致性。典型的應(yīng)用就如某米的搶購(gòu)手機(jī)場(chǎng)景，可能前幾秒你瀏覽商品的時(shí)候頁(yè)面提示是有庫(kù)存的，當(dāng)你選擇完商品準(zhǔn)備下單的時(shí)候，系統(tǒng)提示你下單失敗，商品已售完。這其實(shí)就是先在 A（可用性）方面保證系統(tǒng)可以正常的服務(wù)，然后在數(shù)據(jù)的一致性方面做了些犧牲，雖然多少會(huì)影響一些用戶體驗(yàn)，但也不至于造成用戶購(gòu)物流程的嚴(yán)重阻塞。

zookeeper和Eureka

zookeeper保證的是CP
zookeeper存在的問題：當(dāng)master掛掉的時(shí)候會(huì)通過選舉產(chǎn)生新的master，但是由于在選舉期間集群不可用且選舉時(shí)間過長(zhǎng)導(dǎo)致服務(wù)長(zhǎng)期不可用。
Eureka保證的是AP
Eureka由于保證的是可用性，因此不會(huì)出現(xiàn)上面那種情況。因?yàn)镋ureka的每個(gè)節(jié)點(diǎn)都是平等的，掛掉幾個(gè)節(jié)點(diǎn)不會(huì)影響整體的工作，當(dāng)某個(gè)Eurek的客戶端注冊(cè)失敗的時(shí)候會(huì)自動(dòng)切換到其他節(jié)點(diǎn)進(jìn)行注冊(cè)，只要是還有一臺(tái)存活就闊以保證可用性，只不過查詢到的數(shù)據(jù)不是最新的。
?? 因此Eureka可以很好的應(yīng)對(duì)因?yàn)榫W(wǎng)絡(luò)故障導(dǎo)致節(jié)點(diǎn)丟失的情況，而不是像zookeeper那樣使整個(gè)注冊(cè)服務(wù)癱瘓的情況。

客服端負(fù)載均衡——Netflix Ribbon

Ribbon工作原理
ribbon實(shí)現(xiàn)的關(guān)鍵點(diǎn)是為ribbon定制的RestTemplate，ribbon利用了RestTemplate的攔截器機(jī)制，在攔截器中實(shí)現(xiàn)ribbon的負(fù)載均衡。負(fù)載均衡的基本實(shí)現(xiàn)就是利用applicationName從服務(wù)注冊(cè)中心獲取可用的服務(wù)地址列表，然后通過一定算法負(fù)載，決定使用哪一個(gè)服務(wù)地址來進(jìn)行http調(diào)用。

負(fù)載均衡分類

集中式LoadBalance
在消費(fèi)者和提供者之間使用獨(dú)立的LoadBanlance設(shè)備，如Nginx（反向代理服務(wù)器）。由該設(shè)備將訪問親求分發(fā)到提供者。
進(jìn)程式LoadBalance
將LoadBanlance的邏輯整合到消費(fèi)者，消費(fèi)者從注冊(cè)中心獲取可用的地址，然后自己通過策略選擇合適的服務(wù)器。Ribbon就是典型的進(jìn)程式。

負(fù)載均衡算法

隨機(jī)負(fù)載均衡（默認(rèn)）：隨機(jī)選擇狀態(tài)為UP的Server
簡(jiǎn)單輪詢負(fù)載均衡：以輪詢的方式依次將請(qǐng)求調(diào)度不同的服務(wù)器
加權(quán)響應(yīng)時(shí)間負(fù)載均衡：根據(jù)響應(yīng)時(shí)間分配一個(gè)weight，響應(yīng)時(shí)間越長(zhǎng)，weight越小，被選中的可能性越低
區(qū)域感知輪詢負(fù)載均衡：復(fù)合判斷server所在區(qū)域的性能和server的可用性選擇server

斷路器——Netflix Hystrix

Hystrix為分布式系統(tǒng)的延遲和故障提供強(qiáng)大的容錯(cuò)能力。 當(dāng)一個(gè)節(jié)點(diǎn)出問題的時(shí)候，hystrix保證了整體不會(huì)失敗，提高了分布式系統(tǒng)的彈性

服務(wù)熔斷

微服務(wù)架構(gòu)中某個(gè)微服務(wù)發(fā)生故障時(shí)，要快速切斷服務(wù)，提示用戶，后續(xù)請(qǐng)求，不調(diào)用該服務(wù)，直接返回，釋放資源，這就是服務(wù)熔斷。
熔斷生效后，會(huì)在指定的時(shí)間后調(diào)用請(qǐng)求來測(cè)試依賴是否恢復(fù)，依賴的應(yīng)用恢復(fù)后關(guān)閉熔斷。

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

服務(wù)器高并發(fā)下，壓力劇增的時(shí)候,根據(jù)當(dāng)業(yè)務(wù)情況以及流量，對(duì)一些服務(wù)和頁(yè)面有策略的降級(jí)(可以理解為關(guān)閉不必要的服務(wù))，以此緩解服務(wù)器資源的壓力以保障核心任務(wù)的正常運(yùn)行。
雙十一期間，支付寶很多功能都會(huì)提示，[雙十一期間，保障核心交易，某某服務(wù)數(shù)據(jù)延遲]。

服務(wù)網(wǎng)關(guān)——Netflix Zuul

網(wǎng)關(guān)：系統(tǒng)唯一對(duì)外的入口，介于客戶端與服務(wù)器端之間，用于對(duì)請(qǐng)求進(jìn)行鑒權(quán)、限流、 路由、監(jiān)控等功能。

zuul提供了兩個(gè)主要功能：路由和過濾

路由功能負(fù)責(zé)將外部請(qǐng)求轉(zhuǎn)發(fā)到具體的微服務(wù)實(shí)例上，是實(shí)現(xiàn)外部訪問統(tǒng)一入口的基礎(chǔ)。
過濾功能則負(fù)責(zé)對(duì)請(qǐng)求的處理過程進(jìn)行干預(yù)，是實(shí)現(xiàn)請(qǐng)求校驗(yàn)、鑒權(quán)等處理
??Zuul和Eureka進(jìn)行整合，將Zuul自身注冊(cè)為Eureka服務(wù)治理下的應(yīng)用，同時(shí)從Eureka中獲得其他微服務(wù)的消息，也即以后的訪問微服務(wù)都是通過Zuul跳轉(zhuǎn)后獲得。
??注意：Zuul服務(wù)最終還是會(huì)注冊(cè)進(jìn)Eureka

通俗點(diǎn)就是統(tǒng)一了訪問地址

分布式配置——Spring Cloud Config

在分布式系統(tǒng)中，由于服務(wù)數(shù)量巨多，為了方便服務(wù)配置文件統(tǒng)一管理，實(shí)時(shí)更新，所以需要分布式配置中心組件。在Spring Cloud中，有分布式配置中心組件spring cloud config ，它支持配置服務(wù)放在配置服務(wù)的內(nèi)存中（即本地），也支持放在遠(yuǎn)程Git倉(cāng)庫(kù)中。在spring cloud config 組件中，分兩個(gè)角色，一是config server，二是config client。server提供配置文件的存儲(chǔ)、以接口的形式將配置文件的內(nèi)容提供出去，client通過接口獲取數(shù)據(jù)、并依據(jù)此數(shù)據(jù)初始化自己的應(yīng)用。

最后

感謝你看到這里，看完有什么的不懂的可以在評(píng)論區(qū)問我，覺得文章對(duì)你有幫助的話記得給我點(diǎn)個(gè)贊，每天都會(huì)分享java相關(guān)技術(shù)文章或行業(yè)資訊，歡迎大家關(guān)注和轉(zhuǎn)發(fā)文章！