30 - 最新2024版SpringCloud学习记录 - 项目版本选型

Spring Cloud 2025.0.0"Northfields"正式发布

springcloud的版本格式： 大版本(以英国地铁站命名，按首字母排序).小版本 maven中央仓库上版本一览： 希腊字母版本号 　　Base：设计阶段。只有相应的设计没有具体的功能实现 　　Alpha：软件的初级版本。基本功能已经实现，但存在较多的bug 　　Bate：相对于Alpha已经有了很大的进步，消除了严重的BUG，但还存在一些潜在的BUG，还需要不断测试...

Spring Cloud 项目目前仍然是快速迭代期，版本变化很快。这里整理一下版本相关的东西，备忘一下。 大版本 版本号规则 Spring Cloud并没有熟悉的数字版本号，而是对应一个开发代号。 Cloud代号 Boot版本(train) Boot版本(tested) lifecycle Angle 1.2.x incompatible with 1.3 EOL in J...

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制相互协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。Spring Cloud=分布式微服务架构的一站式解决方案，是多种微服务

2024最新版SpringCloud教程 0 前言闲聊开篇简介 1 SpringBoot和SpringCloud版本选型 2 SpringCloud是什么能干吗 3 SpringCloud各组件的停更升级替换说明 4 项目实战之需求说明 5 项目实战之Maven父工程聚合说明和mysql驱动选择 6 项目实战之Mapper4一键生成Dao层代码 7 项目实战之微服务工程化编写步骤 8 项目实战之Pay支付微服务编码落地实战 9 项目实战之PostMan测试通过 10 项目实战之Swagger3测试通过 11

Spring Boot的版本以数字表示。例如：Spring Boot 2.2.5.RELEASE --> 主版本.次版本.增量版本（Bug修复）Spring Cloud是一个项目总括，里面包含了很多的子项目，避免子项目之间的混淆，因此命名方式采用英文名字的方式来命名，SpringCloud采用了英国伦敦地铁站的名称来命名，并由地铁站名称首字母A-Z一次类推的形式来发布迭代版本。例如 Angel 是第一个版本，Brixton 是第二个版本…。

传统的单体架构足以满足中小型项目的需求，但是如果对于一个用户量庞大的系统就会出现各种问题。例如：如果只有一个支付系统，那么系统崩溃了整个系统就运作不了了。而分布式系统解决了这个问题，它允许系统以集群的形式部署，形成负载均衡，尽量减少系统崩溃带来的问题。在2019年之前，使用的大部分技术都是Netflix提供的，但是由于开发SpringCloud的相关技术不挣钱，因此Netflix就暂停开发相关技术了，虽然他提供的那些技术依旧可以使用，但是已经不推荐了。

将业务的所有功能集中在一个项目中开发，打成一个包部署架构简单部署成本低当随着业务越来越多，代码量将上升至几万行甚至几十万行，开发人员也会需要越来越多！各业务之前存在耦合性，编写、提交代码时，可能会产生冲突。同时，代码量过高也会造成编译，打包时间过长。某些业务存在高并发，就会很容易将服务器资源耗尽，其他业务就只能等待，访问时就会卡顿。团队协作成本高系统发布效率低系统可用性差单体架构适合开发功能相对简单，规模较小的项目。

│ Elasticsearch01-14.JavaRestClient-文档的CRUD.mp4。│ Elasticsearch01-13.JavaRestClient-新增文档.mp4。│ MybatisPlus-10.核心功能-IService的Lambda方法.mp4。│ MybatisPlus-11.核心功能-IService的批量新增.mp4。│ Elasticsearch01-07.索引库操作-索引库的CRUD.mp4。

微服务 在 jsp 时代，应用前后端耦合，前后端 all in 一台服务器，随着流量的增大，代码数量的增加，单体应用不再适合互联网的发展，微服务顺应提出。 微服务是一种用于构建应用的架构方案。区别于更为传统的单体式方案，将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。 Spring Cloud 版本 在微服...

内部开发到一定阶段了，各个模块集成后，经过全面测试发现没有问题，可对外发行了。从BUILD后到GA在到M基本上系统就算定型了，这个时候系统就进入Release Candidate（候选发布版）。milestone（里程碑版）。milestone版主要修复了一些bug调整。正式发布版一般也有多个发布，例如 SR1 SR2 SR3等等，一般是用。一个GA后，一般会有多个里程本版。由于GA还不属于公开发行版，里面还有些功能不完善或者bug，于是就有了。该期间只对一些发现的等级高的bug进行修复。

Spring Cloud是一套整合了各大公司开源技术的规范，而这些开源技术的版本发布是由各个公司来维护的，每个子项目都维护了自己的发布版本号，所以它不像传统意义上的版本命名，而是采用了伦敦地铁站的名字根据字母表的顺序结合对应版本的时间顺序来定义一个大版本，Spring Cloud以往的版本发布顺序排列如下: Spring Cloud的每一个大版本通过BOM ( Bill of Materials ）来管理每个子项目的版本清单，下图所示是Spring Cloud官网提供的各个子项目的版本清单，表头(Edgw

Spring Cloud 项目目前是快速迭代期，版本变化快。 大版本 版本号规则 Spring Cloud并没有熟悉的数字版本号，而是对应一个开发代号。 Cloud代号 Boot版本(train) Boot版本(tested) lifecycle Angle 1.2.x incompatible with 1.3 EOL in July 2017 Brixton 1.3.x 1.4.x 2017-07卒 Camden 1.4.x 1.5.x - Dalston 1.5.x not expected 2.x

springcloud(狂神)

其实SpringBoot与SpringCloud需要版本对应，否则可能会造成很多意料之外的错误，比如eureka注册了结果找不到服务类啊，比如某些jar导入不进来啊，等等这些错误。从 Spring Cloud 2020.0.0-M1 开始，Spring Cloud 废除了这种英国伦敦地铁站的命名方式，而使用了全新的 "日历化" 版本命名方式。SpringCloud的版本号是根据英国伦敦地铁站的名字进行命名的，由地铁站名称字母A-Z依次类推表示发布迭代版本。

vCamden.Release表示Camden主版本的最后验收版本，有了此版本号，意味着将开始下一主版本号的演进之路。其中次要版本号、增量版本号、修饰版本号同之前Release Train风格约定的涵义一样。新式的版本命名仍然同之前Release Train风格命名，但Maven仓库中的项目坐标将不再使用。Spring Cloud的Release Train版本号规则：v{伦敦地铁站的英文单词}·{SR/M/RC}{数字}/Release。即 主要版本号（YYYY）.次要版本号.增量版本号-修饰版本号。