您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關分布式架構SpringCloud如何實現CAP,文章內容質量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關知識有一定的了解。
調研SpringCloud
SpringCloud是現階段最火的微服務治理框架,那么SpringCloud如何實現服務治理的CAP,這里我只想談談我對SpringCloud架構思想的理解。
個人理解的SpringCloud本質:
1)封裝業界最火的基礎組件(也可以叫中間件),豌豆莢的Netflix一籃子組件,并注入SpringBoot特性,無縫對接SpringBoot項目,業務開箱即用。
2)SpringCloud本質上也是一個高級中間件,比spring和springBoot都高級,但是比他們都簡單,也更加的靈活。
那么問題來了,SpringCloud能為我們解決什么問題呢,特性、有點和缺點有事什么,網上百度一下,一大堆亂七八糟的文章,都是淺嘗輒止,人云亦云,這個可能會給很多架構師出了很多的難題,為嘛選型SpringCloud。
其實技術對于架構師來說不是難事,主要難在如何選型和技術梳理,SpringCloud官網http://projects.spring.io/spring-cloud/ ,SpringCloud中文翻譯網站https://springcloud.cc/,其實很好的利用好這兩個網站,對于你更好的掌握好這個框架是很有幫助的。
SpringCloud整體功能模塊
分布式配置模塊
SpringCloudConfig,分布式配置,阿里也有自己自研的config server,那么SpringCloud的分布式配置系統有哪些特性,這里就簡單的總結下。SpringCloudConfig是SpringCloud提供的分布式配置中心的解決方案,依托于Netflix服務治理模塊和Consul服務治理模塊,解耦為server和client,server就是分布式配置中心,獨立部署,暴露一些restful接口,獲取配置信息。客戶端通過starter集成到業務系統,與業務系統一塊啟動,通過指定對應的server配置中心,熱加載與應用相關的配置信息,并本地緩存。SpringCloud支持git和文件兩種模式的分布式配置中心,那么這兩種如何保證CAP,這就得仔細的閱讀源碼。當然你可以直接通過client訪問server,獲取配置信息,但是這樣就會有單點問題了,一旦server掛了,就很難玩完了,其實SpringCloud本身框架設計的理念就是服務化集群管理,怎么可能出現單點故障了,client和server都可以以一個獨立的微服務注冊到eureka或者consul注冊中心,從而實現client和server的服務治理,就可以充分的利用consul的CP和eureka的AP特性,達到服務的高可用。
Netflix服務治理模塊(Eureka)
SpringCloudNetflix,考慮到發生故障的情況,服務注冊中心發生故障必將會造成整個系統的癱瘓,因此需要保證服務注冊中心的高可用。Eureka Server在設計的時候就考慮了高可用設計,在Eureka服務治理設計中,所有節點既是服務的提供方,也是服務的消費方,服務注冊中心也不例外。
Eureka Server的高可用實際上就是將自己做為服務向其他服務注冊中心注冊自己,這樣就可以形成一組互相注冊的服務注冊中心,以實現服務清單的互相同步,達到高可用的效果。
Eureka Server的同步遵循著一個非常簡單的原則:只要有一條邊將節點連接,就可以進行信息傳播與同步。可以采用兩兩注冊的方式實現集群中節點完全對等的效果,實現最高可用性集群,任何一臺注冊中心故障都不會影響服務的注冊與發現。eureka強調高可用性,也就是犧牲強一致性的前提下,保證AP。
eureka是Servlet程序,需要嵌入到Servlet容器中,會影響服務治理的性能,這就是在網關技術選型的時候很多人放棄eureka-zuul,選擇更加粗暴的Nginx和lua做基礎網關,服務只要嵌入到servlet容器,性能就會受到setvlet容器的限制。
eureka1.0高可用架構缺陷:
eureka沒有使用強一致性的選舉協議,比如ZAB協議作為數據一致性的算法(zookeeper選舉算法)比如Consul的數據一致性算法Raft,Eureka 集群的多副本的一致性協議采用類似“異步多寫”的 AP 協議,每一個server都會把本地接收到的寫請求(register/heartbeat/unregister/update)發送給組成集群的其他所有的機器(Eureka 稱之為 peer,對等服務),特別是 hearbeat 報文是周期性持續不斷的在 client->server->all peers 之間傳送。
eureka數據一致性協議缺點:
每一臺 Server 都需要存儲全量的服務數據,Server 的內存明顯會成為瓶頸。當訂閱者卻來越多的時候,需要擴容 Eureka 集群來提高讀的能力,但是擴容的同時會導致每臺 server 需要承擔更多的寫請求,擴容的效果不明顯。組成 Eureka 集群的所有server都需要采用相同的物理配置,并且只能通過不斷的提高配置來容納更多的服務數據
eureka2.0架構升級:
數據推送從 pull 走向 push 模式,并且實現更小粒度的服務地址按需訂閱的功能。
讀寫分離,寫集群相對穩定,無需經常擴容;讀集群可以按需擴容以提高數據推送能力。
新增審計日志的功能和功能更豐富的 Dashboard。
eureka2.0架構整體升級類似于阿里巴巴自研的分布式注冊中心ConfigServer的架構演進。
分布式消息總線模塊(Bus)
SpringCloudBus又是一個什么樣的功能組件,顧名思義,那肯定是消息總線,如果不熟悉消息總線這個概念,可以自行的百度。這里就簡單描述下SpringCloudBus微服務框架,主要解決什么問題。
SpringCloudBus消息總線支持Rabbitmq和Kafka,工程目錄結構:Spring-cloud-bus、Spring-cloud-bus-dependencies、Spring-cloud-starter-bus-amqp、Spring-cloud-starter-bus-kafka,其實Springcloud所有的工程目錄結構都是按照springboot的格式來梳理的。消息總線底層是采用SpringCloudStream完成服務間的通信。
單點登錄web模塊:SpringCloudForCloudFoundry
集群管理模塊:SpringCloudCluster
Consul服務治理模塊:SpringCloudConsul
安全認證模塊:SpringCloudSecurity
全鏈路追蹤系統:SpringCloudSleuth
數據流服務模塊:SpringCloudDataFlow
消息隊列模塊
SpringCloudStream是一個用來為微服務應用構建消息驅動能力的框架,隔離業務與消息中間件,屏蔽掉消息中間件的差異性,比如Rabbitmq、Kafka等,當然SpringCloud目前只支持Rabbitmq和Kafka,中間件團隊可以自己封裝Rocketmq的綁定器,并以插件的形式侵入到業務中,從而讓業務無縫的切到Rocketmq,不用更改上層的業務代碼,完成消息中間件的升級。
網關模塊
SpringCloudGateway是SpringCloud封裝的又一套分布式微服務架構網關。
最新網關特性如下:基于Spring Framework 5,Project Reactor和Spring Boot 2.0構建;能夠匹配任何請求屬性上的路由;Hystrix斷路器集成;Spring Cloud DiscoveryClient集成;請求率限制;路徑重寫;容易編寫斷言和過濾器;支持斷言和過濾器到路由端。
Spring Cloud Gateway是Spring官方基于Spring 5.0,Spring Boot 2.0和Project Reactor等技術開發的網關,Spring Cloud Gateway旨在為微服務架構提供一種簡單而有效的統一的API路由管理方式。Spring Cloud Gateway作為Spring Cloud生態系中的網關,目標是替代Netflix ZUUL,其不僅提供統一的路由方式,并且基于Filter鏈的方式提供了網關基本的功能,例如:安全,監控/埋點,和限流等。
網關模塊的核心概念:路由、斷言和過濾器,路由功能是網關的基本模塊,它由一系列的ID,URI,以及斷言和過濾器組成。斷言是java8的函數式斷言,輸入類型是SpringFramework的ServerWebExchange,允許開發者匹配所有的HTTP請求,包括HTTP頭和參數等。過濾器是SpringFramework GatewayFilter的實例化,請求和響應會在HTTP下行請求之前或者之后改變。
關于分布式架構SpringCloud如何實現CAP就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。