SpringCloud 入门

Spring Cloud是一个基于Spring Boot实现的云应用开发工具，它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

 

核心成员:       

 

1、Spring Cloud Netflix :

    Spring Cloud Netflix这个项目对于Spring Boot应用来说，它集成了NetFlix OSS的一些组件，只需通过注解配置和Spring环境的通用简单的使用注解，你可以快速的启用和配置这些久经测试考验的NetFlix的组件于你的应用和用于构建分布式系统中。这些组件包含的功能有服务发现（Eureka），熔断器（Hystrix），智能路由(Zuul)以及客户端的负载均衡器（Ribbon）
    简单的来说，Spring Cloud NetFlix这个项目对NetFlix中一些久经考验靠谱的服务发现，熔断，网关，智能路由，以及负载均衡等做了封装，并通过注解的或简单配置的方式提供给Spring Cloud用户用。

 

1. 1. Netflix Eureka :三个核心角色：服务注册中心，服务提供者和服务消费者

 

Eureka是一个基于REST(Representational State Transfer)的服务，主要用于AWS cloud， 提供服务定位(locating services)、负载均衡(load balancing)、故障转移(failover of middle-tier servers)。我们把它叫做Eureka Server. Eureka也提供了基于Java的客户端组件，Eureka Client,内置的负载均衡器可以实现基本的round-robin负载均衡能力。在Netflix，一个基于Eureka的更复杂的负载均衡器针对多种因素(如流量、资源利用率、错误状态等)提供加权负载均衡，以实现高可用(superior resiliency).

          基础架构：

                   服务注册中心：Eureka提供的服务器，提供服务注册和发现的功能

 

                   服务提供者：提供服务的应用，可以是SpringBoot应用，也可以是其他技术平台的且遵循Eureka通信机制的应用。它将自己提供的服务注册到Eureka Service上，以供其他应用发现。Eureka Server接收到这个Rest请求之后，将元数据信息存储在一个双层结构的Map中，其中第一层的key是服务名。第二层的key 是具体服务的实例名。

                   服务同步：不同的服务提供者可以注册在不同的服务注册中心上，它们的信息被不同的服务注册中心维护。

此时，由于多个服务注册中心互相注册为服务，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发给集群中相连的其他注册中心，从而实现服务注册中心之间的服务同步。通过服务同步，提供者的服务信息就可以通过集群中的任意一个服务注册中心获得。

                   服务续约：在注册服务之后，服务提供者会维护一个心跳用来持续高速Eureka Server，“我还在持续提供服务”，否则Eureka Server的剔除任务会将该服务实例从服务列表中排除出去。我们称之为服务续约。

 

                   服务消费者：消费者服务启动时，会发送一个Rest请求给服务注册中心，来获取上面注册的服务清单。为了性能考虑，Eureka Server会维护一份只读的服务注册清单来返回给客户端，同时该缓存清单默认会每隔30秒更新一次。

下面是获取服务的两个重要的属性：

（1）      eureka.client.fetch-registry

是否需要去检索寻找服务，默认是true

（2）eureka.client.registry-fetch-interval-seconds

表示eureka client间隔多久去拉取服务注册信息，默认为30秒，对于api-gateway，如果要迅速获取服务注册状态，可以缩小该值，比如5秒

                   服务调用：

                   服务消费者在获取服务清单后，通过服务名可以获取具体提供服务的实例名和该实例的元数据信息。因为有这些服务实例的详细信息，所以客户端可以根据自己的需要决定具体调用哪个实例，在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。

                   服务下线：

                   在系统运行过程中必然会面临关闭或重启服务的某个实例的情况，在服务关闭操作时，会触发一个服务下线的Rest服务请求给Eureka Server，告诉服务注册中心：“我要下线了。”服务端在接收到该请求后，将该服务状态置位下线（DOWN），并把该下线事件传播出去。

 

         服务治理机制：

         服务调用在Ribbon中会默认采用轮询的方式进行调用，从而实现客户端的负载均衡。

         服务注册：

                   在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，包括服务的主机与端口号、服务版本号、通讯协议等一些附加信息。注册中心按照服务名分类组织服务清单，同时还需要以心跳检测的方式去监测清单中的服务是否可用，若不可用需要从服务清单中剔除，以达到排除故障服务的效果。

         服务发现：

                   服务间的调用不再通过指定具体的实例地址来实现，而是通过服务名发起请求调用实现。服务调用方通过服务名从服务注册中心的服务清单中获取服务实例的列表清单，通过指定的负载均衡策略取出一个服务实例位置来进行服务调用。

Netflix Eureka既包含了服务端组件，也包含了客户端组件

Eureja服务端：

Eureka服务端，即服务注册中心。它同其他服务注册中心一样，支持高可用配置。依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。

Eureka服务端支持集群模式部署，当集群中有分片发生故障的时候，Eureka会自动转入自我保护模式。它允许在分片发生故障的时候继续提供服务的发现和注册，当故障分配恢复时，集群中的其他分片会把他们的状态再次同步回来。集群中的的不同服务注册中心通过异步模式互相复制各自的状态，这也意味着在给定的时间点每个实例关于所有服务的状态可能存在不一致的现象。

Eureja客户端：

Eureka客户端，主要处理服务的注册和发现。客户端服务通过注册和参数配置的方式，嵌入在客户端应用程序的代码中。在应用程序启动时，Eureka客户端向服务注册中心注册自身提供的服务，并周期性的发送心跳来更新它的服务租约。同时，他也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期行的刷新服务状态。

 

         1.2 Netflit Hystrix(断路器)

         熔断器，容错管理工具，作用主要体现一下几个方面：

保护和控制底层服务的高延迟和失效对上层服务的影响。

避免复杂分布式中服务失效的雪崩效应。在大型的分布式系统中，存在各种复杂的依赖关系。如果某个服务失效，很可能会对其他服务造成影响，形成连锁反应。

快速失效和迅速恢复。以Spring为例，一般在实现controller的时候，都会以同步的逻辑调用依赖的服务。如果服务失效，而且没有客户端失效机制，就会导致请求长时间的阻塞。如果不能快速的发现失效，而就很难通过高可用机制或者负载均衡实现迅速的恢复。

优雅地实现服务降级。个人理解，这一点是从用户体验来考虑的，一个预定义默认返回会比请求卡死或者500好很多。

实现了服务监控、报警和运维控制。Hystrix Dashboard和Turbine可以配合Hystrix完成这些功能。

 

Hystrix是怎么完成这些需求呢？个人觉得Hystrix的实现有以下几个关键点：

为服务调用设置超时时间；这一点非常容易理解，超时返回可以实现服务快速失效。

使用线程池来完成服务请求；线程池可以实现资源控制的作用。不同的依赖服务使用不同的线程池来完成请求，就可以实现服务依赖之间的隔离。这样就是Hystrix中比较常提起的“仓壁模式”。这种方式可以一定程度的抑制失效扩散。比如，服务A依赖于服务B和服务C，服务B宕机了，导致服务A中依赖于B的请求大量积压。如果没有隔离，依赖于服务C的请求的CPU时间将被严重压缩，甚至导致服务A中的依赖于B和C的请求都失败。

基于对请求的统计，Hystrix实现了服务监控。并且在服务失效达到一定的比例之后，直接熔断服务。因为，即使有超时，仍然有可能形成请求积压。在这种极端情况下，熔断机制就能发挥作用了，它会让请求直接失败。

 

         1.3 Netflix Zuul(服务网关)

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。

Netflix使用Zuul进行以下操作：

• 认证
• 洞察
• 压力测试
• 金丝雀测试
• 动态路由
• 服务迁移
• 负载脱落
• 安全
• 静态响应处理
• 主动/主动流量管理

服务网关=路由转发+过滤器

1.路由转发 ：接收一切外界请求，转发到后端的微服务上去；

2.过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验，限流以及监控等，这些都可以通过过滤器完成

引入服务网关后的微服务架构，总体包括三部分：服务网关，open-service和service

总体流程：

·服务网关、open-service和service启动时注册到注册中心上去；

·用户请求时直接请求网关，网关做智能路由转发（包括服务发现，负载均衡）到open-service，这其中包含权限校验、监控、限流等操作

·open-service聚合内部service响应，返回给网关，网关再返回给用户

 

 

         1.4 Netflix Ribbon(客户端负载均衡)

Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，Ribbon是一个客户端负载均衡器，我们可以在配置文件中Load Balancer后面的所有机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器，我们也很容易使用Ribbon实现自定义的负载均衡算法。

Ribbon工作时分为两步：第一步选择Eureka Server，它优先选择在同一个Zone且负载较少的Server；第二步再根据用户指定的策略，再从Server取到的服务注册列表中选择一个地址。其中Ribbon提供了很多策略，例如轮询round robin、随机Random、根据响应时间加权等。

 

2、Spring Cloud Config(配置中心)

配置管理工具包，让你可以把配置放在远程服务器，集中化集群配置，目前支持本地存储，Git以及Subversion

Spring Cloud Config 项目

• 提供 服务端 和 客户端 支持
• 集中式 管理分布式环境下的应用配置
• 基于 Spring 环境，无缝 与 Spring 应用集成
• 可用于 任何 语言开发的程序
• 默认实现基于 git 仓库，可以进行 版本管理
• 可替换 自定义实现

Spring Cloud Config Server 作为配置中心服务端

• 拉取配置时更新 git 仓库副本，保证是最新结果
• 支持数据结构丰富，yml, json, properties 等
• 配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新
• 配置存储基于 git 仓库，可进行版本管理
• 简单可靠，有丰富的配套方案