微服務架構是一種架構模式或者說是一種架構風格,不同于集中式的服務管理機制,它提倡將單一應用程序劃分成一組小的服務,根據業務拆分成一個一個的服務,每個服務都圍繞著具體業務進行構建并且運行在其獨立的自己的進程中。服務之間通常是基于HTTP的RESTful API的輕量級的通信機制交互。每個服務能夠被獨立地部署到預生產環境、生產環境等。
優點:微服務可使用不同的語言開發,開發效率提高,一個服務可以專一的只干一件事。
1.復雜度?:服務調?要考慮被調??故障、過載、消息丟失等各種異常情況,代碼邏輯更加復雜;對于微服務間的事務性操作,因為不同的微服務采?了不同的數據庫,將?法利?數據庫本身的事務機制保證?致性,需要引??階段提交等技術。
2.運維復雜:系統由多個獨?運?的微服務構成,需要?個設計良好的監控系統對各個微服務的運?狀態進?監控。運維?員需要對系統有細致的了解才對夠更好的運維系統。
3.通信延遲:微服務之間調?會有時間損耗,造成通信延遲。
1)與分布式系統相關的復雜性-這種開銷包括網絡問題,延遲開銷,帶寬問題,安全問題。
2)服務發現-服務發現工具管理群集中的流程和服務如何查找和互相交談。它涉及一個服務目
錄,在該目錄中注冊服務,然后能夠查找并連接到該目錄中的服務。
3)冗余-分布式系統中的冗余問題。
4)負載平衡 --負載平衡改善跨多個計算資源的工作負荷,諸如計算機,計算機集群,網絡鏈
路,中央處理單元,或磁盤驅動器的分布。
5)性能-問題 由于各種運營開銷導致的性能問題。
1遠程過程調用(Remote Procedure Invocation)
只支持請求/響應的模式,要求客戶端和服務端在請求過程中必須都是可用的
2異步消息
支持很多通信機制比如通知、請求/異步響應、發布/訂閱、發布/異步響應;
SOA(全稱:Service Oriented Architecture),中文意思為 “面向服務的架構”,
1.微服務去中心化,去掉ESB企業總線。微服務不再強調傳統SOA架構里面比較重的ESB企業服務總線,同時SOA的思想進入到單個業務系統內部實現真正的組件化
2.Docker容器技術的出現,為微服務提供了更便利的條件,比如更小的部署單元,每個服務可以通過類似Node或者Spring Boot等技術跑在自己的進程中。
3.SOA注重的是系統集成方面,而微服務關注的是完全分離。
Netflix OSS 開源組件集成,包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心組件。
1.Eureka:服務治理組件,包括服務端的注冊中心和客戶端的服務發現機制;
2.Ribbon:負載均衡的服務調用組件,具有多種負載均衡調用策略;
3.Hystrix:服務容錯組件,實現了斷路器模式,為依賴服務的出錯和延遲提供了容錯能力;
4.Feign:基于Ribbon和Hystrix的聲明式服務調用組件;
5.Zuul:API網關組件,對請求提供路由及過濾功能。
6.Spring Cloud Config:分布式統一配置管理;
1SpringBoot專注于快速方便的開發單個個體微服務。
2SpringCloud是關注全局的微服務協調整理治理框架,它將SpringBoot開發的一個個單體微服務整合并管理起來,為各個微服務之間提供配置管理、服務發現、斷路器、路由、微代理、事件總線、全局鎖、決策競選、分布式會話等等集成服務。
3SpringBoot可以離開SpringCloud獨立使用開發項目,但是SpringCloud離不開SpringBoot,屬于依賴的關系.
4SpringBoot專注于快速、方便的開發單個微服務個體,SpringCloud關注全局的服務治理框架。
服務調用方式:Dubbo是RPC,SpringCloud是RestApi;
注冊中心:Dubbo 是zookeeper,SpringCloud是Eureka,也可以是ZooKeeper
服務網關:Dubbo本身沒有實現,只能通過其他第三方技術整合,SpringCloud有Zuul路由網關,作為路由服務器,進行消費者的請求分發,SpringCloud支持斷路器,與git完美集成配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素。
服務注冊是讓所有微服務將自己的信息注冊到注冊中心,服務發現在真正發起服務調用前,調用方需要從注冊中心拿到相應服務可用的IP和端口列表,即服務發現。
Eureka作為SpringCloud的服務注冊功能服務器,它是服務注冊中心,系統中的其他服務使用Eureka的客戶端將其連接到Eureka Service中,并且保持心跳,這樣工作人員可以通過EurekaService來監控各個微服務是否運行正常。
通過集群注冊多臺 Eureka ,然后把SpringCloud服務互相注冊,客戶端從Eureka獲取信息時,按照Eureka的順序來訪問。
默認情況下,如果 Eureka Service 在一定時間內沒有接收到某個微服務的心跳, Eureka Service 會進入自我保護模式,在該模式下Eureka Service 會保護服務注冊表中的信息,不在刪除注冊表中的數據,當網絡故障恢復后,Eureka Servic 節點會自動退出自我保護模式。
可以從注冊中心中根據服務別名獲取注冊的服務器信息。
1.ZooKeeper中的節點服務掛了就要選舉 在選舉期間注冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的, 選舉就是改微服務做了集群,必須有一臺主其他的都是從
2.Eureka各個節點是平等關系,服務器掛了沒關系,只要有一臺Eureka就可以保證服務可用,數據都是最新的。 如果查詢到的數據并不是最新的,就是因為Eureka的自我保護模式導致的
3.Eureka本質上是一個工程,而ZooKeeper只是一個進程
4.Eureka可很好的應對因網絡故障導致部分節點失去聯系的情況,而不會像ZooKeeper一樣使得整個注冊系統癱瘓
5.ZooKeeper保證的是CP,Eureka保證的是AP;
網關相當于一個網絡服務架構的入口,所有網絡請求必須通過網關轉發到具體的服務。
統一管理微服務請求,權限控制、負載均衡、路由轉發、監控、安全控制黑名單和白名單等。
Zuul是對SpringCloud提供的成熟對的路由方案,他會根據請求的路徑不同,網關會定位到指定的微服務,并代理請求到不同的微服務接口,他對外隱蔽了微服務的真正接口地址。 三個重要概念:動態路由表,路由定位,反向代理。
1)動態路由表:Zuul支持Eureka路由,手動配置路由,這倆種都支持自動更新
2)路由定位:根據請求路徑,Zuul有自己的一套定位服務規則以及路由表達式匹配
3)反向代理:客戶端請求到路由網關,網關受理之后,在對目標發送請求,拿到響應之后在給客戶端,它可以和Eureka,Ribbon,Hystrix等組件配合使用。
對外暴露,權限校驗,服務聚合,日志審計等
網關是對所有服務的請求進行分析過濾,過濾器是對單個服務而言。
Nginx、Zuul、Gateway
Zuul是java語言實現的,主要為java服務提供網關服務,尤其在微服務架構中可以更加靈活的對網關進行操作。Nginx是使用C語言實現,性能高于Zuul,但是實現自定義操作需要熟悉lua語言,對程序員要求較高,可以使用Nginx做Zuul集群。
Zuul是SpringCloud集成的網關,使用Java語言編寫,可以對SpringCloud架構提供更靈活的服務。
考慮到API接口的分類可以將API接口分為開發API接口和內網API接口,內網API接口用于局域網,為內部服務器提供服務。開放API接口用于對外部合作單位提供接口調用,需要遵循Oauth2.0權限認證協議。同時還需要考慮安全性、冪等性等問題。
crun():過濾器的具體業務邏輯
shouldFilter():判斷過濾器是否有效
filterOrder():過濾器執行順序
filterType():過濾器攔截位置
通過path配置攔截請求,通過ServiceId到配置中心獲取轉發的服務列表,Zuul內部使用Ribbon實現本地負載均衡和轉發。
使用Nginx的upstream設置Zuul服務集群,通過location攔截請求并轉發到upstream,默認使用輪詢機制對Zuul集群發送請求。
SpringCloudGateway是SpringCloud官方推出的第二代網關框架,取代Zuul網關。網關作為流量的,在微服務系統中有著非常作用,網關常見的功能有路由轉發、權限校驗、限流控制等作用。使用了一個RouteLocatorBuilder的bean去創建路由,除了創建路RouteLocatorBuilder可以讓你添加各種predicates和filters,predicates斷言的意思,顧名思義就是根據具體的請求的規則,由具體的route去處理,filters是各種過濾器,用來對請求做各種判斷和修改。
Feign 是一個聲明web服務客戶端,這使得編寫web服務客戶端更容易將我們需要調用的服務方法定義成抽象方法保存在本地就可以了,不需要自己構建Http請求了,直接調用接口就行了,不過要注意,調用方法要和本地抽象方法的簽名完全一致。
Feign
RestTemplate
Ribbon
調用方式同:Ribbon需要我們自己構建Http請求,模擬Http請求然后通過RestTemplate發給其他服務,步驟相當繁瑣而Feign則是在Ribbon的基礎上進行了一次改進,采用接口的形式,將我們需要調用的服務方法定義成抽象方法保存在本地就可以了,不需要自己構建Http請求了,直接調用接口就行了,不過要注意,調用方法要和本地抽象方法的簽名完全一致。
簡單來說: 先將集群,集群就是把一個的事情交給多個人去做,假如要做1000個產品給一個人做要10天,我叫10個人做就是一天,這就是集群,負載均衡的話就是用來控制集群,他把做的最多的人讓他慢慢做休息會,把做的最少的人讓他加量讓他做多點。在計算中,負載平衡可以改善跨計算機,計算機集群,網絡鏈接,中央處理單元或磁盤驅動器等多種計算資源的工作負載分布。負載平衡旨在優化資源使用,最大化吞吐量,最小化響應時間并避免任何單一資源的過載。使用多個組件進行負載平衡而不是單個組件可能會通過冗余來提高可靠性和可用性。負載平衡通常涉及專用軟件或硬件,例如多層交換機或域名系統服務器進程。
Ribbon是Netflix發布的開源項目,主要功能是提供客戶端的軟件負載均衡算法;Ribbon客戶端組件提供一系列完善的配置項,如連接超時,重試等。簡單的說,就是在配置文件中列出后面所有的機器,Ribbon會自動的幫助你基于某種規則(如簡單輪詢,隨即連接等)去連接這些機器。我們也很容易使用Ribbon實現自定義的負載均衡算法。(有點類似Nginx)
Nginx是反向代理同時可以實現負載均衡,nginx攔截客戶端請求采用負載均衡策略根據upstream配置進行轉發,相當于請求通過nginx服務器進行轉發。Ribbon是客戶端負載均衡,從注冊中心讀取目標服務器信息,然后客戶端采用輪詢策略對服務直接訪問,全程在客戶端操作。
Ribbon使用discoveryClient從注冊中心讀取目標服務信息,對同一接口請求進行計數,使用%取余算法獲取目標服務集群索引,返回獲取到的目標服務信息。@LoadBalanced注解的作用開啟客戶端負載均衡。
當一個服務調用另一個服務由于網絡原因或自身原因出現問題,調用者就會等待被調用者的響應;當更多的服務請求到這些資源導致更多的請求等待,發生連鎖效應(雪崩效應)。
斷路器有三種狀態
1)打開狀態:一段時間內 達到一定的次數無法調用 并且多次監測沒有恢復的跡象 斷路器完全打開 那么下次請求就不會請求到該服務;
2)半開狀態:短時間內 有恢復跡象 斷路器會將部分請求發給該服務,正常調用時斷路器關閉;
3)關閉狀態:當服務一直處于正常狀態 能正常調用;
Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫,在分布式系統里,許多依賴不可避免的會調用失敗,比如超時、異常等。當某個服務單元發生故障之后,熔斷器會向調用方返回一個符合預期的、可處理的備選響應(FallBack),而不是長時間的等待或者拋出調用方無法處理的異常,這樣就保證了服務調用方的線程不會被長時間、不必要地占用,從而避免了故障在分布式系統中的蔓延,乃至雪崩,以提高分布式系統的彈性。5秒內20次調用失敗就會啟動熔斷機制。熔斷機制的注解是@HystrixCommand。
服務降級:接口調用失敗就調用本地的方法返回一個空
服務熔斷:接口調用失敗就會進入調用接口提前定義好的一個熔斷的方法,返回錯誤信息
服務隔離:隔離服務之間相互影響
服務監控:在服務發生調用時,會將每秒請求數、成功請求數等運行指標記錄下來。
雪崩效應是在大型互聯網項目中,當某個服務發生宕機時,調用這個服務的其他服務也會發生宕機,大型項目的微服務之間的調用是互通的,這樣就會將服務的不可用逐步擴大到各個其他服務中,從而使整個項目的服務宕機崩潰.發生雪崩效應的原因有以下幾點
1)單個服務的代碼存在bug.
2)請求訪問量激增導致服務發生崩潰(如大型商城的槍紅包,秒殺功能).
3)服務器的硬件故障也會導致部分服務不可用.
一般使用使用Hystrix框架,實現服務隔離來避免出現服務的雪崩效應,從而達到保護服務的效果。當微服務中,高并發的數據庫訪問量導致服務線程阻塞,使單個服務宕機,服務的不可用會蔓延到其他服務,引起整體服務災難性后果,使用服務降級能有效為不同的服務分配資源,一旦服務不可用則返回友好提示,不占用其他服務資源,從而避免單個服務崩潰引發整體服務的不可用.
因為Tomcat默認情況下只有一個線程池來維護客戶端發送的所有的請求,這時候某一接口在某一時刻被大量訪問就會占據tomcat線程池中的所有線程,其他請求處于等待狀態,無法連接到服務接口。
1)服務降級:當客戶端請求服務器端的時候,防止客戶端一直等待,不會處理業務邏輯代碼,直接返回一個友好的提示給客戶端。
2)服務熔斷是在服務降級的基礎上更直接的一種保護方式,當在一個統計時間范圍內的請求失敗數量達到設定值(requestVolumeThreshold)或當前的請求錯誤率達到設定的錯誤率閾值(errorThresholdPercentage)時開啟斷路,之后的請求直接走fallback方法,在設定時間(sleepWindowInMilliseconds)后嘗試恢復。
3)服務隔離就是Hystrix為隔離的服務開啟一個獨立的線程池,這樣在高并發的情況下不會影響其他服務。服務隔離有線程池和信號量兩種實現方式,一般使用線程池方式。
Hystrix實現服務降級的功能是通過重寫HystrixCommand中的getFallback()方法,當Hystrix的run方法或construct執行發生錯誤時轉而執行getFallback()方法。
SpringCloudBus就像一個分布式執行器,用于擴展的SpringBoot應用程序的配置文件,但也可以用作應用程序之間的通信通道;
SpringCloudBus 不能單獨完成通信,需要配合MQ支持;
SpringCloudBus一般是配合SpringCloudConfig做配置中心的;
SpringCloudConfig實時刷新也必須采用SpringCloudBus消息總線;
SpringCloud Config為分布式系統中的外部配置提供服務器和客戶端支持,可以方便的對微服務各個環境下的配置進行集中式管理。Spring CloudConfig分為ConfigServer和ConfigClient兩部分。ConfigServer負責讀取配置文件,并且暴露Http API接口,ConfigClient通過調用ConfigServer的接口來讀取配置文件。
Apollo、ZooKeeper、SpringCloudConfig。
動態變更項目配置信息而不必重新部署項目。
SpringCloudConfig實時刷新采用SpringCloudBus消息總線。