一、springCloud概念

  • SpringCloud，基于springboot提供了一套微服务解决方案，包括服务注册，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。

  • SpringCloud利用springboot的开发便利性巧妙的简化了分布式系统基础设施的开发，springcloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、为代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以利用springboot的开发风格做到一键启动和部署。

  • SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

二、SpingCloud与Dubbo的区别


  • RPC：客户端向服务器端发送请求，由服务器相应处理传回结果的方法被称为RPC（远程调用）,编程人员在编写页面的代码时需要透彻的理解各个函数的调用方法，以及相互之间的逻辑关系,这一系列的函数的理解都给编程增添了复杂度.
    REST：下载服务器端的当前状态，修改之后将最终用户所期待的状态发送给服务器，服务器按照客户的期待进行修改。而不同于RPC的也就是响应函数没有那么多的，复杂的逻辑关系，函数也减少了很多，只是get和post两个。从而给服务器减少了工作量而且在逻辑上也是符合的。表面上看来REST比RPC是要先进的，但是REST的缺点在于，这种只有get和post的逻辑并不是永远有效的，并不是对一切问题都是万能的。

  • 最大的区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。严格来说两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但是也避免了上面提到的原声RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

三、Eureka

eureka服务jar包

 <!--eureka-server服务端 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka-server</artifactId>
        </dependency>

@EnableEurekaServer

微服务jar包

<!-- 将微服务provider侧注册进eureka -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>
启动类需要注解
@EnableEurekaClient //本服务启动后会自动注册进eureka服务中

SpringCloud 封装了Netflix公司开发的Eureka模块来实现服务的注册和发现。其采用了C-S的设计架构。Eureka作为服务注册功能的服务器，他是服务注册中心，而系统种的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统种各个微服务是否正常运行。SpringCloud的一些其他模块（比如Zuul）就可以通过EurekaServer来发现系统种的其他微服务，并执行相关的逻辑。

Eureka包含两个组件：Eureka Server和Eureka Client

  • Eureka Server提供服务注册，各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。

  • EurekaClient是一个java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的、使用轮询（round-robin）负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳（默认30s）。如果EurekaServer在多个心跳周期内没有接到到某个心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90s）。

  • Eureka的自我保护机制：好死不如赖活着！默认情况下，如果EurekaServer在一定的时间内没有接收到某个微服务的实例心跳，EurekaServer将会注销该实例（默认90s）。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险——因为微服务本身其实是健康的，此时不应该注销这个微服务。Eureka通过“自我保护机制”，来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护微服务表中的信息，不再删除微服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该EurekaServer节点会自动推出自我保护模式。
    在SpringCloud中，可以使用eureka.server.enable-self-preservation = false禁用自我保护模式。

注：在本地配置的时候C:\Windows\System32\drivers\etc中的hosts文件需要域名映射，如下：

127.0.0.1       eureka7001
127.0.0.1       eureka7002
127.0.0.1       eureka7003

CAP：（C:强一致性；A:可用性；P:分区容错性）

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前网络硬件肯定会出现延迟丢包等问题，所以P（分区容错性）是我们必须要实现的。

Eureka与Zookeeper的区别：eureka遵守AP，zookeeper遵守CP
Zookeeper保证CP，如下：

Eureka保证AP，如下：

四、Ribbon

<!-- Ribbon相关 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-ribbon</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-config</artifactId>
        </dependency>

  • Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端，负载均衡的东西。
    简单的说，Ribbon是Netflix发布的开源项目，主要的功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务链接在一起。Ribbon客服端组件提供一系列完善的配置项如连接超时，重试等。换句话说，就是在配置文件中列出Load Balance（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易适用Ribbon实现自定义的负载均衡算法。

  • LB，即负载均衡，在微服务或分布式集群中经常用的一种应用。负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统HA（高可用）。常见的的负载均衡软件有Nginx,LVS,硬件F5等，相应的中间件，例如：dubbo和SpringCloud中给我们提供的负载均衡，SpringCloud的负载均衡算法可以自定义。

  • 集中式LB，偏向硬件；进程内LB，偏向软件，Ribbon属于进程内LB

Ribbon和Eureka整合后Consumer可以直接调用服务而不用再关心地址和端口号。

IRule：根据特定算法中从服务列表中选取一个要访问得服务，提供了7种，如下：

自定义规则，方法如下：

注：MySelfRule.class

五、Feign

  • Feign是一个声明式WebService客户端。使用Feign能让WebService客户端更加简单，它的使用方法是定义一个接口，然后在上面添加注解，同时也支持JAX-RS标准的注解。Feign也支持可拔插式的编程和解码器。SpringCloud对Feign进行了封装，十七支持SpringMvc标准注解和HttpMessageConverters。Feign可以与Eureka和Ribbon组合使用以支持负载均衡。

六、Hystrix

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
        </dependency>

  1. Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

  2. “断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过段断路器监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要的占用，从而避免故障在分布式系统中的蔓延、乃至雪崩。

  3. 服务熔断
    熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。熔断机制的注解时：@HystrixCommand，主启动类上的注解：@EnableCircuitBreaker

  4. 服务降级
    所谓降级，一般是从整体符合考虑。就当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。这样做，虽然服务水平下降，但是好歹可用，比直接挂掉强。
    具体操作如下：
    定义一个类DeptClientServiceFallbackFactory，实现FallbackFactory，重写方法即可。类注解：@Component，并在接口处调用使用：@FeignClient(value = “MICROSERVICECLOUD-DEPT”,fallbackFactory=DeptClientServiceFallbackFactory.class)

  5. 服务监控（Hystrix Dashboard）

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
        </dependency>

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起地请求地执行信息，并以统计报表和图形地形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项目实现了对以上指标地监控。SpringCloud也提供了HystrixDashboard地整合，对监控内容转换成可视化界面。
实心圆：共有两种含义，它通过颜色的变化代表了实例的健康程度，它的健康度从绿色<黄色<橙色<红色 递减。该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆也就越大。所以通过该实心圆的展示就可以在大量的实例中快速的发现故障实例和高压实例。

七、Zuul 路由网关

 		<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zuul</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>

Zuul包含了对请求的路由和过滤两个主要的功能：其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础；而过滤功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得的。
注：Zuul服务最终还是会注册进Eureka。

八、SpringCloud Config

		<!-- springCloud Config -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
        <!-- 避免Config的Git插件报错：org/eclipse/jgit/api/TransportConfigCallback -->
        <dependency>
            <groupId>org.eclipse.jgit</groupId>
            <artifactId>org.eclipse.jgit</artifactId>
            <version>4.10.0.201712302008-r</version>
        </dependency>

SpringCloud Config为微服务架构中得微服务提供集中化得外部配置支持，配置服务器为各个不同微服务应用得所有环境提供了一个中心化得外部配置。
**注：使用bootstrap.yml，其优先级高于application.yml**
Spring Cloud Config分为服务端和客户端两部分：

  1. 服务端也成为分布式配置中心，它是一个独立的微服务应用，用来链接配置服务器并未客户端提供获取配置信息，加密/解密信息等访问接口。

  2. 客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理，并且可以通过git客户端工具来方便的管理和访问配置内容。

更多推荐

Spring Cloud五大核心详解