springcloud学习笔记

最新推荐文章于 2024-06-01 16:19:57 发布

zm98

最新推荐文章于 2024-06-01 16:19:57 发布

阅读量1.1k

点赞数 4

分类专栏：心得总结文章标签： springcloud

本文链接：https://blog.csdn.net/zm9898/article/details/90143505

版权

心得总结专栏收录该内容

33 篇文章 1 订阅

订阅专栏

别人的springcloud学习笔记
完整参考老师的思维导图（百度云盘中有）

搭建微服务的4个基础工程（springboot）

一个主工程，其它都是moudle

parent工程，存放版本号和依赖
api工程，存放通用的实体类
部门生产者工程，查询添加部门controller，service，dao都有
部门消费者工程，只写controller，用spring提供的restTemplate发送rest请求获取生产者工程的数据。

springcloud的服务注册中心（eureka）

eureka分为server端和client端

创建server工程加入server的maven坐标依赖，使得该工程成为一个server。
配置yml的server相关信息
在启动类上使用注解启动服务@EnableEurekaServer
测试localhost:工程端口号

将已有的部门微服务注册进eureka

加入maven依赖坐标

        <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>

配置yml的相关信息
在启动类上使用注解启动服务

微服务完善

对访问eureka服务端项目后显示的微服务列表页面进行完善

主机映射名称修改

修改yml的instance ：instance-id,这样在eureka的注册中心，显示的微服务名称就发生了变化

instance:
    instance-id: microservicecloud-dept8001

主机ip信息提示

修改yml

prefer-ip-address: true     #访问路径可以显示IP地址

微服务info内容的详细信息

修改pom.xml

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

在总的父工程的pom.xml中添加构建信息

<build>
		<finalName>microservicecloud</finalName>
		<resources>
			<resource>
				<directory>src/main/resources</directory>
				<filtering>true</filtering>
			</resource>
		</resources>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-resources-plugin</artifactId>
				<configuration>
					<delimiters>
						<delimit>$</delimit>
					</delimiters>
				</configuration>
			</plugin>
		</plugins>
	</build>

修改微服务工程中我yml文件

info: 
  app.name: atguigu-microservicecloud
  company.name: www.atguigu.com
  build.artifactId: $project.artifactId$
  build.version: $project.version$

到此别人在eureka服务端页面点击微服务名称就可以看见这个微服务的简介

eureka的自我保护机制

好死不如赖活着

  一句话一个微服务现在不可以用了，eureka不会马上清理，而是保存了微服务的信息

eureka的服务发现discovery（不是重点，了解即可）

类似于淘宝买东西后的快递信息可以通过第三方接口拿到

eureka的集群配置

新建另外两个server端工程
按7001工程修改pom.xml
按7001工程修改启动类注解
在host文件中配置三个域名映射，都是指向127.0.0.1
三个工程的yml文件需要修改

server: 
  port: 7001
 
eureka: 
  instance:
    hostname: eureka7001.com #eureka服务端的实例名称
  client: 
    register-with-eureka: false     #false表示不向注册中心注册自己。
    fetch-registry: false     #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    service-url: 
      #单机 defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/       #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。
      defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

server:
port: 7001

eureka:
instance:
hostname: eureka7001.com #eureka服务端的实例名称
client:
register-with-eureka: false #false表示不向注册中心注册自己。
fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
service-url:
#单机 defaultZone: http:// ${eureka.instance.hostname}:$ {server.port}/eureka/ #设置与Eureka Server交互的地址查询服务和注册服务都需要依赖这个地址（单机）。
defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/

每一个server工程都要配置知到其他的server端，以及重新配置instance.hostname

eureka和zookeeper对比

百度了解ACID和CAP
cap是分布式系统的三个指标
其中cap定理：只能满足其中的两个，也就是3选2
（容错性，一致性，可用性）

不同区域可能无法通信
区域的数据不一致
用户不管访问哪个区域都要有回应

点我cap原理介绍
p一般一定成立，c和a会产生矛盾

一致性和可用性，为什么不可能同时成立？答案很简单，因为可能通信失败（即出现分区容错）。
如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。
如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。
综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

经典cap图

作为服务注册中心，Eureka比Zookeeper好在哪里
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
因此
Zookeeper保证的是CP,
Eureka则是AP。
4.1 Zookeeper保证CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
4.2 Eureka保证AP
Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：
1 Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2 Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
3 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

ribbon（客户端负载均衡工具）

注意：是客户端负载均衡工具

在consumer-dept-80消费者工程的pom.xml中加入坐标
修改yml文件
对ConfigBean进行新注解@LoadBalanced 获得Rest时加入Ribbon的配置
启动类添加注解

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

到此我们只有一个8001的服务提供者，现在我们要测试ribbon的负载均衡还需要创建服务提供者8002,8003创建的方式参靠8001工程，创建三个数据库，然后修改配置文件
注意：

端口要改，还有数据库配置，instance-id也要改，但是application-name不能改
请求consumer消费者工程，测试Ribbon的客户端负载均衡完成。
注意：上面没有配置ribbon的均衡算法，所以它用的轮询算法

使用irule改变ribbon的均衡算法

在配置类中配置

@Bean
	public IRule myRule()
	{
		//return new RoundRobinRule();
		//return new RandomRule();//达到的目的，用我们重新选择的随机算法替代默认的轮询。
		return new RetryRule();
	}

自定义irule均衡算法

主启动类添加@RibbonClient
@RibbonClient(name=“MICROSERVICECLOUD-DEPT”,configuration=MySelfRule.class)

官方文档明确给出了警告：
这个自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下，
否则我们自定义的这个配置类就会被所有的Ribbon客户端所共享，也就是说
我们达不到特殊化定制的目的了。

新建package com.atguigu.myrule
新建自定义Robbin规则类，参考官方写的规则类
测试

feign负载均衡

feign就是接口加注解的声明式web服务调用
Ribbon是调用微服务的名称获取服务，而许多程序员更习惯于接口加注解的调用方式，feign就是为了补充这个问题的

创建一个接口，然后加一个注解就可以了。

前面我们用的是Ribbon+RestTemplate，面向template编程
而feign是面向接口编程

feign集成了Ribbon，使用轮询算法实现负载均衡

参考消费者工程80创建一个fegin的消费者工程
加入pom.xml依赖
修改api工程（接口写在api工程中方便以后其他的工程调用）
对api工程加入pom.xml依赖
在api工程中新建接口并在接口上添加注解@FeignClient
mvn clean mvn install
在fegin消费者工程中新建controller，里面使用api工程中的接口
修改fegin工程中启动类的注解@EnableFeignClients
启动eureka集群和服务提供者集群，然后再启动fegin工程
测试

   Feign通过接口的方法调用Rest服务（之前是Ribbon+RestTemplate），
该请求发送给Eureka服务器（http://MICROSERVICECLOUD-DEPT/dept/list）,
通过Feign直接找到服务接口，由于在进行服务调用的时候融合了Ribbon技术，所以也支持负载均衡作用。

Hystrix断路器

防止在分布式系统中A调用B，B调用C，C。。。。某一个服务不可用的时候，导致整个分布式系统长期等待，占用资源，导致服务崩溃。这时Hystrix类似于保险丝，直接断开某个服务，向调用者返回一个可以处理的错误信息，防止发生雪崩效应。

使用注解是在服务端实现
使用参考老师的思维导图
注意使用解耦和，防止熔断注解和实际方法耦合度太高

修改microservicecloud-api工程，根据已经有的DeptClientService接口新建一个实现了FallbackFactory接口的类DeptClientServiceFallbackFactory

服务降级

当系统的整体资源不够用时，忍痛将某些服务先关掉，等到度过难关后在开启

服务降级处理是在客户端实现，与服务端没有关系

HystrixDashboard监控管理

参考脑图搭建工程

Zuul路由网关

Zuul是什么？

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

参考脑图配置

springcloud的config配置中心

是什么？

可以简单的理解为帮助我们管理各个微服务的配置信息（yml文件），config可以借助github实现。

config配置中心分为服务端和客户端，服务端工程将配置文件通过git上传到github上远程存储，客户端工程新建一个bootstrap.yml文件
application.yml是用户级的配置文件，bootstrap.yml是系统级的配置文件，优先级更高
bootstrap.yml中url是连服务端工程，因为服务端工程连接了github的库，所以在bootstrap.yml中的name属性就可以找到对应的配置文件，bootstrap.yml中的profile指定使用了哪个配置(一般是dev和product)