分布式架构-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