分布式架構(gòu)SpringCloud如何實(shí)現(xiàn)CAP

這篇文章將為大家詳細(xì)講解有關(guān)分布式架構(gòu)SpringCloud如何實(shí)現(xiàn)CAP，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

 調(diào)研SpringCloud

SpringCloud是現(xiàn)階段最火的微服務(wù)治理框架，那么SpringCloud如何實(shí)現(xiàn)服務(wù)治理的CAP，這里我只想談?wù)勎覍?duì)SpringCloud架構(gòu)思想的理解。

個(gè)人理解的SpringCloud本質(zhì)：

1）封裝業(yè)界最火的基礎(chǔ)組件（也可以叫中間件），豌豆莢的Netflix一籃子組件，并注入SpringBoot特性，無(wú)縫對(duì)接SpringBoot項(xiàng)目，業(yè)務(wù)開(kāi)箱即用。

2）SpringCloud本質(zhì)上也是一個(gè)高級(jí)中間件，比spring和springBoot都高級(jí)，但是比他們都簡(jiǎn)單，也更加的靈活。

那么問(wèn)題來(lái)了，SpringCloud能為我們解決什么問(wèn)題呢，特性、有點(diǎn)和缺點(diǎn)有事什么，網(wǎng)上百度一下，一大堆亂七八糟的文章，都是淺嘗輒止，人云亦云，這個(gè)可能會(huì)給很多架構(gòu)師出了很多的難題，為嘛選型SpringCloud。

其實(shí)技術(shù)對(duì)于架構(gòu)師來(lái)說(shuō)不是難事，主要難在如何選型和技術(shù)梳理，SpringCloud官網(wǎng)http://projects.spring.io/spring-cloud/ ，SpringCloud中文翻譯網(wǎng)站https://springcloud.cc/，其實(shí)很好的利用好這兩個(gè)網(wǎng)站，對(duì)于你更好的掌握好這個(gè)框架是很有幫助的。

  SpringCloud整體功能模塊

       分布式配置模塊  

           SpringCloudConfig，分布式配置，阿里也有自己自研的config server，那么SpringCloud的分布式配置系統(tǒng)有哪些特性，這里就簡(jiǎn)單的總結(jié)下。SpringCloudConfig是SpringCloud提供的分布式配置中心的解決方案，依托于Netflix服務(wù)治理模塊和Consul服務(wù)治理模塊，解耦為server和client，server就是分布式配置中心，獨(dú)立部署，暴露一些restful接口，獲取配置信息?？蛻舳送ㄟ^(guò)starter集成到業(yè)務(wù)系統(tǒng)，與業(yè)務(wù)系統(tǒng)一塊啟動(dòng)，通過(guò)指定對(duì)應(yīng)的server配置中心，熱加載與應(yīng)用相關(guān)的配置信息，并本地緩存。SpringCloud支持git和文件兩種模式的分布式配置中心，那么這兩種如何保證CAP，這就得仔細(xì)的閱讀源碼。當(dāng)然你可以直接通過(guò)client訪問(wèn)server，獲取配置信息，但是這樣就會(huì)有單點(diǎn)問(wèn)題了，一旦server掛了，就很難玩完了，其實(shí)SpringCloud本身框架設(shè)計(jì)的理念就是服務(wù)化集群管理，怎么可能出現(xiàn)單點(diǎn)故障了，client和server都可以以一個(gè)獨(dú)立的微服務(wù)注冊(cè)到eureka或者consul注冊(cè)中心，從而實(shí)現(xiàn)client和server的服務(wù)治理，就可以充分的利用consul的CP和eureka的AP特性，達(dá)到服務(wù)的高可用。

  Netflix服務(wù)治理模塊（Eureka）

    SpringCloudNetflix，考慮到發(fā)生故障的情況，服務(wù)注冊(cè)中心發(fā)生故障必將會(huì)造成整個(gè)系統(tǒng)的癱瘓，因此需要保證服務(wù)注冊(cè)中心的高可用。Eureka Server在設(shè)計(jì)的時(shí)候就考慮了高可用設(shè)計(jì)，在Eureka服務(wù)治理設(shè)計(jì)中，所有節(jié)點(diǎn)既是服務(wù)的提供方，也是服務(wù)的消費(fèi)方，服務(wù)注冊(cè)中心也不例外。

   Eureka Server的高可用實(shí)際上就是將自己做為服務(wù)向其他服務(wù)注冊(cè)中心注冊(cè)自己，這樣就可以形成一組互相注冊(cè)的服務(wù)注冊(cè)中心，以實(shí)現(xiàn)服務(wù)清單的互相同步，達(dá)到高可用的效果。

   Eureka Server的同步遵循著一個(gè)非常簡(jiǎn)單的原則：只要有一條邊將節(jié)點(diǎn)連接，就可以進(jìn)行信息傳播與同步?？梢圆捎脙蓛勺?cè)的方式實(shí)現(xiàn)集群中節(jié)點(diǎn)完全對(duì)等的效果，實(shí)現(xiàn)最高可用性集群，任何一臺(tái)注冊(cè)中心故障都不會(huì)影響服務(wù)的注冊(cè)與發(fā)現(xiàn)。eureka強(qiáng)調(diào)高可用性，也就是犧牲強(qiáng)一致性的前提下，保證AP。

  eureka是Servlet程序，需要嵌入到Servlet容器中，會(huì)影響服務(wù)治理的性能，這就是在網(wǎng)關(guān)技術(shù)選型的時(shí)候很多人放棄eureka-zuul,選擇更加粗暴的Nginx和lua做基礎(chǔ)網(wǎng)關(guān)，服務(wù)只要嵌入到servlet容器，性能就會(huì)受到setvlet容器的限制。

  eureka1.0高可用架構(gòu)缺陷：

      eureka沒(méi)有使用強(qiáng)一致性的選舉協(xié)議，比如ZAB協(xié)議作為數(shù)據(jù)一致性的算法（zookeeper選舉算法）比如Consul的數(shù)據(jù)一致性算法Raft，Eureka 集群的多副本的一致性協(xié)議采用類似“異步多寫(xiě)”的 AP 協(xié)議，每一個(gè)server都會(huì)把本地接收到的寫(xiě)請(qǐng)求（register/heartbeat/unregister/update）發(fā)送給組成集群的其他所有的機(jī)器（Eureka 稱之為 peer，對(duì)等服務(wù))，特別是 hearbeat 報(bào)文是周期性持續(xù)不斷的在 client->server->all peers 之間傳送。

 eureka數(shù)據(jù)一致性協(xié)議缺點(diǎn)：

   每一臺(tái) Server 都需要存儲(chǔ)全量的服務(wù)數(shù)據(jù)，Server 的內(nèi)存明顯會(huì)成為瓶頸。當(dāng)訂閱者卻來(lái)越多的時(shí)候，需要擴(kuò)容 Eureka 集群來(lái)提高讀的能力，但是擴(kuò)容的同時(shí)會(huì)導(dǎo)致每臺(tái) server 需要承擔(dān)更多的寫(xiě)請(qǐng)求，擴(kuò)容的效果不明顯。組成 Eureka 集群的所有server都需要采用相同的物理配置，并且只能通過(guò)不斷的提高配置來(lái)容納更多的服務(wù)數(shù)據(jù)

 eureka2.0架構(gòu)升級(jí)：

     數(shù)據(jù)推送從 pull 走向 push 模式，并且實(shí)現(xiàn)更小粒度的服務(wù)地址按需訂閱的功能。

     讀寫(xiě)分離，寫(xiě)集群相對(duì)穩(wěn)定，無(wú)需經(jīng)常擴(kuò)容；讀集群可以按需擴(kuò)容以提高數(shù)據(jù)推送能力。

     新增審計(jì)日志的功能和功能更豐富的 Dashboard。

  eureka2.0架構(gòu)整體升級(jí)類似于阿里巴巴自研的分布式注冊(cè)中心ConfigServer的架構(gòu)演進(jìn)。

 分布式消息總線模塊（Bus）

     SpringCloudBus又是一個(gè)什么樣的功能組件，顧名思義，那肯定是消息總線，如果不熟悉消息總線這個(gè)概念，可以自行的百度。這里就簡(jiǎn)單描述下SpringCloudBus微服務(wù)框架，主要解決什么問(wèn)題。

               SpringCloudBus消息總線支持Rabbitmq和Kafka，工程目錄結(jié)構(gòu):Spring-cloud-bus、Spring-cloud-bus-dependencies、Spring-cloud-starter-bus-amqp、Spring-cloud-starter-bus-kafka，其實(shí)Springcloud所有的工程目錄結(jié)構(gòu)都是按照springboot的格式來(lái)梳理的。消息總線底層是采用SpringCloudStream完成服務(wù)間的通信。

       單點(diǎn)登錄web模塊：SpringCloudForCloudFoundry

       集群管理模塊：SpringCloudCluster

      Consul服務(wù)治理模塊：SpringCloudConsul

      安全認(rèn)證模塊：SpringCloudSecurity

     全鏈路追蹤系統(tǒng)：SpringCloudSleuth

     數(shù)據(jù)流服務(wù)模塊：SpringCloudDataFlow

     消息隊(duì)列模塊

             SpringCloudStream是一個(gè)用來(lái)為微服務(wù)應(yīng)用構(gòu)建消息驅(qū)動(dòng)能力的框架，隔離業(yè)務(wù)與消息中間件，屏蔽掉消息中間件的差異性，比如Rabbitmq、Kafka等，當(dāng)然SpringCloud目前只支持Rabbitmq和Kafka，中間件團(tuán)隊(duì)可以自己封裝Rocketmq的綁定器，并以插件的形式侵入到業(yè)務(wù)中，從而讓業(yè)務(wù)無(wú)縫的切到Rocketmq，不用更改上層的業(yè)務(wù)代碼，完成消息中間件的升級(jí)。

     網(wǎng)關(guān)模塊

            SpringCloudGateway是SpringCloud封裝的又一套分布式微服務(wù)架構(gòu)網(wǎng)關(guān)。

            最新網(wǎng)關(guān)特性如下：基于Spring Framework 5，Project Reactor和Spring Boot 2.0構(gòu)建；能夠匹配任何請(qǐng)求屬性上的路由；Hystrix斷路器集成；Spring Cloud DiscoveryClient集成；請(qǐng)求率限制；路徑重寫(xiě)；容易編寫(xiě)斷言和過(guò)濾器；支持?jǐn)嘌院瓦^(guò)濾器到路由端。

         Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技術(shù)開(kāi)發(fā)的網(wǎng)關(guān)，Spring Cloud Gateway旨在為微服務(wù)架構(gòu)提供一種簡(jiǎn)單而有效的統(tǒng)一的API路由管理方式。Spring Cloud Gateway作為Spring Cloud生態(tài)系中的網(wǎng)關(guān)，目標(biāo)是替代Netflix ZUUL，其不僅提供統(tǒng)一的路由方式，并且基于Filter鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/埋點(diǎn)，和限流等。

          網(wǎng)關(guān)模塊的核心概念：路由、斷言和過(guò)濾器，路由功能是網(wǎng)關(guān)的基本模塊，它由一系列的ID，URI，以及斷言和過(guò)濾器組成。斷言是java8的函數(shù)式斷言，輸入類型是SpringFramework的ServerWebExchange，允許開(kāi)發(fā)者匹配所有的HTTP請(qǐng)求，包括HTTP頭和參數(shù)等。過(guò)濾器是SpringFramework GatewayFilter的實(shí)例化，請(qǐng)求和響應(yīng)會(huì)在HTTP下行請(qǐng)求之前或者之后改變。

關(guān)于分布式架構(gòu)SpringCloud如何實(shí)現(xiàn)CAP就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。