這個厲害了，阿里P7大佬都在看的SpringCloud 總結，幫你梳理所有知識點！

微服務

微服務架構是一種以一些微服務來替代開發單個大而全應用的方法，每個小服務運行在本身的進程裏,並以輕量級的機制來通訊, 一般是 HTTP RESTful API。微服務強調小快靈， 任何一個相對獨立的功能服務再也不是一個模塊, 而是一個獨立的服務。   微服務是一種生態，不是一種具體技術

微服務的特性

自主性（鬆耦合）

能夠對微服務架構中的每一個組件服務進行開發、部署、運營和擴展，而不影響其餘服務的功能。這些服務不須要與其餘服務共享任何代碼或實施。各個組件之間的任何通訊都是經過明肯定義的 API 進行的。

專用性

每項服務都是針對一組功能而設計的，並專一於解決特定的問題。若是開發人員逐漸將更多代碼增長到一項服務中而且這項服務變得複雜，那麼能夠將其拆分紅多項更小的服務。

靈活擴展

經過微服務，您能夠獨立擴展各項服務以知足其支持的應用程序功能的需求。這使團隊可以適當調整基礎設施需求，準確衡量功能成本，並在服務需求激增時保持可用性。

輕鬆部署

微服務支持持續集成和持續交付，能夠輕鬆嘗試新想法，並能夠在沒法正常運行時回滾。因爲故障成本較低，所以能夠大膽試驗，更輕鬆地更新代碼，並縮短新功能的上市時間。

目前微服務的發展情況

目前主流的就是springCloud和dubbo了，那麼咱們對他們作一個對比：

Dubbo

一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用、智能容錯、負載均衡，以及服務自動註冊和發現。

節點角色說明：

Provider: 暴露服務的服務提供方。 Consumer: 調用遠程服務的服務消費方。 Registry: 服務註冊與發現的註冊中心。（Dubbo種通常都是使用zookeeper做爲註冊中心） Monitor: 統計服務的調用次調和調用時間的監控中心。 Container: 服務運行容器。

調用關係說明：

服務容器負責啓動，加載，運行服務提供者。 服務提供者在啓動時，向註冊中心註冊本身提供的服務。 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

SpringCloud與Dubbo的對比

SpringCould是基於SpringBoot的基礎上的一個微服務架構。包括包服務發現（Eureka），斷路器（Hystrix），服務網關（Zuul），客戶端負載均衡（Ribbon）、服務跟蹤(Sleuth)、消息總線(Bus)、消息驅動(Stream)、批量任務(Task)等。Spring Cloud拋棄了Dubbo 的RPC通訊，採用的是基於HTTP的REST方式。   Dubbo和Spring Cloud並非徹底的競爭關係，二者所解決的問題域不同：Dubbo的定位始終是一款RPC框架，而Spring Cloud的目的是微服務架構下的一站式解決方案。

SpringCloud

服務發現——Netflix Eureka

Eureka包含兩個組件：Eureka Server和Eureka Client

Eureka Server提供服務發現能力，各個微服務啓動時會向Eureka Server註冊本身的信息（服務名、IP、端口等），Eureka Server便存儲了這個信息。功能相似於zookeeper Eureka Client 是一個Java客戶端，用於簡化與Eureka的交互。 心跳機制：每一個微服務啓動後， 會每一個必定時間（默認30s）向Eureka Server 發送心，讓其知道本身扔健康存活。若是Eureka Server在必定時間內（默認90s）沒有收到某個微服務實例的心跳，Eureka Server就會註銷該實例 Eureka集羣：默認狀況下，Eureka Server也是Eureka Client，多個Eureka Server之間經過複製方式，來實現服務註冊表中的數據同步。Eureka Client會緩存服務註冊表中的信息， 無須每次都請求Eureka Server查詢，緩解了Eureka Server的壓力；即便Eureka Server全部節點都宕機，服務消費者依然能夠查詢本身緩存中的信息找到去調用服務提供者。 自我保護機制：如果由於網絡緣由，經過心跳機制判讀該服務已死致使實例被註銷時，這是不被容許的。所以自我保護機制來解決這個問題，當EurekaServer節點短期內丟失過多客戶端（網絡緣由致使），那麼這個節點就會進入自我保護模式，一旦進入該模式，EurekaServer就會保護服務註冊表中的信息，再也不刪除服務註冊表中的數據（也就是不會註銷任何微服務）。當網絡恢復時，該EurekaServer節點會退出自我保護機制。自我保護機制使Eureka集羣更加的穩定與健壯。

CAP原則

CAP原則又稱CAP定理，指的是在一個分佈式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。CAP原則是NOSQL（Redis、mongdb）數據庫的基石。

一致性（Consistency）：在分佈式系統中的全部數據備份，在同一時刻是否一樣的值。（等同於全部節點訪問同一份最新的數據副本） 可用性（Availability）：在集羣中一部分節點故障後，集羣總體是否還能響應客戶端的讀寫請求。（對數據更新具有高可用性） 分區容錯性（Partition tolerance）：以實際效果而言，分區至關於對通訊的時限要求。系統若是不能在時限內達成數據一致性，就意味着發生了分區的狀況，必須就當前操做在C和A之間作出選擇（集羣下必需要保證P）。

CAP三個特性只能知足其中兩個：

CA without P：若是不要求P（不容許分區），則C（強一致性）和A（可用性）是能夠保證的。但放棄P的同時也就意味着放棄了系統的擴展性，也就是分佈式節點受限，沒辦法部署子節點，這是違背分佈式系統設計的初衷的。傳統的關係型數據庫RDBMS：Oracle、MySQL就是CA。

CP without A：若是不要求A（可用），至關於每一個請求都須要在服務器之間保持強一致，而P（分區）會致使同步時間無限延長(也就是等待數據同步完才能正常訪問服務)，一旦發生網絡故障或者消息丟失等狀況，就要犧牲用戶的體驗，等待全部數據所有一致了以後再讓用戶訪問系統。設計成CP的系統其實很多，最典型的就是分佈式數據庫，如Redis、HBase等。對於這些分佈式數據庫來講，數據的一致性是最基本的要求，由於若是連這個標準都達不到，那麼直接採用關係型數據庫就好，不必再浪費資源來部署分佈式數據庫。

AP wihtout C：要高可用並容許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，爲了高可用，每一個節點只能用本地數據提供服務，而這樣會致使全局數據的不一致性。典型的應用就如某米的搶購手機場景，可能前幾秒你瀏覽商品的時候頁面提示是有庫存的，當你選擇完商品準備下單的時候，系統提示你下單失敗，商品已售完。這其實就是先在 A（可用性）方面保證系統能夠正常的服務，而後在數據的一致性方面作了些犧牲，雖然多少會影響一些用戶體驗，但也不至於形成用戶購物流程的嚴重阻塞。

zookeeper和Eureka

zookeeper保證的是CP zookeeper存在的問題：當master掛掉的時候會經過選舉產生新的master，可是因爲在選舉期間集羣不可用且選舉時間過長致使服務長期不可用。 Eureka保證的是AP Eureka因爲保證的是可用性，所以不會出現上面那種狀況。由於Eureka的每一個節點都是平等的，掛掉幾個節點不會影響總體的工做，當某個Eurek的客戶端註冊失敗的時候會自動切換到其餘節點進行註冊，只要是還有一臺存活就闊以保證可用性，只不過查詢到的數據不是最新的。    所以Eureka能夠很好的應對由於網絡故障致使節點丟失的狀況，而不是像zookeeper那樣使整個註冊服務癱瘓的狀況。

客服端負載均衡——Netflix Ribbon

Ribbon工做原理 ribbon實現的關鍵點是爲ribbon定製的RestTemplate，ribbon利用了RestTemplate的攔截器機制，在攔截器中實現ribbon的負載均衡。負載均衡的基本實現就是利用applicationName從服務註冊中心獲取可用的服務地址列表，而後經過必定算法負載，決定使用哪個服務地址來進行http調用。

負載均衡分類

集中式LoadBalance 在消費者和提供者之間使用獨立的LoadBanlance設備，如Nginx（反向代理服務器）。由該設備將訪問親求分發到提供者。 進程式LoadBalance 將LoadBanlance的邏輯整合到消費者，消費者從註冊中心獲取可用的地址，而後本身經過策略選擇合適的服務器。Ribbon就是典型的進程式。

負載均衡算法

隨機負載均衡（默認）：隨機選擇狀態爲UP的Server 簡單輪詢負載均衡：以輪詢的方式依次將請求調度不一樣的服務器 加權響應時間負載均衡：根據響應時間分配一個weight，響應時間越長，weight越小，被選中的可能性越低 區域感知輪詢負載均衡：複合判斷server所在區域的性能和server的可用性選擇server

斷路器——Netflix Hystrix

Hystrix爲分佈式系統的延遲和故障提供強大的容錯能力。 當一個節點出問題的時候，hystrix保證了總體不會失敗，提升了分佈式系統的彈性

服務熔斷

微服務架構中某個微服務發生故障時，要快速切斷服務，提示用戶，後續請求，不調用該服務，直接返回，釋放資源，這就是服務熔斷。 熔斷生效後，會在指定的時間後調用請求來測試依賴是否恢復，依賴的應用恢復後關閉熔斷。

服務降級

服務器高併發下，壓力劇增的時候,根據當業務狀況以及流量，對一些服務和頁面有策略的降級(能夠理解爲關閉沒必要要的服務)，以此緩解服務器資源的壓力以保障核心任務的正常運行。 雙十一期間，支付寶不少功能都會提示，[雙十一期間，保障核心交易，某某服務數據延遲]。

服務網關——Netflix Zuul

網關：系統惟一對外的入口，介於客戶端與服務器端之間，用於對請求進行鑑權、限流、 路由、監控等功能。

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

路由功能負責將外部請求轉發到具體的微服務實例上，是實現外部訪問統一入口的基礎。 過濾功能則負責對請求的處理過程進行干預，是實現請求校驗、鑑權等處理   Zuul和Eureka進行整合，將Zuul自身註冊爲Eureka服務治理下的應用，同時從Eureka中得到其餘微服務的消息，也即之後的訪問微服務都是經過Zuul跳轉後得到。   注意：Zuul服務最終仍是會註冊進Eureka

通俗點就是統一了訪問地址

分佈式配置——Spring Cloud Config

在分佈式系統中，因爲服務數量巨多，爲了方便服務配置文件統一管理，實時更新，因此須要分佈式配置中心組件。在Spring Cloud中，有分佈式配置中心組件spring cloud config ，它支持配置服務放在配置服務的內存中（即本地），也支持放在遠程Git倉庫中。在spring cloud config 組件中，分兩個角色，一是config server，二是config client。server提供配置文件的存儲、以接口的形式將配置文件的內容提供出去，client經過接口獲取數據、並依據此數據初始化本身的應用。

最後

你們看完有什麼不懂的能夠在下方留言討論，也能夠關注我私信問我，我看到後都會回答的。也歡迎你們關注個人公衆號：前程有光，金三銀四跳槽面試季，整理了1000多道將近500多頁pdf文檔的Java面試題資料，文章都會在裏面更新，整理的資料也會放在裏面。謝謝你的觀看，以爲文章對你有幫助的話記得關注我點個贊支持一下！