SpringCloud入门使用

SpringCloud: 微服务架构(一堆技术,大概21种之多)
服务: 一个Tomcat就指一个服务,指一个应用程序
微服务的概念: (单,微,独)

分布式: 把一个大项目,根据业务需求拆分成多个服务,部署在不同的服务器上,分布式开发,分布式部署
高并发: 系统运行过程中,短时间内遇到大量请求
高可用: 侧重备份机器， 利用集群中系统 的冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来启动服务。在极端的环境下,也可以正常提供服务,哪怕是网线断了
负载均衡: 假如一台机器不能满足高并发的请求访问，那么就两台，两台还满足不了就增加到三台，这种方式我们称之为水平扩展，如何实现请求的平均分配便是负载均衡了。
集群: 就是把多个相同的代码搭建到多台服务器上.集群之后必须负载均衡;想要负载均衡必须集群
rpc: 远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。那么我们至少从这样的描述中挖掘出几个要点：
cap: 它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）
可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。）

---

微服务注册中心Eureka

原理图解

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。Eureka说白了就是一个注册服务中心。
1.导jar包
2.加注解
3.加配置(yml)

创建EurekaServer服务端时勾选会自动导入Eureka的jar包

在启动类上加注解@EnableEurekaServer

注册到Eureka的服务,目前有一个

---

Eureka客户端

<!-- Eureka客户端 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

消费者从Eureka获取服务

服务续约

服务提供者在Eureka注册后,会维持一个心跳,告诉EurekaServer：“我还活着”。这个我们称为服务的续约（renew）；
修改服务续约

eureka:
  instance:
    lease-expiration-duration-in-seconds: 2 # 2秒即过期
    lease-renewal-interval-in-seconds: 1 # 1秒一次心跳

负载均衡Ribbon

将请求分到不同的服务器(轮询,随机),默认方式是轮询

源码追踪

这个类通过提供者名称帮我们获得了Ip和端口号

继续追踪,可以看到,我们的两次请求分发到了不同的服务器

修改负载均衡的规则的方法

user-service: ribbon: NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
格式是：{服务名称}.ribbon.NFLoadBalancerRuleClassName，值就是IRule的实现类。

重试机制

因为服务剔除的延迟，consumer并不会立即得到最新的服务列表，此时再次访问你会得到错误提示：

因此Spring Cloud 整合了Spring Retry 来增强RestTemplate的重试能力，当一次服务调用失败后，不会立即抛出异常，而是再次重试另一个服务。
当访问到某个服务超时后，它会再次尝试访问下一个服务实例，如果不行就再换一个实例，如果不行，则返回失败。切换次数取决于MaxAutoRetriesNextServer参数的值

引入spring-retry依赖

<dependency>
	<groupId>org.springframework.retry</groupId>  
	<artifactId>spring-retry</artifactId>
</dependency>

Hystrix熔断器

Hystrix相当于服务隔离,在高并发领域,分布式系统中,可能因为一个小功能扛不住压力宕机了,导致其他服务也跟着宕机,最终导致整个系统宕机,采用Hystrix处理,可以有效保护其他服务正常提供服务
服务器超过1s就会熔断
服务降级: 当服务繁忙时,如果服务出现异常,不是粗暴的直接返回报错,而是返回一个友好的提示,虽然拒绝了用户的访问,但是会返回一个结果
Hystrix工作机制

测试
pom文件内导入熔断器的坐标

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

在消费者启动类添加注解,开启熔断

声明一个失败时的回滚函数

优化

重试机制的默认时间和熔断的默认时间均为1000ms,所以先执行了熔断机制,因此,重试机制的时间要小于熔断的默认时间

Feign 远程调用

把Rest的请求进行隐藏,不用自己拼接url,拼接参数, 一切都交给feign去做,大大简化了调用服务时的代码.但是Feign的使用限制于SpringCloud的项目,RestTempLate的使用场景更为广泛
导入依赖

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

开启feign功能

feign客户端

调用

ZUUL 网关

三个必须具备的功能:鉴权,动态路由,负载均衡

使用
添加zuul依赖

在启动类添加注解,开启zuul功能

zuul整合Eureka客户端,实现动态路由,默认路由规则,服务名称的本身

zuul实现请求鉴权,我们一般通过zuul提供的过滤器实现