【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(一)基础知识+各个组件介绍+聚合父工程创建

本文涉及的产品
RDS MySQL DuckDB 分析主实例,基础系列 4核8GB
RDS MySQL DuckDB 分析主实例,集群系列 4核8GB
RDS AI 助手,专业版
简介: 【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(一)基础知识+各个组件介绍+聚合父工程创建

1、微服务简介

什么是微服务呢?

就是将一个大的应用,拆分成多个小的模块,每个模块都有自己的功能和职责,每个模块可以 进行交互,这就是微服务

简而言之,微服务架构的风格,就是将单一程序开发成一个微服务, 每个微服务运行在自己的进程中,并使用轻量级通信机制,通常是 HTTP RESTFUL API 。这些服务围绕业务能力来划分构建的,并通 过完全自动化部署机制来独立部署这些服务可以使用不同的编程语 言,以及不同数据存储技术,以保证最低限度的集中式管理。

1.1 微服务的自动化部署(CI /CD)(持续集成 持续交付)

在微服务架构中,系统会被拆分为若干个微服务,每个微服务又是一个独立的应用程序。单体 架构的应用程序只需要部署一次,而微服务架构有多少个服务就需要部署多少次。随着服务数 量的增加,如果微服务按照单体架构的部署方式,部署的难度会呈指数增加。业务的粒度划分 得越细,微服务的数量就越多,这时需要更稳定的部署机制。随着技术的发展,尤其是 Docker 容器技术的推进,以及自动化部署工具(例如开源组件 Jenkins)的出现,自动化部署变得越 来越简单。 自动化部署可以提高部署的效率,减少人为的控制,部署过程中出现错误的概率降低,部署过 程的每一步自动化,提高软件的质量。构建一个自动化部署的系统,虽然在前期需要开发人员 或者运维人员的学习,但是对于整个软件系统来说是一个全新的概念。在软件系统的整个生命 周期之中,每一步是由程序控制的,而不是人为控制,软件的质量提高到了一个新的高度。随 着 DevOps 这种全新概念的推进,自动化部署必然会成为微服务部署 的一种方式。

1.2 服务集中化管理

微服务系统是按业务单元来划分服务的,服务数量越多,管理起来就越复杂,因此微服务必须 使用集中化管理。目前流行的微服务框架中,例如 Spring Cloud 采用 Eureka 来注册服务和 发现服务,另外, Zookeeper、 Consul 等都是非常优秀的服务集中化管理框架。

1.3 分布式架构

分布式系统是集群部署的,由很多计算机相互协作共同构成,它能够处理海量的用户请求。当 分布式系统对外提供服务时,用户是毫不知情的,还以为是一台服务器在提供服务。分布式系 统的复杂任务通过计算机之间的相互协作来完成,当然简单的任务也可以在一台计算机上完 成。分布式系统通过网络协议来通信,所以分布式系统在空间上没有任何限制,即分布式服务 器可以部署不同的机房和不同的地区。微服务架构是分布式架构,分布式系统比单体系统更加 复杂,主要体现在服务的独立性和服务相互调用的可靠性,以及分布式事务、全局锁、全局 Id 等,而单体系统不需要考虑这些复杂性。 另外,分布式系统的应用都是集群化部署,会给数据一致性带来困难。分布式系统中的服务通 信依赖于网络,网络不好,必然会对分布式系统带来很大的影响。在分布式系统中,服务之间 相互依赖,如果一个服务出现了故障或者是网络延迟,在高并发的情况下,会导致线程阻塞, 在很短的时间内该服务的线程资源会消耗殆尽,最终使得该服务不可用。由于服务的相互依赖, 可能会导致整个系统的不可用,这就是“雪崩效应”。为了防止此类事件的发生,分布式系统 必然要采取相应的措施,例如“熔断机制”。

1.4 熔断机制 Hystri

为了防止“雪崩效应”事件的发生,分布式系统采用了熔断机制。在用 SpringCloud 构建的 微服务系统中,采用了熔断器(即 Hystrix 令 组件的 C ircuit Breaker)去做熔断。例如在微 服务系统中,有 a、 b、 c、 d、 e、 如果此时服务 b 出现故障或者网络延迟,服务 b 会出现大量的线程阻塞,有可能在很短的时 间内线程资源就被消耗完了,导致服务 b 的不可用。如果服务 b 为较 底层的服务,会影响 到其他服务,导致其他服务会一直等待服务 b 的处理。如果服务 b 迟迟不处理,大量的网络 请求不仅仅堆积在服务 b,而且会堆积到依赖于服务 b 的其他服务。而因服务 b 出现故障影 响的服务,也会影响到依赖于因服务 b 出现故障影响的服务的其他服务,从而由 b 开始,影 响到整个系统,导致整个系统的不可用。这是一件非常可怕的事,因为服务器运营商的不可靠, 必然会导致服务的不可靠,而网络服务商的不可靠性,也会导致服务的不可靠。在高并发的场 景下,稍微有点不可靠,由于故障的传播性,会导致大量的服务不可用,甚至导致整个系统崩 溃。 为了解决这一难题,微服务架构引入了熔断机制。当服务 b 出现故障,请求失败次数超过设 定的阀值之后,服务 b 就会开启熔断器,之后服务 b 不进行任何的业务逻辑操作,执行快速失败,直接返回请求失败的信息。其他依赖于 b 的服务就不会因为得不到响应而线程阻塞, 这时除了服务 b 和依赖于服务就不会因为得不到响应而线程阻塞, 这时除了服务 b 和依赖于服务 b 的部分功能不可用外,其他功能正常。

==微服务架构中,有三大难题,那就是服务故障的传播性(熔断)、服务的划分和分布式事 务。 ==

2、SpringCloud 简介

Spring Cloud 作为 Java 语言的微服务框架,它依赖于 Spring Boot,有快速开发、持续 交付和容易部署等特点。 Spring Cloud 的组件非常多,涉及微服务的方方面面,井在开源 社区 Spring 和 Netflix、 Pivotal 两大公司的推动下越来越完善,如今 alibaba 也加入 到其中。 spring 官方 netflix alibaba Spring Cloud 在开发部署上继承了 Spring Boot 的一些优点,提高其在开发和部署上的效 率。 Spring Cloud 的首要目标就是通过提供一系列开发组件和框架,帮助开发者迅速搭建 一个分布式的微服务系统。 Spring Cloud 是通过包装其他技术框架来实现的,例如包装开 源的 Netflix oss 组件,实现了一套通过基于注解、 Java 配置和基于模版开发的微服务框 架。 Spring Cloud 提供了开发分布式微服务系统的一些常用组件,例如服务注册和发现、 配置中心、熔断器、远程调用,智能路由、微代理、控制总线、全局锁、分布式会话等。

2.1 SpringCloud 版本对应关系
SpringCloud Release Train SpringBoot Release Train
2022.0.x aka Kilburn 3.0.x
2021.0.x aka Jubilee 2.6.x, 2.7.x (Starting with 2021.0.3)
2020.0.x aka Ilford 2.4.x, 2.5.x (Starting with 2020.0.3)
Hoxton 2.2.x, 2.3.x (Starting with SR5)
Greenwich 2.1.x
Finchley 2.0.x
Edgware 1.5.x
Dalston 1.5.x

官网对应版本链接:https://start.spring.io/actuator/info

{
"git": {
"branch": "340c06d599fde962d4bc305d5ed7d72581e7f6f6",
"commit": {
"id": "340c06d",
"time": "2023-04-04T13:40:09Z"
}
},
"build": {
"version": "0.0.1-SNAPSHOT",
"artifact": "start-site",
"versions": {
"spring-boot": "3.0.5",
"initializr": "0.20.0-SNAPSHOT"
},
"name": "start.spring.io website",
"time": "2023-04-04T13:41:28.911Z",
"group": "io.spring.start"
},
"bom-ranges": {
"codecentric-spring-boot-admin": {
"2.4.3": "Spring Boot >=2.3.0.M1 and <2.5.0-M1",
"2.5.6": "Spring Boot >=2.5.0.M1 and <2.6.0-M1",
"2.6.8": "Spring Boot >=2.6.0.M1 and <2.7.0-M1",
"2.7.4": "Spring Boot >=2.7.0.M1 and <3.0.0-M1",
"3.0.2": "Spring Boot >=3.0.0-M1 and <3.1.0-M1"
},
"solace-spring-boot": {
"1.1.0": "Spring Boot >=2.3.0.M1 and <2.6.0-M1",
"1.2.2": "Spring Boot >=2.6.0.M1 and <3.0.0-M1"
},
"solace-spring-cloud": {
"1.1.1": "Spring Boot >=2.3.0.M1 and <2.4.0-M1",
"2.1.0": "Spring Boot >=2.4.0.M1 and <2.6.0-M1",
"2.3.2": "Spring Boot >=2.6.0.M1 and <3.0.0-M1"
},
"spring-cloud": {
"Hoxton.SR12": "Spring Boot >=2.2.0.RELEASE and <2.4.0.M1",
"2020.0.6": "Spring Boot >=2.4.0.M1 and <2.6.0-M1",
"2021.0.0-M1": "Spring Boot >=2.6.0-M1 and <2.6.0-M3",
"2021.0.0-M3": "Spring Boot >=2.6.0-M3 and <2.6.0-RC1",
"2021.0.0-RC1": "Spring Boot >=2.6.0-RC1 and <2.6.1",
"2021.0.6": "Spring Boot >=2.6.1 and <3.0.0-M1",
"2022.0.0-M1": "Spring Boot >=3.0.0-M1 and <3.0.0-M2",
"2022.0.0-M2": "Spring Boot >=3.0.0-M2 and <3.0.0-M3",
"2022.0.0-M3": "Spring Boot >=3.0.0-M3 and <3.0.0-M4",
"2022.0.0-M4": "Spring Boot >=3.0.0-M4 and <3.0.0-M5",
"2022.0.0-M5": "Spring Boot >=3.0.0-M5 and <3.0.0-RC1",
"2022.0.0-RC1": "Spring Boot >=3.0.0-RC1 and <3.0.0-RC2",
"2022.0.0-RC2": "Spring Boot >=3.0.0-RC2 and <3.0.0",
"2022.0.2": "Spring Boot >=3.0.0 and <3.1.0-M1"
},
"spring-cloud-azure": {
"4.6.0": "Spring Boot >=2.5.0.M1 and <3.0.0-M1",
"5.0.0": "Spring Boot >=3.0.0-M1 and <3.1.0-M1"
},
"spring-cloud-gcp": {
"2.0.11": "Spring Boot >=2.4.0-M1 and <2.6.0-M1",
"3.4.7": "Spring Boot >=2.6.0-M1 and <3.0.0-M1",
"4.1.3": "Spring Boot >=3.0.0-M1 and <3.1.0-M1"
},
"spring-cloud-services": {
"2.3.0.RELEASE": "Spring Boot >=2.3.0.RELEASE and <2.4.0-M1",
"2.4.1": "Spring Boot >=2.4.0-M1 and <2.5.0-M1",
"3.3.0": "Spring Boot >=2.5.0-M1 and <2.6.0-M1",
"3.4.0": "Spring Boot >=2.6.0-M1 and <2.7.0-M1",
"3.5.0": "Spring Boot >=2.7.0-M1 and <3.0.0-M1",
"4.0.0": "Spring Boot >=3.0.0 and <3.1.0-M1"
},
"spring-shell": {
"2.1.6": "Spring Boot >=2.7.0 and <3.0.0-M1",
"3.0.0": "Spring Boot >=3.0.0 and <3.1.0-M1"
},
"vaadin": {
"14.9.6": "Spring Boot >=2.1.0.RELEASE and <2.6.0-M1",
"23.2.15": "Spring Boot >=2.6.0-M1 and <2.7.0-M1",
"23.3.10": "Spring Boot >=2.7.0-M1 and <3.0.0-M1",
"24.0.3": "Spring Boot >=3.0.0-M1 and <3.1.0-M1"
},
"wavefront": {
"2.0.2": "Spring Boot >=2.1.0.RELEASE and <2.4.0-M1",
"2.1.1": "Spring Boot >=2.4.0-M1 and <2.5.0-M1",
"2.2.2": "Spring Boot >=2.5.0-M1 and <2.7.0-M1",
"2.3.4": "Spring Boot >=2.7.0-M1 and <3.0.0-M1",
"3.0.1": "Spring Boot >=3.0.0-M1 and <3.1.0-M1"
}
},
"dependency-ranges": {
"okta": {
"1.4.0": "Spring Boot >=2.2.0.RELEASE and <2.4.0-M1",
"1.5.1": "Spring Boot >=2.4.0-M1 and <2.4.1",
"2.0.1": "Spring Boot >=2.4.1 and <2.5.0-M1",
"2.1.6": "Spring Boot >=2.5.0-M1 and <3.0.0-M1",
"3.0.3": "Spring Boot >=3.0.0-M1 and <3.1.0-M1"
},
"mybatis": {
"2.1.4": "Spring Boot >=2.1.0.RELEASE and <2.5.0-M1",
"2.2.2": "Spring Boot >=2.5.0-M1 and <2.7.0-M1",
"2.3.0": "Spring Boot >=2.7.0-M1 and <3.0.0-M1",
"3.0.0": "Spring Boot >=3.0.0-M1"
},
"pulsar": {
"0.2.0": "Spring Boot >=3.0.0 and <3.1.0-M1"
},
"pulsar-reactive": {
"0.2.0": "Spring Boot >=3.0.0 and <3.1.0-M1"
},
"camel": {
"3.5.0": "Spring Boot >=2.3.0.M1 and <2.4.0-M1",
"3.10.0": "Spring Boot >=2.4.0.M1 and <2.5.0-M1",
"3.13.0": "Spring Boot >=2.5.0.M1 and <2.6.0-M1",
"3.17.0": "Spring Boot >=2.6.0.M1 and <2.7.0-M1",
"3.20.2": "Spring Boot >=2.7.0.M1 and <3.0.0-M1",
"4.0.0-M2": "Spring Boot >=3.0.0-M1 and <3.1.0-M1"
},
"picocli": {
"4.7.0": "Spring Boot >=2.5.0.RELEASE and <3.1.0-M1"
},
"open-service-broker": {
"3.2.0": "Spring Boot >=2.3.0.M1 and <2.4.0-M1",
"3.3.1": "Spring Boot >=2.4.0-M1 and <2.5.0-M1",
"3.4.1": "Spring Boot >=2.5.0-M1 and <2.6.0-M1",
"3.5.0": "Spring Boot >=2.6.0-M1 and <2.7.0-M1"
}
}
}
2.2 SpringCloud 常用组件表 (管家)

服务的注册和发现(eureka,nacos,consul)

服务的负载均衡(ribbon,dubbo)

服务的相互调用(openFeign,dubbo)

服务的容错(hystrix,sentinel)

服务网关(gateway,zuul)

服务配置的统一管理(config-server,nacos,apollo)

服务消息总线(bus)

服务安全组件(security,Oauth2.0)

服务监控(admin) (jvm)

链路追踪(sleuth+zipkin)

2.3 SpringCloud总结

SpringCloud 就是微服务理念的一种具体落地实现方式,帮助微服务架构提供了必备的功能 目前开发中常用的落地实现有三种: Dubbo+Zookeeper 半自动化的微服务实现架构 (别的管理没有) SpringCloud Netflix 一站式微服务架构 SpringCloud Alibaba 新的一站式微服务架构 。

三大公司 Spring Netflix Alibaba 。

3、SpringCloud组件的停更停用说明

SpringCloud各个组件

SpringCloud组件升级替换

描述:

  • 服务注册中心:

Eureka:官方停止更新,并且已经有更好的替代产品了,可以使用,但是官方已经不建议使用了(重度患者)。

Zookeeper:某些老系统,以前是用的Zookeeper + Dubbo,后来做技术升级,结果发现SpringCloud的Eureka停更了,然后就用了最少的技术切换,那么就用了Zookeeper做注册中心。

Consul:go语言开发的,也是一个优秀的服务注册框架,但是使用量较少,风头都被Nacos抢了。

Nacos:来自于SpringCloudAlibaba,在企业中经过了百万级注册考验的,不但可以完美替换Eureka,还能做其他组件的替换,所以强烈建议使用,是学习的重点。

  • 服务调用:

Ribbon:也进入了维护状态,停止更新了,但是Spring官方还在使用(轻度患者)。

LoadBalancer:Spring官方推出的一个新的组件,打算逐渐取代掉Ribbon,但是现在还处于萌芽状态。

  • 服务调用2:

Feign:Netflix 公司产品,也停止更新了。

OpenFeign:Spring社区等不了Netflix更新了,然后就自己做了一个组件,不用Feign了。

  • 服务降级:

Hystrix:官网不推荐使用,但是中国企业中还在大规模使用。

Resilience4J:官网推荐使用,但是国内很少用这个。

Sentienl:来自于SpringCloudAlibaba,在中国企业替换Hystrix的组件,国内强烈建议使用。

  • 服务网关:

Zuul:Netflix 公司产品,公司内部产生分歧,有的人想自己出一个Zuul2。

Zuul2:也是Netflix 公司准备出的产品,但是由于内部分歧,所以Zuul2已经胎死腹中了。

gateway:Spring社区自己出的网关组件,官方隆重介绍和极度推荐的网关服务组件。

  • 服务配置:

Config:目前也在使用,风头被Nacos抢了。

Nacos:来自于SpringCloudAlibaba,后来居上,把Config给替换了。

  • 服务总线:

Bus:SpringCloud原生的服务总线组件,现在风头也被Nacos抢了。

Nacos:来自于SpringCloudAlibaba,后来居上,把Bus给替换了。

综上可以看出,Nacos 是重中之重,一个组件就替换掉了原来的几个组件。

4、微服务cloud整体聚合工程

4.1 新建父工程

1.打开idea,创建一个maven工程

1.New Project

2.聚合总父工程名字和工程名字

  1. Maven选版本

  1. build success

  1. 字符编码

  1. 注解生效激活

  1. java编译版本选、

  1. File Type过滤

  1. 父工程pom
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.tigerhhzz.springcloud</groupId>
  <artifactId>springcloud2023</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>pom</packaging>
  <name>Maven</name>
  <!-- FIXME change it to the project's website -->
  <url>http://maven.apache.org/</url>
  <inceptionYear>2001</inceptionYear>
  <distributionManagement>
    <site>
      <id>website</id>
      <url>scp://webhost.company.com/www/website</url>
    </site>
  </distributionManagement>
  <!-- 统一管理jar包版本 -->
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
    <junit.version>4.12</junit.version>
    <log4j.version>1.2.17</log4j.version>
    <lombok.version>1.16.18</lombok.version>
    <mysql.version>5.1.47</mysql.version>
    <druid.version>1.1.16</druid.version>
    <mybatis.spring.boot.version>1.3.0</mybatis.spring.boot.version>
  </properties>
  <!-- 1、只是声明依赖,并不实际引入,子项目按需声明使用的依赖 -->
  <!-- 2、子项目可以继承父项目的 version 和 scope -->
  <!-- 3、子项目若指定了 version 和 scope,以子项目为准 -->
  <dependencyManagement>
    <dependencies>
      <!--spring boot 2.2.2-->
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>2.2.2.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <!--spring cloud Hoxton.SR1-->
      <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dependencies</artifactId>
        <version>Hoxton.SR1</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <!--spring cloud alibaba 2.1.0.RELEASE-->
      <dependency>
        <groupId>com.alibaba.cloud</groupId>
        <artifactId>spring-cloud-alibaba-dependencies</artifactId>
        <version>2.1.0.RELEASE</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>mysql</groupId>
        <artifactId>mysql-connector-java</artifactId>
        <version>${mysql.version}</version>
      </dependency>
      <dependency>
        <groupId>com.alibaba</groupId>
        <artifactId>druid</artifactId>
        <version>${druid.version}</version>
      </dependency>
      <dependency>
        <groupId>org.mybatis.spring.boot</groupId>
        <artifactId>mybatis-spring-boot-starter</artifactId>
        <version>${mybatis.spring.boot.version}</version>
      </dependency>
      <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>${junit.version}</version>
      </dependency>
      <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>${log4j.version}</version>
      </dependency>
      <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
        <version>${lombok.version}</version>
        <optional>true</optional>
      </dependency>
    </dependencies>
  </dependencyManagement>
  <build>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <configuration>
          <fork>true</fork>
          <addResources>true</addResources>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>
4.2 Maven中的DependencyManagement和Dependencies 介绍

一般项目pom文件中有DependencyManagement,代表这个工程是maven父工程。

通过DependencyManagement管理子模块项目中所需的所有依赖,包括依赖的GAV坐标,此时依赖的版本号可以通过properties标签统一管理,方便以后版本升级时,一处修改,处处生效。

4.3 Maven跳过单元测试

父工程创建完成后可以执行mvn:install将父工程发布到仓库方便子工程继承使用。

目录
相关文章
|
8月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
149 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
5月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
5月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
429 1
|
9月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
478 61
|
6月前
|
NoSQL Java 调度
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
分布式锁是分布式系统中用于同步多节点访问共享资源的机制,防止并发操作带来的冲突。本文介绍了基于Spring Boot和Redis实现分布式锁的技术方案,涵盖锁的获取与释放、Redis配置、服务调度及多实例运行等内容,通过Docker Compose搭建环境,验证了锁的有效性与互斥特性。
544 0
分布式锁与分布式锁使用 Redis 和 Spring Boot 进行调度锁(不带 ShedLock)
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
840 8
|
10月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
3367 57
|
10月前
|
消息中间件 缓存 算法
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
861 0
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
|
12月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
1076 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
1383 41