SpringCloud的五大件

思维导图

• 服务发现——Netflix Eureka
• 客服端负载均衡——Netflix Ribbon
• 断路器——Netflix Hystrix
• 服务网关——Netflix Zuul
• 分布式配置——Spring Cloud Config

1 基于Eureka（服务注册中心）的服务治理

Eureka它主要包括两个组件：Eureka Server 和 Eureka Client

• Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端）

• Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心）

  执行流程：

具体流程：

• 服务生产者启动，向服务注册中心注册自己提供的服务
• 服务消费者启动，向服务组织中心订阅自己需要的服务
• 注册中心返回服务提供者的地址信息给消费者
• 消费者从提供者调用服务

1.1.1Eureka与Zookeeper的区别

CAP：一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择

4.1 Zookeeper保证CP，并且当使用的语言和java语言是无法使用其他语言，基于为socket

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

4.2 Eureka保证AP，基于Http

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

2Ribbon（是一个基于 HTTP 和 TCP 客户端 的负载均衡的工具 ）

作用：

负载均衡：

feign（声明式服务调用）：

因为feign底层是使用了ribbon作为负载均衡的客户端，而ribbon的负载均衡也是依赖于eureka 获得各个服务的地址，所以feign整合了ribbon和eureka。

Ribbon和Feign的区别：

1.Ribbon模拟http请求

用 REST_URL_PREFIX 指定请求地址 ， 使用 restTemplate 模拟 http 请求。

private static final String REST_URL_PREFIX = "http://qc";

	@Autowired
	private RestTemplate restTemplate;

	@RequestMapping(value = "/test/add")
	public boolean add(Dept dept) {
		return restTemplate.postForObject(REST_URL_PREFIX + "/test/add", dept, boolean .class);
	}

2.Feign

添加@FeignClient 注解，指定微服务名称 qc ) 指定请求地址 @RequestMapping 指明方法名qc

@FeignClient("qc")
public interface   Qcservice {
    @GetMapping("/qc")
    String qc();
   }

feign只需要指明服务名和服务的方法名，然后使用接口调用即可，在代码的抒写上，比Ribbon减少很多

3.zuul网关

**网关的作用：**微服务网关介于服务端与客户端的中间层，所有外部服务请求都会先经过微服务网关客户只能跟微服务网关进行交互，无需调用特定微服务接口，使得开发得到简化 。只需要在配置文件中进行如下配置，通过在网关的地址访问路径即可，大大减少了开发难度。并且所以请求访问时，可以通过权限效验

   zuul:
        routes:
          aa.path: /zuul/**  #访问的路径
          aa.serviceId: eureka-qtd  #需要访问的服务名称    然后在后面接controller的方法映射名
          aa.retryable: true  #连接失败后，重试连接

若不使用网关：

（1）客户端会多次请求不同微服务，增加了客户端复杂性，我们需要不断的在代码里面写入对应服务名的ip地址，当其中一个IP地址发生改变，会减少我们的开发更改代码的便利性

（2）存在跨域请求，处理相对复杂

（3）认证复杂，每个服务都需要独立认证

（4）难以重构，项目迭代可能导致微服务重新划分。如果客户端直接与微服务通讯，那么重构将会很难实施。

4. hystrix断路器

一条公路上，许多车辆排队前行，但是他们不知道前面的路不通，当发现的时候已经晚了，许多车都退不出去了。但是车还是在源源不断的前进。如果之前在路的前面里一个牌子“此路不通，请绕行”，那么这个情况就不会发生。这个牌子就是断路器，防止微服务的雪崩。这条公路就是服务组件，防止大量请求访问该Servlet消耗线程资源，导致瘫痪。如果使用断路器，可以避免连锁反应，fallback调用其他方法换回一个固定值来判断该服务是否挂掉。

雪崩效验：当A不可用时，B调用A则会失败，则会出现线程阻塞，如果这个时候出现大量请求，那么B也会挂掉，

开始只是B到A的路线挂断，那么现在就是B到其他的都路线全部挂掉，servlet容器的线程资源就会被消耗完毕导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成不可估量的严重后果

5.Spring Cloud Config

​ 统一管理配置文件，使更改配置文件的操作更加方便。客户端通过https协议主动的拉取服务的的配置信息，完成配置获取。

​ 在开发时，配置文件通常会呗放入单个模块中，配置文件是为了能够更好的更改地址，数据库配置从而出现，但是如果我们要更改配置文件，则需要进入到模块中更改。 如果我们将它们统一到一个模块中则会大大减少更改配置文件的难度

配置文件

# 和git里的文件名对应
spring.application.name=test
# 远程仓库的分支
spring.cloud.config.label=master
# dev 开发环境配置文件 |  test 测试环境  |  pro 正式环境
# 和git里的文件名对应
#spring.cloud.config.profile=default
# 指明配置服务中心的网址
spring.cloud.config.uri= http://localhost:8888/
server.port=8080

@SpringBootApplication
@RestController
public class SpringCloudConfigClient {
    public static void main(String[] args) {
        SpringApplication.run(SpringCloudConfigClient.class, args);
    }
    @Value("${name}")
    String name;

    @RequestMapping("/getName")
    public String getName(){
        return name;
    }
}
则会返回一个“test”的值

ass, args);
}
@Value("${name}")
String name;

@RequestMapping("/getName")
public String getName(){
    return name;
}

}
则会返回一个“test”的值