SpringCloud全系列組件架構圖
SpringCloud全系列組件圖:ProcessOn Mindmap
1、什麼是微服務架構
微服務架構就是將單體的應用程式分成多個應用程式,這多個應用程式就成為微服務,每個微服務運行在自己的進程中,並使用輕量級的機制通信。這些服務圍繞業務能力來劃分,並通過自動化部署機制來獨立部署。這些服務可以使用不同的程式語言,不同資料庫,以保證最低限度的集中式管理。
分布式:將一個大的應用按功能進行拆分成多個小應用,部署在不同的伺服器上,稱為分布式。 集群:同一個業務,部署在不同的伺服器,對外提供相同的功能。稱為集群 微服務:將一個大的應用按功能進行拆分成多個小應用,每個小應用就稱為微服務(常見的技術例如SpringBoot)
微服務架構簡稱為,面向服務的架構(SOA)。是一個組件模型,它將應用程式的不同功能單元(稱為服務)進行拆分,並通過這些服務之間定義良好的接口和協議聯繫起來。接口是採用中立的方式進行定義的,它應該獨立於實現服務的硬體平台、作業系統和程式語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
微服務架構的優點和缺點
優點:
1、微服務對服務的拆分變更的更細(復用性強)。
2、可根據需求使用新的技術
3、開發速度快(周期少)。適用於網際網路項目。
4、進行高並發部署,可按需部署服務,減少因在同一個項目中出現資源浪費等。
缺點:
微服務過多,對服務的治理成本高。
服務的部署難度加大,需要結合Docker等雲容器部署。
技術難點在增加(出現了很多分布式的技術,
例如:分布式ID/分布式事務/分布式日誌/分布式Session/分布式鎖等)
2、Spring Cloud 是什麼
SpringCloud是分布式微服務治理解決方案。提供了一系列框架技術的有序集合。
利用Spring Boot的開發便利性巧妙地簡化了分布式系統基礎設施的開發,如服務發現註冊、配置中心、智能路由、消息總線、負載均衡、斷路器、數據監控等,都可以用Spring Boot的開發風格做到一鍵啟動和部署。
Spring Cloud是集大成者,它只是將各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來,通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理,最終給開發者留出了一套簡單易懂、易部署和易維護的分布式系統開發工具包。
3、SpringCloud的優缺點
優點:
1.耦合度比較低。不會影響其他模塊的開發。 2.配置比較簡單,基本用註解就能實現,不用使用過多的配置文件。 3.微服務跨平台的,可以用任何一種語言開發。 4.每個微服務可以有自己的獨立的資料庫也有用公共的資料庫。 5.直接寫後端的代碼,不用關注前端怎麼開發,直接寫自己的後端代碼即可,然後暴露接口,通過組件進行服務通信。
6.組件化(模塊化)、隨時開箱拆箱。
缺點:
項目結構複雜,每一個組件或者每一個服務都需要創建一個項目。
部署門檻高,項目部署需要配合 Docker 等容器技術進行集群部署。
僅支持JAVA語言。
並不是所有的項目都需要SpringCloud。
4、SpringBoot和SpringCloud的區別?
SpringBoot專注於快速方便的開發單個個體微服務。
SpringCloud是全局的微服務協調整理治理框架,它將SpringBoot開發的一個個單體微服務整合併管理起來,為各個微服務之間提供,配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務
SpringBoot可以離開SpringCloud獨立使用開發項目, SpringCloud基於SpringBoot ,不能脫離SpringBoot。
SpringBoot專注於快速、方便的開發單個微服務個體,SpringCloud關注全局的服務治理框架。
5、SpringCloud有哪些組件?
Spring Cloud Eureka:服務註冊與發現
Spring Cloud Ribbon:客戶端負載均衡
Spring Cloud Feign:聲明性的Web服務客戶端
Spring Cloud Hystrix:斷路器
Spring Cloud Zuul:服務網關
Spring Cloud Config:分布式統一配置管理其它組件詳細地址:
https://www.processon.com/view/link/5ef6e8a96376891e81e8009d
6、為什麼使用服務發現?
如果你在寫代碼調用一個有REST API或Thrift API的服務,你的代碼需要知道一個服務實例的網絡地址(IP位址和埠)。運行在物理硬體上的傳統應用中,服務實例的網絡地址是相對靜態的,你的代碼可以從一個很少更新的配置文件中讀取網絡地址。 在一個現代的,基於雲的微服務應用中, 服務實例的網絡地址是動態分配的。而且,由於自動擴展,失敗和更新,服務實例的配置也經常變化。此時,需要服務註冊與發現的組件來解決動態IP的變化等問題。
7、服務註冊與發現需要具備哪些功能?
註冊中心應具備以下功能:
服務註冊表 服務註冊表是註冊中心的核心,它用來記錄各個微服務的信息,例如微服務的名稱、IP、埠等。服務註冊表提供查詢API和管理API,查詢API用於查詢可用的微服務實例,管理API用於服務的註冊與註銷。
服務註冊與發現 服務註冊是指微服務在啟動時,將自己的信息註冊到註冊中心的過程。服務發現是指查詢可用的微服務列表及網絡地址的機制。
服務檢查 註冊中心使用一定的機制定時檢測已註冊的服務,如發現某實例長時間無法訪問,就會從服務註冊表移除該實例。
8、Eureka組件
什麼是Eureka
Eureka是作為SpringCloud的服務註冊與發現組件功能伺服器,是服務註冊中心,系統中的其他服務使用Eureka的客戶端將其連接到Eureka Service中,並且保持心跳,這樣開發人員可以通過Eureka Service來監控各個微服務是否運行正常。
什麼是Eureka的自我保護模式,
默認情況下,如果Eureka Service在一定時間內沒有接收到某個微服務的心跳,Eureka Service會進入自我保護模式,在該模式下Eureka Service會保護服務註冊表中的信息,不在刪除註冊表中的數據,當網絡故障恢復後,Eureka Servic 節點會自動退出自我保護模式
Renew服務租約
Eureka Client 在默認的情況下會每隔 30 秒發送一次心跳來進行服務續約。通過服務續約 來告知 Eureka Server 該 Eureka Client 仍然可用,沒有出現故障。正常情況下,如果 Eureka Server 在 90 秒內沒有收到 Eureka Client 的心跳, Eureka Server 會將 Eureka Client 實例從註冊列表中 刪除。
Eviction什麼時候會對服務進行剔除
在默認情況下,當 Eureka Client 連續 90 秒沒有向 Eureka Server 發送服務續約(即心跳〉 時, Eureka Server 會將該服務實例從服務註冊列表刪除,即服務剔除。
Eureka怎麼實現高可用
註冊多台Eureka,SpringCloud服務間互相註冊,客戶端從Eureka獲取信息時,按照Eureka的順序依次來訪問。
9、Ribbon組件
Ribbon是什麼?
Ribbon是Netflix發布的開源項目,主要功能是提供客戶端的服務間調用和服務的負載均衡。
Ribbon與Eureka配合使用時,Ribbon可自動從Eureka Server獲取服務提供者地址列表,並基於負載均衡算法,請求其中一個服務提供者實例。Ribbon客戶端組件提供一系列完善的配置項,如連接超時,重試等。簡單的說,就是在配置文件中列出後面所有的機器,Ribbon會自動的幫助你基於某種規則(如簡單輪詢,隨即連接等)去連接這些機器。我們也很容易使用Ribbon實現自定義的負載均衡算法。(有點類似nginx)
Nginx與Ribbon的區別
Nginx是反向代理同時可以實現負載均衡,nginx攔截客戶端請求採用負載均衡策略根據upstream配置進行轉發,相當於請求通過nginx伺服器進行轉發。
Ribbon是客戶端負載均衡,從註冊中心讀取目標伺服器信息,然後客戶端採用輪詢策略對服務直接訪問,全程在客戶端操作。(默認是輪循操作)
Ribbon底層實現原理
Ribbon使用discoveryClient從註冊中心讀取目標服務信息,對同一接口請求進行計數,使用%取余算法獲取目標服務集群索引,返回獲取到的目標服務信息。
10、Feign組件
什麼是Feign?
Feign 是一個聲明web服務客戶端,這使得編寫web服務客戶端更容易
Feign可幫助我們更加便捷,優雅的調用HTTP API。 在SpringCloud中,使用Feign非常簡單——創建一個接口,並在接口上添加一些註解,代碼就完 成了。 Feign支持多種註解,例如Feign自帶的註解或者JAX-RS註解等。SpringCloud對Feign進行了增強,使Feign支持了SpringMVC註解,並整合了Ribbon和Eureka, 從而讓Feign的使用更加方便。
Spring Cloud 集成 Ribbon 和 Eureka 提供的負載均衡的HTTP客戶端Feign。(Feign默認集成了Ribbon,並和Eureka結合)。默認實現了負載均衡的效果。
Ribbon和Feign調用服務的區別
調用方式同:Ribbon需要我們自己構建Http請求,模擬Http請求然後通過RestTemplate發給其他服務,步驟相當繁瑣
而Feign則是在Ribbon的基礎上進行了一次改進,採用接口的形式,將我們需要調用的服務方法定義成抽象方法保存在本地就可以了,不需要自己構建Http請求了,直接調用接口就行了,不過要注意,調用方法要和本地抽象方法的簽名完全一致。
11、Hystrix組件
什麼是 Hystrix?
在分布式系統,我們一定會依賴各種服務,那麼這些個服務一定會出現失敗的情況,就會導致雪崩,
Hystrix是由Netflix開源的一個針對分布式系統容錯處理的開源組件。能夠提供斷路,降級,監控等多種服務。它具有服務降級,服務熔斷,服務隔離,監控等一些防止雪崩的技術。
Hystrix提供了哪些功能?
Hystrix有四種防雪崩方式:
服務降級:接口調用失敗就調用本地的方法返回一個空
服務熔斷:接口調用失敗就會進入調用接口提前定義好的一個熔斷的方法,返回錯誤信息
服務隔離:隔離服務之間相互影響
服務監控:在服務發生調用時,會將每秒請求數、成功請求數等運行指標記錄下來。
服務雪崩效應產生的原因
因為Tomcat默認情況下只有一個線程池來維護客戶端發送的所有的請求,這時候某一接口在某一時刻被大量訪問就會占據tomcat線程池中的所有線程,其他請求處於等待狀態,無法連接到服務接口。
在微服務中,如何保護服務?
一般使用使用Hystrix框架,實現服務隔離來避免出現服務的雪崩效應,從而達到保護服務的效果。當微服務中,高並發的資料庫訪問量導致服務線程阻塞,使單個服務宕機,服務的不可用會蔓延到其他服務,引起整體服務災難性後果,使用服務降級能有效為不同的服務分配資源,一旦服務不可用則返回友好提示,不占用其他服務資源,從而避免單個服務崩潰引發整體服務的不可用.
服務容錯的相關知識概念
服務容錯的核心知識 雪崩效應
在微服務架構中,一個請求需要調用多個服務是非常常見的。如客戶端訪問A服務,而A服務需要調用B 服務,B服務需要調用C服務,由於網絡原因或者自身的原因,如果B服務或者C服務不能及時響應,A服 務將處於阻塞狀態,直到B服務C服務響應。此時若有大量的請求湧入,容器的線程資源會被消耗完畢, 導致服務癱瘓。服務與服務之間的依賴性,故障會傳播,造成連鎖反應,會對整個微服務系統造成災難 性的嚴重後果,這就是服務故障的「雪崩」效應。(服務熔斷和服務降級就可以視為解決服務雪崩的手段之一)
服務隔離
顧名思義,它是指將系統按照一定的原則劃分為若干個服務模塊,各個模塊之間相對獨立,無強依賴。 當有故障發生時,能將問題和影響隔離在某個模塊內部,而不擴散風險,不波及其它模塊,不影響整體 的系統服務。
服務熔斷
熔斷這一概念來源於電子工程中的斷路器(Circuit Breaker)。
在網際網路系統中,當下游服務因訪問壓力過大而響應變慢或失敗,上游服務為了保護系統整體的可用性,可以暫時切斷對下游服務的調用。這種犧牲局部,保全整體的措施就叫做熔斷。
服務降級
降級,就是當某個服務熔斷之後,伺服器將不再被調用,此時客戶端可以自己準備一個本地的 fallback回調,返回一個預設值。
Hystrix實現兩個核心註解
@HystrixCommand 註解
@FeignClient註解:fallback 如果接口服務不能訪問或延遲,則運行對應其接口實現類。
12、網關組件
什麼是網關?
網關相當於一個網絡服務架構的入口,所有網絡請求必須通過網關轉發到具體的服務。
API網關,顧名思義,是統一管理API的一個網絡關口、通道,是整個微服務平台所有請求的唯一入口,所有的客戶端和消費端都通過統一的網關接入微服務,在網關層處理所有的非業務功能。
網關的作用是什麼
統一管理微服務請求,權限控制、負載均衡、路由轉發、監控、安全控制黑名單和白名單等
網關與過濾器有什麼區別
網關是對所有服務的請求進行分析過濾,過濾器是對單個服務而言。
ZuulFilter常用有那些方法
Run():過濾器的具體業務邏輯
shouldFilter():判斷過濾器是否有效
filterOrder():過濾器執行順序
filterType():過濾器攔截位置
Zuul與Nginx有什麼區別?
Zuul是java語言實現的,主要為java服務提供網關服務,尤其在微服務架構中可以更加靈活的對網關進行操作。Nginx是使用C語言實現,性能高於Zuul,但是實現自定義操作需要熟悉lua語言,對程式設計師要求較高,可以使用Nginx做Zuul集群
Nginx可以實現網關?為什麼還需要使用Zuul框架
Zuul是SpringCloud集成的網關,使用Java語言編寫,可以對SpringCloud架構提供更靈活的服務。
如何實現動態Zuul網關路由轉發
通過path配置攔截請求,通過ServiceId到配置中心獲取轉發的服務列表,Zuul內部使用Ribbon實現本地負載均衡和轉發。
Zuul網關如何搭建集群
使用Nginx的upstream設置Zuul服務集群,通過location攔截請求並轉發到upstream,默認使用輪詢機制對Zuul集群發送請求。
13、配置中心組件
分布式配置中心有那些框架?
SpringCloud Config、Apollo、Zookeeper。
什麼是Spring Cloud Config?
Spring Cloud Config為分布式系統中的外部配置提供伺服器和客戶端支持,可以方便的對微服務各個環境下的配置進行集中式管理。Spring Cloud Config分為Config Server和Config Client兩部分。Config Server負責讀取配置文件,並且暴露Http API接口,Config Client通過調用Config Server的接口來讀取配置文件。
Spring Cloud Config
Config能夠管理所有微服務的配置文件
集中配置管理工具,分布式系統中統一的外部配置管理,默認使用Git來存儲配置,可以支持客戶端配置的刷新及加密、解密操作。
分布式配置中心的作用?
動態變更項目配置信息而不必重新部署項目。
SpringCloud Config 可以實現實時刷新嗎?
SpringCloud Config實時刷新採用SpringCloud Bus消息總線。
http://assets.processon.com/chart_image/5e46afc1e4b00aefb7e063aa.png
14、Spring Cloud Bus
用於傳播集群狀態變化的消息總線,使用輕量級消息代理連結分布式系統中的節點,可以用來動態刷新集群中的服務配置信息。
簡單來說就是修改了配置文件,發送一次請求,所有客戶端便會重新讀取配置文件。需要利用中間插件MQ
15、Spring Cloud Sleuth組件
在微服務中,通常根據業務模塊分服務,項目中前端發起一個請求,後端可能跨幾個服務調用才能完成這個請求。如果系統越來越龐大,服務之間的調用與被調用關係就會變得很複雜,假如一個請求中需要跨幾個服務調用,其中一個服務由於網絡延遲等原因掛掉了,那麼這時候我們需要分析具體哪一個服務出問題了就會顯得很困難。
Spring Cloud Sleuth服務鏈路跟蹤功能就可以幫助我們快速的發現錯誤根源以及監控分析每條請求鏈路上的性能等等。
16、Spring Cloud Stream組件
輕量級事件驅動微服務框架,可以使用簡單的聲明式模型來發送及接收消息,主要實現為Apache Kafka及RabbitMQ。
17、Spring Cloud Task組件
Spring Cloud Task的目標是為Spring Boot應用程式提供創建短運行期微服務的功能。在Spring Cloud Task中,我們可以靈活地動態運行任何任務,按需分配資源並在任務完成後檢索結果。Tasks是Spring Cloud Data Flow中的一個基礎項目,允許用戶將幾乎任何Spring Boot應用程式作為一個短期任務執行。
18、Spring Cloud Sidecar組件
在我們的分布式項目中,經常會出現一部分服務是 Java 語言寫的,一部分服務是非 Java 語言寫的,Java 語言寫的服務可以通過我們的 SpringCloud 組件來進行服務發現,網關路由等操作,但是非 Java語言的程序 則無法實現這個功能,為了解決這個問題,Netfilix 提供了 Sidecar 來解決,其基本思想就是 sidecar 是一個 Java 語言的程序,然後內容通過配置訪問非 Java語言的程序,然後註冊到我們的 SpringCloud組件中,實現我們的功能,本質上其就是一個代理