SpringCloud的简单使用_spring cloud使用

---

前言

记录学习SpringCloud

SpringCloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。（百度百科）

微服务架构核心问题

1.服务很多，客户端怎么访问？

2.服务很多，服务之间如何通信？

3.服务很多，如何治理？服务注册与发现

4.服务挂了怎么办？

解决方案：

1.SpringCloud NetFilx

​ 一站式解决方案

服务多，用API网关zuul组件

通信问题，Feign基于httpclient，http同步阻塞 

服务注册与发现，Eureka

熔断机制，Hystrix
1
2
3
4
5
6
7

2.Apache Dubbo Zookeeper

半自动需要整合别人的

没有api网关，需要自己找组件，或者自己实现
通信方式Dubbo，RPC
服务注册与发现，Zookeeper
没有，借助Hystrix
1
2
3
4

3.SpringCloud Alibaba

一站式解决方案

新概念：服务网格，istio

关键：

1.API

2.通信

3.服务注册和发现

4.熔断机制

配置

application.yaml 用户级别的配置

bootstrap.yaml 系统级别的配置 优先度高

微服务技术栈

SpringCloud和Springboot关系

Springboot构建微服务，专注于开发微服务

SpringCloud协调微服务，关注微服务协调的治理框架，将Springboot开发的一个个微服务整合起来，提供：配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁，决策竞选，分布式会话等

Springboot可以离开SpringCloud，但是SpringCloud不能离开Springboot

Dubbo和SpringCloud技术选型

分布式+服务治理Dubbo

成熟的互联网架构：应用服务化拆分+消息中间件

Dubbo和SpringCloud对比

看社区活跃度github

区别

最大的区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于Http的REST方式

SpringCloud牺牲了服务调用性能，但是避免了RPC带来的问题，REST比RPC更灵活

分布式结构图

官网的版本问题

学习参考网站

Spring Cloud Netflix： https://springcloud.cc/spring-cloud-netflix.html

Spring Cloud： https://springcloud.cc/spring-cloud-dalston.html

Spring Cloud中国社区： http://springcloud.cn/

Spring Cloud中文网： https://springcloud.cc

Euraka

服务注册与发现

采用的是AP原则

NetFlix的子模块之一

基于REST风格

采用的CS架构，EurekaService作为服务注册功能的服务器，他是服务注册中心

系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接

心跳：每隔一段时间发送消息，如果没有，就认为死亡

就可以通过心跳来监控各个微服务是否正常运行

Eureka Client是一个java客户端，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器，在应用启动后，会想EurekaServer发送心跳默认是30秒，如果EurekaServer在多个心跳周期内没有接收到某个节点的心跳，EurkaServer将会从服务注册列表中把这个服务节点移除掉，默认是90秒

一般的步骤是

导入依赖

编写配置文件

开启这个功能@Enable功能

配置类

三大角色

Eureka Service：提供服务注册与发现,zookeeper客户端

Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到

Service Consumer：服务消费方从Eureka中获得注册服务列表，从而找到消费服务

Ribbon负载均衡

NetFlix里的客户端负载均衡的工具

主要提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起，就是在配置文件中列出LoadBalancer（简称LB，负载均衡）后面所有的机器

LoadBalancer，LB，负载均衡

负载均衡有一种方法是轮询，如果有5个服务器，第一个人是第一个服务器，第二个人是第二个服务器，第三个人是第三个服务器，不断轮询，减少每一个服务器的压力

另一种为随机连接

Ribbon作用：

负载均衡简单来说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）

常见的负载均衡软件有Nginx，Lvs（中国开发的linux虚拟服务器）等等apache+tomact也可以

dubbo、Springcloud中均提供了负载均衡，Springcloud的负载均衡算法可以自定义

负载均衡减分分类：

1.集中式LB：

即在服务的消费方和提供方之间使用独立的LB设施，如Nginx（反向代理服务器）由该设施负责把访问请求通过某种粗略转发至服务的提供方

2.进程式LB：

将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器

Ribbon就属于进程内LB，他只是一个类库，集成于消费方进程，消费方通过他来获取到服务提供方的地址

Ribbon通过服务注册中心获得服务列表，然后通过负载均衡算法来选择服务的提供者

Feign负载均衡

Feign是声明式的web serveer客户端，使用Feign提供负载均衡的Http客户端

Feign是通过接口和注解进行微服务访问

Ribbon是通过微服务名字

Feign使代码可读性变高，但是性能稍差一点点

Hystrix服务熔断

用于处理分布式系统的延迟和容错，Hystrix能够保证在一个依赖出问题后，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性

当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个服务预期的，可处理的备选响应，而不是长时间的等待或者抛出调用方法无法处理的异常，这样可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩

https://github.com/Netflix/Hystrix/wiki

**也就是说，当一连串的服务中有一个服务I崩溃后，服务熔断系统将服务I进行一个复制，但不是复制功能，而进行一个服务替换，也就是将服务I替换成服务I1，这样整体的服务就不会崩溃，服务I1的作用是给客户端返回一些错误信息或者异常信息等情况。**最重要的就是，整体服务不会因为一个服务崩溃，而全盘崩溃

服务降级

当有A,B,C三个服务的时候，A服务爆满，B,C服务很少使用的时候，可以先将B,C关闭，腾出内存给A使用

熔断是在消费者，服务端，某一个服务超时或者异常，引起熔断，

降级是在消费者，客户端，从整体网站请求负载考虑，当某个服务熔断或关闭后，服务不在被使用，但是仍旧正常访问，，可以在客户端可以准备一个FallbackFactory，返回一个默认值（缺省值），整体的服务水平下降了，好歹能用，比直接挂掉强

服务监控

设置一个新的微服务，导入dashboard包，修改端口号， 在主启动类中加入开启注解，服务端需要actuator，还需要增加dashboardbean

http://localhost:9001/hystrix

进入监控页面，

灰色最近10s错误百分比，绿色是成功，黄色超时数，红色失败异常数，蓝色熔断数，青色错误请求数

host服务请求频率，circuit断路状态

服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C又调用其他的微服务，这就是所谓的：扇出。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的雪崩效应

服务熔断

熔断机制是雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息

熔断机制的注解是@HystrixCommand

Hystrix作用：

服务降级

服务熔断

服务限流

接近实时的监控

Zuul路由网关

用来隐藏localhost本机地址

包含了对请求的路由和过滤两个重要功能

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。路由是用来跳转

过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。

zuul和Eureka进行整合，将zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

zuul服务最终还是会注册进Eureka

提供：代理+路由+过滤三大功能

https://github.com/Netflix/zuul

用户需要先进入网关才能进入服务

SpringConfig配置中心

用来解决很多微服务自己带着的application.yaml问题，也就是说将多个服务的配置文件放在配置管理中心，方便修改和增加

分为服务端和客户端

客户端是微服务，服务端指配置中心是一个独立的微服务

配置服务器默认采用git来存储配置信息，有助于对环境配置进行版本管理，并可以通过git客户端工具来方便的管理和访问配置内容

功能

集中管理配置文件

不同环境，不同配置，动态化的配置更新，分环境部署，比如/dev/test/prod/beta/release

运行期间动态调整配置，不需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息

当配置发生变动时，服务不需要重启，即可感知到配置的变化，并应用新的配置

将配置信息以REST接口的形式暴露

首先生成SSH密钥
在想要的位置，创建Git目录
git clone 地址        复制仓库文件
修改文件
git add .     添加修改的文件到缓存区
git status    查看更新了什么文件
git commit -m "first commit" 将修改的文件提交
git push 
将文件上传到github

1
2
3
4
5
6
7
8
9
10

config服务

导包config，actuator，web
写配置文件
启动类开启服务
通过端口号访问
http://localhost:3344/application-dev.yaml
访问格式看文档
1
2
3
4
5
6

配置文件

server:
  port: 3344
spring:
  application:
    name: springcloud-config-server
  cloud:
    config:
      server:
        git:
          uri: https://gitee.com/HoneySquid/springclouds.git  # https
          username: 13191810255
          password: jinhang1
1
2
3
4
5
6
7
8
9
10
11
12

实例

提供者和消费者

Eureka服务

当注册的服务被突然停止后，会等待30秒后，报错，出现保护机制

如果某一个时刻，一个微服务不可用后，Eureka不会立刻清理掉，而是继续保存该微服务的信息，但是无法访问。

可以使用配置，把自我保护模式禁用，但是不推荐

监控信息

监控信息配置

<!--完善监控信息actuator-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
1
2
3
4
5

配置好后，status的url就可以访问，并且有配置的信息出现

Eureka集群

CAP原则

C：强一致性

A：可用性

P：分区容错性

CAP的三进二：CA,AP,CP,也就是说，会满足2个其中的两个条件，必不可能是3个

nosql和mongdb满足CAP原则

CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差

CP：满足一致性，分区容错性的系统，通常性能不是特别高

AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

P是要一定满足的，所以一般是CP或者AP

Zookeeper保证是CP

当向注册中心查询服务列表时候，可以容忍注册中心返回的是几分钟以前的注册信息，但不接受服务直接down掉。zookeeper会出现这种情况，当master节点因为网络故障与其他节点失去联系的时候，剩下的节点会重新进行leader选举。而选举时间很长，30s-120s，而且选举期间整个zk集群都是不可用的，会导致服务瘫痪

Eureka保证是AP

Eureka设计的时候优先保证了可用性，Eureka各个节点都是公平的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务，Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换其他节点，只要一个Eureka还在，就能保证注册服务的可用性，只是，查到的信息可能不是最新的。

除此之外，Eureka还有自我保护机制，如果15分钟内超过85%的节点都没有正常心跳，那么Eureka就认为客户端与注册中心发生网络故障，会出现以下情况

1、Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务

2、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）

3、当网络稳定时，当前实例新的注册信息会被同步到其他节点中

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

Ribbon

自定义负载均衡算法

负载均衡的核心实现为

IRule
实现类
AvailabilityFilteringRule ：会先过滤掉，（跳闸）崩溃的服务，剩下的进行轮询
RoundRobinRule 轮询：
RandomRule:随机
RetryRule:会先按照轮询获取服务，如果服务获取失败，则会在指定的时间内进行

继承AbstractLoadBalancerRule类
1
2
3
4
5
6
7
8