分佈式架構-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下行請求以前或者以後改變。

     feign客戶端模塊：SpringCloudOpenFeign