springCloud详情笔记

最新推荐文章于 2024-06-29 18:33:45 发布

未来可期MXH

最新推荐文章于 2024-06-29 18:33:45 发布

阅读量252

点赞数

分类专栏： springCloud 文章标签： spring spring boot 后端

本文链接：https://blog.csdn.net/qflyIT/article/details/104554443

版权

springCloud 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1.常见问题

1.1springCloud和dubbo的主要区别是什么？

通信机制的不同：dubbo采用的是RPC远程过程调用，springCloud是基于RESTful调用

1.2 springCloud和springBoot的关系

SpringBoot专注于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独立使用开发项目；但是SpringCloud离不开SpringBoot,属于依赖的关系
SpringBoot专注于快速、方便的开发单个微服务个体, SpringCloud关注全局的服务治理框架。

1.3 ZooKeeper和Eureka的区别

Eureka是基于AP原则设计

传统的ACID分别为

代表技术：RDBMS ( mysql/oracle/ sqlServer)

A (Atomicity)原子性传统的ACID分别是什么国
C (Consistency)一致性
I (Isolation)独立性
D (Durability)持久性

CAP分别为(CAP只能三选二，不能同时满足三个)

代表技术：NOSQL (redis/ mongdb)

C:Consistency (强一致性)：信息的及时性，最新性
A:Availability ( 高可用性)
P:Partition tolerance ( 分区容错性)

因为eureka分布式项目一般会在不同的服务器上，所以P是一定要选的，zookeeper为CP原则，eureka 为AP原则

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

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

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

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

2. 什么是微服务

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，甚至拥有自己独立的数据库。最大程度降低耦合度

2.1微服务与微服务架构的区别

微服务：对外形成一个架构体系，它强调的是服务的大小，关注的是某个点就比如eclipse里面一个个的微服务工程/module
微服务架构：是一种架构模式，提倡将单一的应用根据业务拆分成一个个的服务，服务之间相互协调，互相配合。每个服务都在其运行的进程中。

2.2微服务的优缺点

优点：

每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。微服务能使用不同的语言开发。
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Hudson, bamboo。微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件混合。
每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

缺点：

开发人员要处理分布式系统的复杂性
多服务运维难度，随着服务的增加，运维的压力也在增大
系统部署依赖、服务间通信成本、数据一致性、系统集成测试、性能监控…

2.3 微服务技术栈有哪些？

在这里插入图片描述

3.为什么选择springCloud 作为微服务架构

因为springCloud拥有完整的微服务框架，像前面的微服务条目中的维度基本都可以实现，无需背靠其它插件或框架。

4. springCloud 入门概述

4.1 dubbo和springCloud对比

在这里插入图片描述

最大区别: SpringCloud拋弃了Dubbo的RPC通信,采用的是基于HTTP的REST方式。严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖,这在强调快速演化的微服务环境下，显得更加合适。
品牌机与组装机的区别
很明显，Spring Cloud的功能比DUBBO更加强大,涵盖面更广,而且作为Spring的拳头项目，它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合,这些对于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑,各环节我们的选择自由度很高,但是最终结果很有可能因为一条内存质量不行就点不亮了, 总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题;而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

springCloud项目案列

MicroServiceCloud父I程(Project)，下面带着3个子模块 (Module)

MicroServiceCloud
- microservicecloud-api （封装的整体entity/接口/公共配置等）
- microservicecloud- provider-dept- -8001（微服务落地的服务提供者）
- microservicecloud-consumer-dept-80（微服务调用的客户端使用）

idea构建分布式项目的方法

链接:idea构建分布式项目的方法.

5. 服务注册

5.1Eureka是什么

Eureka是Netflix的一个子模块,也是核心模块之一。Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的,有了服务发现与注册，只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心,比如Zookeeper.

5.2原理讲解

Spring Cloud封装了Netflix 公司开发的Eureka模块来实现服务注册和发现(请对比Zookeeper)。Eureka采用了C-S的设计架构。Eureka Server作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到Eureka Server并维持心跳连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行。SpringCloud 的一些其他模块(此如Zuul)就可以通过Eureka Server 来发现系统中的其他微服务，并执行相关的逻辑。

在这里插入图片描述
Eureka包含两个组件: Eureka Server和Eureka Client

Eureka Server提供服务注册服务各个节点启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到
EurekaClient是一个Java客户端，用于简化Eureka Server的交互,客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除(默认90秒)

5.3具体搭建

假如我需要引入cloud的一个新技术组件
基本上有两步

1.1
新增一个相关的maven坐标
eureka

<!--eureka-server服务端-->
<dependency>
<groupId>org. spr ingframework. cloud</ groupId>
<artifactId>spring-cloud-starter-eureka- -server</artifactId>
</dependency>

1.2
再主启动类上面，标注的启动该新组件技术的相关注解标签
@EnableEurekaServer

@SpringBootApplication
@EnableEurekaServer
public class EurekaService7001_APP 
{
    public static void main( String[] args )
    {
       SpringApplication.run(EurekaService7001_APP.class, args);
    }
}

1.3
java业务逻辑编码

5.4 将服务注册进eureka中

1.在需要被放入eureka的微服务中加入pom相关依赖

 <!--将微服务注册进eureka-->
     <dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-eureka</artifactId>
		<version>1.4.4.RELEASE</version>
	</dependency>
	<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-config</artifactId>
		 <version>2.1.4.RELEASE</version>
	</dependency>

2.在需要被放入eureka的微服务中加入yml相关配置

eureka :
  client: #客户端注册进eureka服务列表内
    service-url:  
      defaultZone: http://localhost:7001/eureka  # 要去注册的地址，在eureka服务端的yml中有定义

在需要被放入eureka的微服务的主启动类中配置@EnableEurekaClient

@SpringBootApplication
@EnableEurekaClient //本服务启动后会自动注册进eureka服务中
public class Dept8001_APP 
{
    public static void main( String[] args )
    {
        SpringApplication.run(Dept8001_APP.class, args);
    }
}

5.5 细节修改

1.修改服务映射地址的名字
方法：在客户端的yml中配置 instance :
instance-id: microservicecloud-dept8001

eureka :
  client: #客户端注册进eureka服务列表内
    service-url:  
      defaultZone: http://localhost:7001/eureka  # 要去注册的地址，在eureka服务端的yml中有定义
  instance :
    instance-id: microservicecloud-dept8001 #你想要配置的服务映射地址的名字

2.修改主机IP信息提示

在这里插入图片描述 方法：在客户端的yml中配置如下信息

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

3.info内容构建

第一步：在客户端的pom中添加依赖

	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-actuator</artifactId>
		<version>2.1.4.RELEASE</version>
	</dependency>

第二步:在总微服务的pom中添加依赖,作用是可以识别到客户端的yml中$的配置信息

  <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>
						<delimiter>$</delimiter>
					</delimiters>
				</configuration>
			</plugin>
		</plugins>
	</build>

第三步：在客户端的yml中配置信息

info:
  app.name: atguigu-microservicec loud
  company.name: WWW.atguigu.com
  build.artifactId: ${project.artifactId}
  build.version: ${project.version}

效果展示

在这里插入图片描述

5.6eureka的自我保护机制

一句话:某时刻某一个微服务不可用了eureka不会立刻清理，依旧会对该微服务的信息进行保存

默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳， EurekaServer将会注销该实例(默认90秒) 。但是当网络分区故障发生时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了一因为微服务本身其实是健康的，此时本不应该注销这个微服务。Eureka通过” 自我保护模式”来解决这个问题一当EurekaServer节，点在短时间内丢失过多客户端时(可能发生了网络分区故障)，那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据(也就是不会注销任何微服务)。当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。

在自我保护模式中，Eureka Server会保护服务注册表中的信息,不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上
时，该Eureka Server节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能
健康的服务实例。一句话讲解:好死不如赖活着

在Spring Cloud中，在eureka服务端的yml配置中可以使用eureka.server.enable-self-preservation = false禁用自我保护模式。

5.7集群配置

作用是防止某一个eureka不起作用后导致项目死机

第一步：先新创建两个eureka微服务7003和7002
第二步：将最早的eureka7001的主启动类和pom文件拷贝到后建的eureka 中
第三部：修改映射配置

在这里插入图片描述

第四步：修改yml，三个eureka 的yml都要修改

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

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

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

未来可期MXH

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
springCloud详情笔记

1.常见问题1.1springCloud和dubbo的主要区别是什么？通信机制的不同：dubbo采用的是RPC远程过程调用，springCloud是基于RESTful调用2. 什么是微服务微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自...
复制链接

扫一扫

专栏目录