SpringCloud的简单使用

最新推荐文章于 2024-04-30 11:53:50 发布

蜂蜜蘸鱿鱼脚

最新推荐文章于 2024-04-30 11:53:50 发布

阅读量924

点赞数

分类专栏： Java 文章标签： spring cloud java dubbo

本文链接：https://blog.csdn.net/weixin_43287895/article/details/126465855

版权

Java 专栏收录该内容

14 篇文章 0 订阅

订阅专栏

前言

记录学习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

2.Apache Dubbo Zookeeper

半自动需要整合别人的

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

3.SpringCloud Alibaba

一站式解决方案

新概念：服务网格，istio

关键：

1.API

2.通信

3.服务注册和发现

4.熔断机制

配置

application.yaml 用户级别的配置

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

微服务技术栈

微服务条目	落地技术
服务开发	Springboot，Spring，SpringMVC
服务配置与管理	Netfilx公司的Archaius，阿里的Diamond
服务注册和发现	Eureka，Consul，Zookeeper
服务调用	Rest，RPC,gRPC
服务熔断器	Hystrix，Envoy
负载均衡	Ribbon，Nginx
服务接口调用（客户端调用服务的简化工具）	Feign
消息队列	Kafka，RabbitMQ，ActiveMQ
服务配置中心管理	SpringCloudConfig，Chef
服务路由（API网关）	Zuul
服务监控	Zabbix，Nagios，Metrics，Specatator
全链路追踪	ZipKin，Brave，Dapper
服务部署	Docker，OpenStack，Kubernetes
数据流操作开发包	SpringCloud Stream（封装与Redis，Rabbit，Kafka等发送接收消息
事件消息总线	SpringCloud Bus

SpringCloud和Springboot关系

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

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

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

Dubbo和SpringCloud技术选型

分布式+服务治理Dubbo

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

Dubbo和SpringCloud对比

看社区活跃度github

区别

	Dubbo	Spring
服务注册中心	Zookeeper	SpringCloud Netfilx Eureka
服务调用方式	RPC	REST API
服务监控	Dubbo-monitor	SpringBoot Admin
断路器	不完善	Spring Cloud Netfilx Hystrix
服务网关		Spring Cloud Netfilx Zuul
分布式配置		Spring Cloud Config
服务跟踪		Spring Cloud Sleuth
消息总线		Spring Cloud Bus
数据流		Spring Cloud Stream
批量任务		Spring Cloud Task

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

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

分布式结构图

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UD1fnlEO-1661150671461)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220627163706973.png)]$

官网的版本问题

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yfufKs5J-1661150671464)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220627165147614.png)]$

学习参考网站

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

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IMdOHceu-1661150671465)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220822144339255.png)]$

**也就是说，当一连串的服务中有一个服务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问题，也就是说将多个服务的配置文件放在配置管理中心，方便修改和增加

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6W3RQx7V-1661150671466)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220706165456319.png)]$

分为服务端和客户端

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

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

功能

集中管理配置文件

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

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

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

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

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

config服务

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

配置文件

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

实例

提供者和消费者

Eureka服务

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xgfIVDDx-1661150671467)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220630165829912.png)]$

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

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-12KaI0BB-1661150671469)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220630165959797.png)]$

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

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

监控信息

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-V6Ah1E8F-1661150671469)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220630170058643.png)]$

监控信息配置

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

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

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dHgE6XLf-1661150671471)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220630171626962.png)]$

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

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JjopFwe9-1661150671472)(C:\Users\77278\AppData\Roaming\Typora\typora-user-images\image-20220702190112092.png)]$

自定义负载均衡算法

负载均衡的核心实现为

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

继承AbstractLoadBalancerRule类