全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

軟件是有生命的,你作出來的架構決定了這個軟件它這一輩子是坎坷仍是幸福。前端

本文不是講解如何使用Spring Cloud的教程,而是探討Spring Cloud是什麼,以及它誕生的背景和意義。java

1、背景

2008年之後,國內互聯網行業飛速發展,咱們對軟件系統的需求已經再也不是過去」能用就行」這種很low的檔次了,像搶紅包、雙十一這樣的活動不斷逼迫咱們去突破軟件系統的性能上限,傳統的IT企業」能用就行」的開發思想已經不能知足互聯網高併發、大流量的性能要求。系統架構走向分佈式已是服務器開發領域解決該問題惟一的出路,然而分佈式系統因爲天生的複雜度,並不像開發單體應用同樣把框架一堆就能搞定,所以各大互聯網公司都在投入技術力量研發本身的基礎設施。這裏面比較有名的如阿里的開源項目dubbo, Netflix開發的一系列服務框架。在這種「百花齊放」、重複造輪子的情況下,必然要出現一種統一的標準來簡化分佈式系統的開發,Spring Cloud應運而生。git

2、Spring Cloud是什麼

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發,如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等,均可以用Spring Boot的開發風格作到一鍵啓動和部署。Spring並無重複製造輪子,它只是將目前各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來,經過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理,最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。
Spring Cloud正是對Netflix的多個開源組件進一步的封裝而成,同時又實現了和雲端平臺,和Spring Boot開發框架很好的集成。
Spring Cloud是一個相對比較新的微服務框架,2016年才推出1.0的release版本. 雖然Spring Cloud時間最短, 可是相比Dubbo等RPC框架, Spring Cloud提供的全套的分佈式系統解決方案
Spring Cloud 爲開發者提供了在分佈式系統(配置管理,服務發現,熔斷,路由,微代理,控制總線,一次性token,全居瑣,leader選舉,分佈式session,集羣狀態)中快速構建的工具,使用Spring Cloud的開發者能夠快速的啓動服務或構建應用、同時可以快速和雲平臺資源進行對接。算法

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

從上圖能夠看出Spring Cloud各個組件相互配合,合做支持了一套完整的微服務架構。spring

  • 其中Eureka負責服務的註冊與發現,很好將各服務鏈接起來
  • Hystrix 負責監控服務之間的調用狀況,連續屢次失敗進行熔斷保護。
  • Hystrix dashboard,Turbine 負責監控 Hystrix的熔斷狀況,並給予圖形化的展現
  • Spring Cloud Config 提供了統一的配置中心服務
  • 當配置文件發生變化的時候,Spring Cloud Bus 負責通知各服務去獲取最新的配置信息
  • 全部對外的請求和服務,咱們都經過Zuul來進行轉發,起到API網關的做用
  • 最後咱們使用Sleuth+Zipkin將全部的請求數據記錄下來,方便咱們進行後續分析

Spring Cloud從設計之初就考慮了絕大多數互聯網公司架構演化所需的功能,如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等。這些功能都是以插拔的形式提供出來,方便咱們系統架構演進的過程當中,能夠合理的選擇須要的組件進行集成,從而在架構演進的過程當中會更加平滑、順利。docker

微服務架構是一種趨勢,Spring Cloud提供了標準化的、全站式的技術方案,意義可能會堪比當前Servlet規範的誕生,有效推動服務端軟件系統技術水平的進步。數據庫

3、Spring Cloud組成

Spring Cloud的子項目,大體可分紅兩類,一類是對現有成熟框架」Spring Boot化」的封裝和抽象,也是數量最多的項目;第二類是開發了一部分分佈式系統的基礎設施的實現,如Spring Cloud Stream扮演的就是kafka, ActiveMQ這樣的角色。對於咱們想快速實踐微服務的開發者來講,第一類子項目就已經足夠使用,如:Spring Cloud Netflix,是對Netflix開發的一套分佈式服務框架的封裝,包括服務的發現和註冊,負載均衡、斷路器、REST客戶端、請求路由等。該項目是Spring Cloud的子項目之一,主要內容是對Netflix公司一系列開源產品的包裝,它爲Spring Boot應用提供了自配置的Netflix OSS整合。
經過一些簡單的註解,開發者就能夠快速的在應用中配置一下經常使用模塊並構建龐大的分佈式系統。它主要提供的模塊包括:服務發現(Eureka),斷路器(Hystrix),智能路由(Zuul),客戶端負載均衡(Ribbon)等。編程

Spring Cloud Netflix
這但是個大boss,地位僅次於老大,老大各項服務依賴與它,與各類Netflix OSS組件集成,組成微服務的核心,它的小弟主要有Eureka, Hystrix, Zuul, Archaius... 太多了後端

3.一、Spring Cloud Eureka 服務發現安全

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

服務中心,雲端服務發現,一個基於 REST 的服務,用於定位服務,以實現雲端中間層服務發現和故障轉移。這個但是SpringCloud最牛鼻的小弟,服務中心,任何小弟須要其它小弟支持什麼都須要從這裏來拿,一樣的你有什麼獨門武功的都趕忙過報道,方便之後其它小弟來調用;它的好處是你不須要直接找各類什麼小弟支持,只須要到服務中心來領取,也不須要知道提供支持的其它小弟在哪裏,仍是幾個小弟來支持的,反正拿來用就行,服務中心來保證穩定性和質量。
Spring Cloud Eureka提供在分佈式環境下的服務發現,服務註冊的功能。
一個RESTful服務,用來定位運行在AWS地區(Region)中的中間層服務。由兩個組件組成:Eureka服務器和Eureka客戶端。Eureka服務器用做服務註冊服務器。Eureka客戶端是一個java客戶端,用來簡化與服務器的交互、做爲輪詢負載均衡器,並提供服務的故障切換支持。Netflix在其生產環境中使用的是另外的客戶端,它提供基於流量、資源利用率以及出錯狀態的加權負載均衡。

3.二、Spring Cloud Ribbon 客戶端負載均衡

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Ribbon,主要提供客戶側的軟件負載均衡算法。
Ribbon客戶端組件提供一系列完善的配置選項,好比鏈接超時、重試、重試算法等。Ribbon內置可插拔、可定製的負載均衡組件。下面是用到的一些負載均衡策略

  • 簡單輪詢負載均衡
  • 加權響應時間負載均衡
  • 區域感知輪詢負載均衡
  • 隨機負載均衡

Ribbon中還包括如下功能:

  • 易於與服務發現組件(好比Netflix的Eureka)集成
  • 使用Archaius完成運行時配置
  • 使用JMX暴露運維指標,使用Servo發佈
  • 多種可插拔的序列化選擇
  • 異步和批處理操做(即將推出)
  • 自動SLA框架(即將推出)
  • 系統管理/指標控制檯(即將推出)

ribbon架構示例

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

  • 一個服務註冊中心,eureka server,端口爲8761
  • service-hi工程跑了兩個實例,端口分別爲8762,8763,分別向服務註冊中心註冊
  • sercvice-ribbon端口爲8764,向服務註冊中心註冊
  • 當sercvice-ribbon經過restTemplate調用service-hi的hi接口時,由於用ribbon進行了負載均衡,會輪流的調用service-hi:8762和8763 兩個端口的hi接口;

3.三、Spring Cloud Config

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

俗稱的配置中心,配置管理工具包,讓你能夠把配置放到遠程服務器,集中化管理集羣配置,目前支持本地存儲、Git以及Subversion。就是之後你們武器、槍火什麼的東西都集中放到一塊兒,別隨便本身帶,方便之後統一管理、升級裝備。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

將配置信息中央化保存, 配置Spring Cloud Bus能夠實現動態修改配置文件。這個仍是靜態的,得配合Spring Cloud Bus實現動態的配置更新。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Spring Cloud Config就是咱們一般意義上的配置中心。Spring Cloud Config-把應用本來放在本地文件的配置抽取出來放在中心服務器,本質是配置信息從本地遷移到雲端。從而可以提供更好的管理、發佈能力。
Spring Cloud Config分服務端和客戶端,服務端負責將git(svn)中存儲的配置文件發佈成REST接口,客戶端能夠從服務端REST接口獲取配置。但客戶端並不能主動感知到配置的變化,從而主動去獲取新的配置,這須要每一個客戶端經過POST方法觸發各自的/refresh。

3.四、Spring cloud Hystrix 熔斷器

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

熔斷器,容錯管理工具,旨在經過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。好比忽然某個小弟生病了,可是你還須要它的支持,而後調用以後它半天沒有響應,你殊不知道,一直在等等這個響應;有可能別的小弟也正在調用你的武功絕技,那麼當請求多以後,就會發生嚴重的阻塞影響老大的總體計劃。這個時候Hystrix就派上用場了,當Hystrix發現某個小弟不在狀態不穩定立馬立刻讓它下線,讓其它小弟來頂上來,或者給你說不用等了這個小弟今天確定不行,該幹嗎趕忙幹嗎去別在這排隊了。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

斷路器(Cricuit Breaker)是一種可以在遠程服務不可用時自動熔斷(打開開關),並在遠程服務恢復時自動恢復(閉合開關)的設施,Spring Cloud經過Netflix的Hystrix組件提供斷路器、資源隔離與自我修復功能。

斷路器能夠防止一個應用程序屢次試圖執行一個操做,即極可能失敗,容許它繼續而不等待故障恢復或者浪費 CPU 週期,而它肯定該故障是持久的。斷路器模式也使應用程序可以檢測故障是否已經解決。若是問題彷佛已經獲得糾正​​,應用程序能夠嘗試調用操做。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

斷路器增長了穩定性和靈活性,以一個系統,提供穩定性,而系統從故障中恢復,並儘可能減小此故障的對性能的影響。它能夠幫助快速地拒絕對一個操做,即極可能失敗,而不是等待操做超時(或者不返回)的請求,以保持系統的響應時間。若是斷路器提升每次改變狀態的時間的事件,該信息能夠被用來監測由斷路器保護系統的部件的健康情況,或以提醒管理員當斷路器跳閘,以在打開狀態。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Netflix開源了Hystrix組件,實現了斷路器模式,SpringCloud對這一組件進行了整合。 在微服務架構中,一個請求須要調用多個服務是很是常見的,以下圖:

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

較底層的服務若是出現故障,會致使連鎖故障。當對特定的服務的調用的不可用達到一個閥值(Hystric 是5秒20次) 斷路器將會被打開。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

斷路打開後,可用避免連鎖故障,fallback方法能夠直接返回一個固定值

在微服務架構中一般會有多個服務層調用,基礎服務的故障可能會致使級聯故障,進而形成整個系統不可用的狀況,這種現象被稱爲服務雪崩效應。服務雪崩效應是一種因「服務提供者」的不可用致使「服務消費者」的不可用,並將不可用逐漸放大的過程。

以下圖所示:A做爲服務提供者,B爲A的服務消費者,C和D是B的服務消費者。A不可用引發了B的不可用,並將不可用像滾雪球同樣放大到C和D時,雪崩效應就造成了。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

在這種狀況下就須要整個服務機構具備故障隔離的功能,避免某一個服務掛掉影響全局。在Spring Cloud 中Hystrix組件就扮演這個角色
Hystrix會在某個服務連續調用N次不響應的狀況下,當即通知調用端調用失敗,避免調用端持續等待而影響了總體服務。Hystrix間隔時間會再次檢查此服務,若是服務恢復將繼續提供服務。

Hystrix Dashboard和Turbine
當熔斷髮生的時候須要迅速的響應來解決問題,避免故障進一步擴散,那麼對熔斷的監控就變得很是重要。熔斷的監控如今有兩款工具:Hystrix-dashboardTurbine

Hystrix-dashboard是一款針對Hystrix進行實時監控的工具,經過Hystrix Dashboard咱們能夠直觀地看到各Hystrix Command的請求響應時間, 請求成功率等數據。可是隻使用Hystrix Dashboard的話, 你只能看到單個應用內的服務信息, 這明顯不夠. 咱們須要一個工具能讓咱們彙總系統內多個服務的數據並顯示到Hystrix Dashboard上, 這個工具就是Turbine. 監控的效果圖以下:

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

3.五、Spring Cloud Zuul 服務網關,智能路由

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

在微服務架構模式下,後端服務的實例數通常是動態的,對於客戶端而言很難發現動態改變的服務實例的訪問地址信息。所以在基於微服務的項目中爲了簡化前端的調用邏輯,一般會引入API Gateway做爲輕量級網關,同時API Gateway中也會實現相關的認證邏輯從而簡化內部服務之間相互調用的複雜度。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Spring Cloud體系中支持API Gateway落地的技術就是Zuul。Spring Cloud Zuul路由是微服務架構中不可或缺的一部分,提供動態路由,監控,彈性,安全等的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。

它的具體做用就是服務轉發,接收並轉發全部內外部的客戶端調用。使用Zuul能夠做爲資源的統一訪問入口,同時也能夠在網關作一些權限校驗等相似的功能

Zuul 是在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 至關因而設備和 Netflix 流應用的 Web 網站後端全部請求的前門。當其它門派來找大哥辦事的時候必定要先通過zuul,看下有沒有帶刀子什麼的給攔截回去,或者是須要找那個小弟的直接給帶過去。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

相似Nginx,反向代理的功能,不過netflix本身增長了一些配合其餘組件的特性。

3.六、Spring Netflix Archaius

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

配置管理API,包含一系列配置管理API,提供動態類型化屬性、線程安全配置操做、輪詢框架、回調機制等功能。能夠實現動態獲取配置,
原理是每隔60s(默認,可配置)從配置源讀取一次內容,這樣修改了配置文件後不須要重啓服務就可使修改後的內容生效,前提使用archaius的API來讀取。

3.七、Spring Cloud Bus

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

事件、消息總線,用於在集羣(例如,配置變化事件)中傳播狀態變化,可與Spring Cloud Config聯合實現熱部署。至關於水滸傳中日行八百里的神行太保戴宗,確保各個小弟之間消息保持暢通。

分佈式消息隊列,是對Kafka, MQ的封裝;事件、消息總線,用於在集羣(例如,配置變化事件)中傳播狀態變化,可與Spring Cloud Config聯合實現熱部署
Spring cloud bus經過輕量消息代理鏈接各個分佈的節點。這會用在廣播狀態的變化(例如配置變化)或者其餘的消息指令。Spring bus的一個核心思想是經過分佈式的啓動器對spring boot應用進行擴展,也能夠用來創建一個多個應用之間的通訊頻道。目前惟一實現的方式是用AMQP消息代理做爲通道,一樣特性的設置(有些取決於通道的設置)在更多通道的文檔中。
Spring cloud bus被國內不少都翻譯爲消息總線,也挺形象的。你們能夠將它理解爲管理和傳播全部分佈式項目中的消息既可,其實本質是利用了MQ的廣播機制在分佈式的系統中傳播消息,目前經常使用的有Kafka和RabbitMQ。利用bus的機制能夠作不少的事情,其中配置中心客戶端刷新就是典型的應用場景之一,咱們用一張圖來描述bus在配置中心使用的機制。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

根據此圖咱們能夠看出利用Spring Cloud Bus作配置更新的步驟:

  1. 提交代碼觸發post給客戶端A發送bus/refresh
  2. 客戶端A接收到請求從Server端更新配置而且發送給Spring Cloud Bus
  3. Spring Cloud bus接到消息並通知給其它客戶端
  4. 其它客戶端接收到通知,請求Server端獲取最新配置
  5. 所有客戶端均獲取到最新的配置

3.8 Spring Cloud Security

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

對Spring Security的封裝,並能配合Netflix使用,安全工具包,爲你的應用程序添加安全控制,主要是指OAuth2
基於spring security的安全工具包,爲你的應用程序添加安全控制。這個小弟很牛鼻專門負責整個幫派的安全問題,設置不一樣的門派訪問特定的資源,不能把祕籍葵花寶典泄漏了。

3.九、Spring Cloud Zookeeper

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

對Zookeeper的封裝,使之能配置其它Spring Cloud的子項目使用;操做Zookeeper的工具包,用於使用zookeeper方式的服務註冊和發現
ZooKeeper是一個分佈式的,開放源碼的分佈式應用程序協調服務,是Google的Chubby一個開源的實現,是Hadoop和Hbase的重要組件。它是一個爲分佈式應用提供一致性服務的軟件,提供的功能包括:配置維護、域名服務、分佈式同步、組服務等。ZooKeeper的目標就是封裝好複雜易出錯的關鍵服務,將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
操做Zookeeper的工具包,用於使用zookeeper方式的服務發現和配置管理,抱了Zookeeper的大腿。

3.十、Spring Cloud Stream

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

數據流;數據流操做開發包,封裝了與Redis,Rabbit、Kafka等發送接收消息。
Spring Cloud Stream是建立消息驅動微服務應用的框架。Spring Cloud Stream是基於spring boot建立,用來創建單獨的/工業級spring應用,使用spring integration提供與消息代理之間的鏈接。數據流操做開發包,封裝了與Redis,Rabbit、Kafka等發送接收消息。
一個業務會牽扯到多個任務,任務之間是經過事件觸發的,這就是Spring Cloud stream要乾的事了。

3.十一、Spring Cloud Sleuth

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

隨着服務的愈來愈多,對調用鏈的分析會愈來愈複雜,如服務之間的調用關係、某個請求對應的調用鏈、調用之間消費的時間等,對這些信息進行監控就成爲一個問題。在實際的使用中咱們須要監控服務和服務之間通信的各項指標,這些數據將是咱們改進系統架構的主要依據。所以分佈式的鏈路跟蹤就變的很是重要,Spring Cloud也給出了具體的解決方案:Spring Cloud Sleuth和Zipkin

服務跟蹤;日誌收集工具包,封裝了Dapper,Zipkin和HTrace操做。
日誌收集工具包,封裝了Dapper和log-based追蹤以及Zipkin和HTrace操做,爲SpringCloud應用實現了一種分佈式追蹤解決方案。

簡介

Spring Cloud Sleuth 主要功能就是在分佈式系統中提供追蹤解決方案,而且兼容支持了 zipkin,你只須要在pom文件中引入相應的依賴便可。

服務追蹤分析

微服務架構上經過業務來劃分服務的,經過REST調用,對外暴露的一個接口,可能須要不少個服務協同才能完成這個接口功能,若是鏈路上任何一個服務出現問題或者網絡超時,都會造成致使接口調用失敗。隨着業務的不斷擴張,服務之間互相調用會愈來愈複雜。

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

隨着服務的愈來愈多,對調用鏈的分析會愈來愈複雜。它們之間的調用關係也許以下:

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

術語

  • Span:基本工做單元,例如,在一個新建的span中發送一個RPC等同於發送一個迴應請求給RPC,span經過一個64位ID惟一標識,trace以另外一個64位ID表示,span還有其餘數據信息,好比摘要、時間戳事件、關鍵值註釋(tags)、span的ID、以及進度ID(一般是IP地址)
    span在不斷的啓動和中止,同時記錄了時間信息,當你建立了一個span,你必須在將來的某個時刻中止它。
  • Trace:一系列spans組成的一個樹狀結構,例如,若是你正在跑一個分佈式大數據工程,你可能須要建立一個trace。
  • Annotation:用來及時記錄一個事件的存在,一些核心annotations用來定義一個請求的開始和結束
    cs - Client Sent -客戶端發起一個請求,這個annotion描述了這個span的開始
    sr - Server Received -服務端得到請求並準備開始處理它,若是將其sr減去cs時間戳即可獲得網絡延遲
    ss - Server Sent -註解代表請求處理的完成(當請求返回客戶端),若是ss減去sr時間戳即可獲得服務端須要的處理請求時間
    cr - Client Received -代表span的結束,客戶端成功接收到服務端的回覆,若是cr減去cs時間戳即可獲得客戶端從服務端獲取回覆的全部所需時間
    將Span和Trace在一個系統中使用Zipkin註解的過程圖形化:

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

3.十二、Spring Cloud Feign 使用HTTP請求遠程服務

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

在Spring Cloud Netflix棧中,各個微服務都是以HTTP接口的形式暴露自身服務的,所以在調用遠程服務時就必須使用HTTP客戶端。咱們可使用JDK原生的URLConnection、Apache的Http Client、Netty的異步HTTP Client, Spring的RestTemplate。可是,用起來最方便、最優雅的仍是要屬Feign了。
Feign是一種聲明式、模板化的HTTP客戶端。在Spring Cloud中使用Feign, 咱們能夠作到使用HTTP請求遠程服務時能與調用本地方法同樣的編碼體驗,開發者徹底感知不到這是遠程方法,更感知不到這是個HTTP請求。
經過Feign, 咱們能把HTTP遠程調用對開發者徹底透明,獲得與調用本地方法一致的編碼體驗。這一點與阿里Dubbo中暴露遠程服務的方式相似,區別在於Dubbo是基於私有二進制協議,而Feign本質上仍是個HTTP客戶端。若是是在用Spring Cloud Netflix搭建微服務,那麼Feign無疑是最佳選擇。

Feign是一個聲明式的僞Http客戶端,它使得寫Http客戶端變得更簡單。使用Feign,只須要建立一個接口並註解。它具備可插拔的註解特性,可以使用Feign 註解和JAX-RS註解。Feign支持可插拔的編碼器和解碼器。Feign默認集成了Ribbon,並和Eureka結合,默認實現了負載均衡的效果。

簡而言之:

  • Feign 採用的是基於接口的註解
  • Feign 整合了ribbon

3.1三、Spring Cloud for Cloud Foundry

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Cloud Foundry是VMware推出的業界第一個開源PaaS雲平臺,它支持多種框架、語言、運行時環境、雲平臺及應用服務,使開發人員可以在幾秒鐘內進行應用程序的部署和擴展,無需擔憂任何基礎架構的問題
其實就是與CloudFoundry進行集成的一套解決方案,抱了Cloud Foundry的大腿。

3.1四、Spring Cloud Cluster

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Spring Cloud Cluster將取代Spring Integration。提供在分佈式系統中的集羣所須要的基礎功能支持,如:選舉、集羣的狀態一致性、全局鎖、tokens等常見狀態模式的抽象和實現。
若是把不一樣的幫派組織成統一的總體,Spring Cloud Cluster已經幫你提供了不少方便組織成統一的工具。

3.1五、Spring Cloud Consul

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Consul 是一個支持多數據中心分佈式高可用的服務發現和配置共享的服務軟件,由 HashiCorp 公司用 Go 語言開發, 基於 Mozilla Public License 2.0 的協議進行開源. Consul 支持健康檢查,並容許 HTTP 和 DNS 協議調用 API 存儲鍵值對.
Spring Cloud Consul 封裝了Consul操做,consul是一個服務發現與配置工具,與Docker容器能夠無縫集成。

3.1六、Spring Cloud Data Flow

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Data flow 是一個用於開發和執行大範圍數據處理其模式包括ETL,批量運算和持續運算的統一編程模型和託管服務。
對於在現代運行環境中可組合的微服務程序來講,Spring Cloud data flow是一個原生雲可編配的服務。使用Spring Cloud data flow,開發者能夠爲像數據抽取,實時分析,和數據導入/導出這種常見用例建立和編配數據通道 (data pipelines)。
Spring Cloud data flow 是基於原生雲對 spring XD的從新設計,該項目目標是簡化大數據應用的開發。Spring XD 的流處理和批處理模塊的重構分別是基於 spring boot的stream 和 task/batch 的微服務程序。這些程序如今都是自動部署單元並且他們原生的支持像 Cloud Foundry、Apache YARN、Apache Mesos和Kubernetes 等現代運行環境。
Spring Cloud data flow 爲基於微服務的分佈式流處理和批處理數據通道提供了一系列模型和最佳實踐。

3.1七、Spring Cloud Task

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Spring Cloud Task 主要解決短命微服務的任務管理,任務調度的工做,好比說某些定時任務晚上就跑一次,或者某項數據分析臨時就跑幾回。

3.1八、Spring Cloud Connectors

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Spring Cloud Connectors 簡化了鏈接到服務的過程和從雲平臺獲取操做的過程,有很強的擴展性,能夠利用Spring Cloud Connectors來構建你本身的雲平臺。
便於雲端應用程序在各類PaaS平臺鏈接到後端,如:數據庫和消息代理服務。

3.1九、Spring Cloud Starters

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Spring Boot式的啓動項目,爲Spring Cloud提供開箱即用的依賴管理。

3.20、Spring Cloud CLI

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

基於 Spring Boot CLI,可讓你以命令行方式快速創建雲組件。

3.2一、Netflix Turbine

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

Turbine是聚合服務器發送事件流數據的一個工具,用來監控集羣下hystrix的metrics狀況。

4、和Spring Boot 是什麼關係

Spring boot 是 Spring 的一套快速配置腳手架,能夠基於spring boot 快速開發單個微服務,Spring Cloud是一個基於Spring Boot實現的雲應用開發工具;Spring boot專一於快速、方便集成的單個個體,Spring Cloud是關注全局的服務治理框架;spring boot使用了默認大於配置的理念,不少集成方案已經幫你選擇好了,能不配置就不配置,Spring Cloud很大的一部分是基於Spring boot來實現,能夠不基於Spring boot嗎?不能夠。
Spring boot能夠離開Spring Cloud獨立使用開發項目,可是Spring Cloud離不開Spring boot,屬於依賴的關係

Spring -> Spring Boot > Spring Cloud 這樣的關係。

5、Spring Cloud的優點**

微服務的框架那麼多好比:dubbo、Kubernetes,爲何就要使用Spring Cloud的呢?

  • 產出於Spring你們族,Spring在企業級開發框架中無人能敵,來頭很大,能夠保證後續的更新、完善。好比dubbo如今就差很少死了
  • 有Spring Boot 這個獨立干將能夠省不少事,大大小小的活spring boot都搞的挺不錯。
    做爲一個微服務治理的你們夥,考慮的很全面,幾乎服務治理的方方面面都考慮到了,方便開發開箱即用。
  • Spring Cloud 活躍度很高,教程很豐富,遇到問題很容易找到解決方案
  • 輕輕鬆鬆幾行代碼就完成了熔斷、均衡負責、服務中心的各類平臺功能
  • Spring Cloud 也有一個缺點,只能使用Java開發,不適合小型獨立的項目。

6、Spring Cloud前景

Spring Cloud對於中小型互聯網公司來講是一種福音,由於這類公司每每沒有實力或者沒有足夠的資金投入去開發本身的分佈式系統基礎設施,使用Spring Cloud一站式解決方案能在從容應對業務發展的同時大大減小開發成本。同時,隨着近幾年微服務架構和docker容器概念的火爆,也會讓Spring Cloud在將來愈來愈「雲」化的軟件開發風格中立有一席之地,尤爲是在目前五花八門的分佈式解決方案中提供了標準化的、全站式的技術方案,意義可能會堪比當前Servlet規範的誕生,有效推動服務端軟件系統技術水平的進步。

共同進步,學習分享

歡迎你們關注個人公衆號【風平浪靜如碼】,海量Java相關文章,學習資料都會在裏面更新,整理的資料也會放在裏面。

以爲寫的還不錯的就點個贊,加個關注唄!點關注,不迷路,持續更新!!!

全網最全微服務架構—Spring Cloud詳解,沒有比這更詳細的了!

相關文章
相關標籤/搜索