java前后端如何实现连接—java前后端联调 收藏 0

如何从 Java 8/11 迁移到 Java 21，从 Spring Boot 2 迁移到最新的3.2

如果您的工作配置与 Java 有一定的关系，您一定已经注意到 了Java 最新稳定版本 Java 21 引起了很多关注。

这个新版本引入了一些未来的功能，改进了之前引入/孵化的一些突破性功能，弃用了多余的功能，并删除了一些错误。它使 Java 更具竞争力和活力，与其他流行的编程语言保持同步。

现代软件应用程序及其使用模式需要非常高的效率、安全性、吞吐量和可扩展性。随着软件开发范式的发展以满足这些需求（和威胁），流行的语言也在不断发展，而 Java 自然也不甘落后。

如果您关心优化并保持软件最佳性能，并充分利用尖端技术，那么这篇文章适合您。即使您不打算进行任何升级，您也可能需要进行现实检查或盘点当前的软件堆栈。随着我们运行软件和业务的环境不断变化，新的要求和威胁不断涌现。提前计划、修改和纠正一些事情总是更好。

利用最新的功能和特性使我们保持竞争力、兼容性和灵活性。在本文中，我们讨论从 Java 8 到 Java 21 的迁移；以及 Spring Boot 2 到 Spring Boot3.2/Spring Framework 6.1 我们的讨论重点是 Java 21 和 Spring Boot 3.2。

Java 21 旨在保持 Java 的竞争力，提高性能和安全性，并增强其功能和特性。一些显著特点是：

• Lightweight Virtual threads – 轻量级虚拟线程 – Java 21 支持thread-per-request式编程，通过虚拟线程实现近乎最佳的硬件利用率。以前，每个新创建的线程都必须对应一个新操作系统线程，这限制了新线程的创建。但是现在，虚拟线程允许创建许多共享同一个操作系统线程的虚拟线程，缓解了 thread-per-request风格编程创建线程的负担。 。
• Structured Concurrency API – 结构化并发 API – 协调、编排和观察上述虚拟线程，以提供更可靠和可维护的并发代码。
• Scoped Values – 作用域值-作用域值允许安全有效地在线程之间共享变量/数据值。因此，来自同一父级的线程可以在它们之间共享信息/上下文，从而无需传递方法参数即可达到相同的效果。作用域值被声明为最终的和静态的，并且仅在线程执行期间的有限时间内可用，明确定义了虚拟线程可以共享变量的范围和规则。
• Vector API – Vector API – Java21 中的另一个开创性功能，它是在 Java 16 中孵化的。Vector API 允许指定在支持的 CPU 上编译为向量指令的向量计算，从而提供计算速度的成倍提高。向量指令可以处理多条数据，例如256 位处理器上的 8 个浮点值或 16 个短值，只需 1 个 CPU 指令。
• 相反，标量计算需要重复 8 次循环才能完成。
• Record Patterns 记录模式 为了使 Java 更适合解释和分析大量不同的数据，Java 21 中引入了记录模式的概念。
• 记录模式可以处理嵌套对象图，确定记录的确切类型，然后获取记录中的组成数据。
• Enhanced SWITCH statement – 增强的 SWITCH 语句 – Switch 语句现在可以匹配记录模式和正则表达式，然后对匹配项执行特定操作。与记录模式相结合以解构记录值以实现更好的数据查询，此功能可实现出色的数据导航和处理。
• Sequenced collections排序集合像List/Set这样的集合对象现在有一个定义的顺序，可以有第一个/最后一个/下一个/上一个元素，并且它们可以颠倒。 Java 21 提供了一组统一的操作来访问这个定义良好的顺序，从而为开发人员提供了更多的能力。
• Generational ZGC – 分代 ZGC – 这是改进的垃圾收集器，可以在不需要时谨慎地释放内存，从而优化资源利用率和系统性能。
• Foreign Function & Memory API 外部函数和内存 API 与 JVM 外部的代码和数据进行互操作，以防您认为其他语言可以更好地完成特定任务。
• 更多 – 还有更多这样的功能，包括未命名类和无人模式、字符串模板、密钥封装机制等，这些都增加了 Java 21 的强大功能和多功能性。

上述一些功能的灵感来自其他语言（如 Python、Go 和 Rust）中的优秀工件。其中一些是在考虑到计算的未来以及 Java 广泛使用的领域的情况下引入的。许多这些功能都备受期待，因为它们是经验丰富的 Java 开发人员所要求的。

采用和迁移到Java 21 可能具有里程碑意义。

Java 8 是 2011 年推出的长期支持（LTS）版本，当时提供了一些很酷的功能，例如 Lambda 函数、流 API、数据和时间 API、接口中的默认/静态函数以及 Nashorn JavaScript 引擎。

Java 8 允许您编写可读且可维护的代码，这些代码可以与软件堆栈的其他部分很好地交互。 Java8 是最后一个免费的 LTS 版本，这一事实进一步增加了 Java8 的受欢迎程度。

对 Java 8 的支持已于 2019 年结束，在 2030 年之前只有有限的选项可用于商业支持。Java 9 的许可证更改有点被误解，我们认为 Java 的后续更改对社区和语言都有好处。您应该考虑从 Java 8 升级，因为 Java 已经先进、成熟，并添加了许多有用的功能。

虽然 Spring Framework 的初始版本侧重于消除样板代码并通过提供基本基础设施和自动配置来简化开发，但 SpringBoot3.2/Spring Framework 6.1 向前迈出了几步，添加了反应式支持（Webflux 以及 MongoDB 和 Cassandra 等）。 ）、改进的Actuator、增强的性能以及更好的自动配置等。

Java 8 和 Spring Boot 2 都很好，可能是十年前最好的选择。

虽然 Spring Boot 2 提供了 Spring-Hibernate 平台的改进功能，但 Java 8 是一个添加了强大功能的路径定义版本。随着基于云的应用程序和移动应用程序的爆炸式增长，该堆栈有能力满足两者的需求。 Java 8 仍然受到一些开发人员的喜爱，但 Java 本身在 11、17 和 21 LTS 版本中经历了许多变化。

与各自的最新版本相比，Java 8 的一些限制和约束是：

• Java 8 缺乏诸如大幅改进的垃圾收集器和内存/资源管理之类的功能。
• 用于安全和加密、外部内存访问、流和矢量计算等的高级 API。
• 现代数据类型，如记录、虚拟线程、序列集合等。
• 类、接口和包装的改进和增强
• 改进的类加载器、系统监视器和工具

Spring Boot 2/Spring Framework 4 或 5 缺乏以下功能：

• Spring Framework 6 的特性和改进
• 更好的性能、可扩展性、安全性和资源利用率
• Jakarta EE 的最新功能，如验证、事务和 JSON/XML 支持
• 更好的 Servlet 容器和 GraalVM 镜像
• 更好的可观察性、追踪性和Micrometer Metrics

总体而言，Java 8 与 Spring Boot 2 曾经是一个强大的组合，但随着过去十年计算的进步和期望的变化，它现在看起来有点过时。

Java 21 的发展方向是未来主义和开创性的。 Java 21 正在跟上其生态系统中其他语言的变化，例如 GO/Rust/JavaScript(ECMAScript2022)/Python 等。我们在这些语言中看到的许多增强功能都支持/促进了人工智能和机器学习。更新、更好、更相关的工具正在被添加，以增强可观察性和测量。

此外，您的程序使用并与之共存的其他 API/软件/库/工具也在不断发展和进步。您可能不想因为使用过时或无效的软件堆栈而落后。迟早，围绕软件的需求和期望也可能会发生变化。考虑升级到 Java 21 和 Spring Boot 3 是明智的做法。这也可能意味着在性能、安全性、可维护性以及最重要的可观察性方面获得潜在的改进。

因此，我们进一步的讨论将集中于简化过渡以及如何迁移到它。

SpringBoot3.2 和 Spring Framework 6.1 提供以下显著特性：

• SpringBoot3.2可以与Java 21一起在GraalVm上运行。

GraalVM GraalVM 是一个令人着迷的 JDK 发行版，它提供 Java 程序的提前 (AOT) 编译，它会修剪代码中不必要的部分，并将您需要的内容编译为操作系统和特定于体系结构的本机代码，运行速度与运行速度一样快作为本机 C 代码！

编译后的代码加载速度快，占用的 RAM 少得多，并优化了其运行平台上的 CPU 周期使用。想象一下以极快的速度运行 Java 程序，就好像它是 GO 或 C 程序一样！

您只需将以下内容添加到您的 gradle 配置中：-

复制代码

java { sourceCompatibility = \’21\’}graalvmNative { binaries { main { buildArgs.add(\’–enable-preview\’) } } }

• 如果运行 Java 21，Spring Boot 3.2 提供对虚拟线程（Project Loom）的内置支持，因此您可以通过升级获得轻量级并发构造的好处。您只需要设置一个属性： spring.threads.virtual.enabled=true; Spring Boot 3.2 将开始使用虚拟执行器。锦上添花的是，虚拟线程执行器可以为许多技术自动配置，例如 RabbitMQ 监听器/Kafka 监听器/Spring Data Redis 的 ClusterCommandExecutor/Apache Pulsar 等。
• CRaC (Coordinated Restore at Checkpoint)CRaC（检查点协调恢复）是 Java 中的一种机制，允许您在 JVM+程序运行时拍摄快照并保存映像。稍后，如果您的 Java 程序遇到问题，您可以将其恢复到此快照以达到“最后已知的稳定状态”，并进一步解决问题。如果您遇到启动缓慢或预热时间较长的情况，此图像也非常有用。因此，要利用上述有用的功能，您必须考虑使用 Java 21 升级到 Spring Boot 3.2。
• 以 RestClientCustomizer 和 RestClientAutoConfiguration 的形式支持 Spring Framework 的 RestClient。 RestClient通过RestTemplate的基础设施提供WebClient的流畅API，通过可配置的模板、消息转换器、请求工厂和等使HTTP编程变得容易。
• Observability, 顾名思义，可观察性是仅通过测量系统的外部输出来测量系统内部状态的能力。
• 在 Spring 6.1/SpringBoot3.2 中，引入了一项名为 Spring Observability 的新举措，其中 Spring 框架本身跟踪其内部指标，如日志/跟踪/其他指标，提供来自框架本身的更快/更好的信息。
• 您现在可以使用 Micrometer 的 @Timed、@Counted、@ContinueSpan 等注释。

此外，还添加了 R2DBC 和 AspectJ 的可观察性，并改进了开放遥测的自动配置。

根据上述增强功能，使用我们的 Unlogged 插件可以为您的观察添加整体跟踪/可视化/主动干预/代码优化。您现在就可以尝试该插件。

• 基于 NamedParameterJdbcTemplate 的存在，添加了 JdbcClient 的自动配置。
• SSL 改进 – 现在，只需将其 reload-on-update 属性设置为 true，即可在信任材料发生更改时自动重新加载 SSL 捆绑包。
• 您可以在here. 查看许多其他有用的功能和增强功能。

一种方法是逐步向上过渡到 Java 11，然后过渡到 Java 17，最后过渡到 Java 21。虽然很耗时，但这样可以更平滑地过渡。

第二种方式是从Java 8直接跳转到Java 21。

无论您采用哪种方法，以下都是您在规划过渡时应考虑的一些准备工作和关键问题。

• Migration Analysis Reports Tool – 迁移分析报告工具 – Java 21 提供了一个很酷且有效的工具来分析您现有的应用程序，并提供详细的报告来帮助您规划迁移过程并制定策略。

该工具的分析粒度非常细，可以识别源代码中需要修改的行号，并突出显示强制和建议的更改！

迁移分析报告详细介绍了将应用程序从较旧的 JDK 版本迁移到所需的较新 JDK 版本所涉及的迁移工作和风险。

该工具确实可以帮助您量化和衡量迁移所需的工作量，提供所需操作/练习的清晰图片，并帮助您做出明智的决策。

还在为您的迁移而担忧吗？ …在这里查看这个工具：- Java Migration Analysis

‍

• 从 Java 17 开始，强制执行更严格的封装，阻止对私有/受保护（非公共）字段和方法的未经授权的反射，如果您的代码到目前为止使用许可反射，在编译代码时则需要添加“–add-exports”和“–add-opens”。

–add-exports 允许运行时/编译时访问封装的内部 API，而 –add-opens 允许反射到“外部”Java API。

• 如果您使用的是 javax.util.regex.Pattern 类，请记住 Java 8 之后它的行为略有不同。否定运算符“[”用大括号括起来。
• 因此， [^u-v[w-x]y-z] 现在不会匹配 w 和 x，因为该运算符现在也适用于嵌套类。
• 在 Java 8 之前，它会匹配 w 和 x（之前不适用于嵌套类），但不会匹配 u-v 和 y-z，因为它们不是嵌套的。
• 您可以查看官方文档以获取更多详细信息和细粒度示例，包括 && 和 || 等等。

规划迁移工作、使用上述工具和问题将使您的流程更加顺利，并推动您成功迁移。充分的准备将简化您的流程并使其富有成效。

以下是迁移的两个常规清单：

除了“准备迁移”部分中详细介绍的步骤之外，以下步骤可以作为迁移的清单：

• 如果您的代码依赖版本字符串格式来区分主要版本、次要版本、安全版本和补丁更新版本，那么您可能需要更新它。

新版本字符串的格式为：$FEATURE.$INTERIM.$UPDATE.$PATCH

• Class loader changes – 类加载器更改 – 应用程序类加载器现在是一个内部类，它不再是 URLClassLoader 的实例。扩展类加载器已更名为平台类加载器。引导类加载器现在加载很少的类，因此使用 Xbootclasspath/a 部署的 Java 8 应用程序或创建以 null 作为父级的类加载器的 Java 8 应用程序可能需要更改。
• AppleScript、一些特定于 Apple 的包（例如 com.apple.eawt 和 com.apple.eio）被 java.awt.Desktop 包中与平台无关的对应项替换。您无法编译使用它们的代码，但编译为旧版本的现有代码将继续运行，因为它们（旧包）仅可用于运行时。
• 您无法选择 JRE 版本，如果您在命令行上使用version选项或在 JAR 文件中找到 JRE-Version清单条目，您将收到错误消息。

已弃用：- 有关已弃用功能的完整列表，请参阅此链接

• deprecated. 方法 javax.management.remote.JMXConnector.getMBeanServerConnection(Subject) 支持旧版主题委托功能，并且仅与其他已弃用的 API 结合使用，因此现已弃用。
• Applet API 以及 AWT 包中的许多接口和类现已弃用。
• 用于解析 String 以获取 Byte/Double/Float 等的构造函数方法已被弃用，您必须使用静态替代方法。
• 用于挂起/恢复/停止线程的线程方法已被弃用，您可能需要编写简单地修改某些变量的代码来指示目标线程应该停止运行。

Spring Boot 3 至少需要 Java 17，我们将安装 Java21，因此应牢记以下问题。

• 由于 Java EE 已更改为 Jakarta EE，Spring Boot 3.0 的所有依赖项 API 也从 Java EE 迁移到 了 Jakarta EE。一些主要依赖项/包名称需要更改为：- 例如
• lua
• 复制代码
• *.javax.servlet.* –> jakarta.servlet.* *javax.persistence.* –> jakarta.persistence.* *javax.validation.* –> jakarta.validation.*
• Spring Boot 3 是一个重大升级，因此需要更改几个配置属性，我们可以在 pom.xml 中使用 spring-boot-properties-migrator。可以在这里找到。

这将处理大多数所需的依赖项更改和命名更改。不过，下面列出了一些需要提及的重要配置。

1. 由于我们正在升级 Java 和 Spring，因此您还应该将第 3 方 jar 更新到最新版本，例如Hibernate 6.3、Hibernate Validator 8.0、Jackson 2.15、Jersey 2.41、SLF4J 2.0.6、Tomcat 10.1 等。
2. Micrometer 1.10 中引入的最新观察 API 和 Micrometer Tracing

a.) 由于新的 Spring Boot 版本不推荐使用配置 尾部斜杠匹配的选项，因此如果您需要启用尾部斜杠匹配，请定义自己的配置类

复制代码

publicclassWebConfigurationimplementsWebMvcConfigurer {@OverridepublicvoidconfigurePathMatch(PathMatchConfigurer configurer) { configurer.setUseTrailingSlashMatch(true); } }

1. 属性 server.max.http.header.size 已弃用，取而代之的是 server.max-http-request-header-size，它现在仅检查请求标头大小。因此，您可能需要定义一个实现 WebServerFactoryCustomizer 接口的新 bean，以定义响应标头大小的限制。例如。

复制代码

@ConfigurationpublicclassMyServerConfigurationimplementsWebServerFactoryCustomizer {@Overridepublicvoidcustomize(TomcatServletWebServerFactory defFactory){ defFactory.addConnectorCustomizers(newTomcatConnectorCustomizer() {@Overridepublicvoidcustomize(Connector myConnector) { connector.setProperty(\”maxHttpResponseHeaderSize\”, \”200000\”); } });} }

1. Spring Boot 3.0 使用 Spring Security 6.0。 ，因此您可能需要在此处添加细粒度的安全设置。
2. 您还可以查看 Spring-Boot-3.0-Migration-Guide 和 Spring-Framework-6.0-Migration- Guide 了解细粒度的详细信息。

由于我们不知道您的应用程序实现的具体业务逻辑，也不知道其内部架构，因此我们建议至少阅读一次迁移指南。

一旦 Java 21 能够正常工作，以下措施将有助于充分利用 Java 21：-

• 如果需要，可以使用 javac 工具中的新 –release 标志交叉编译到平台的旧版本。
• 使用静态分析工具 jdeprscan 来查明您是否仍在使用任何已弃用的 API
• 升级代码时值得考虑 IDE 的建议
• 想要使用最新 Apple Metal API 的 Mac OS 用户可以启用新的渲染管道 openjdk.java.net/jeps/382
• 添加我们的 IDE 插件的强大功能； Java 的开源记录和回放，包括断言、模拟和代码覆盖率；通过安装未登录。

我们讨论了升级到 Java 21 的一些关键优势以及 Java 21 中的开创性功能。为了简化迁移过程，我们讨论了如何为迁移做好准备、使用专门为此目的制作的工具、清单和问题来简化迁移过程。意识到。此外，我们还建议升级到 Spring Boot 3.2，以及如何最好地进行 Spring Boot 2 到 Spring Boot 3.2/ Spring Framework 6 的迁移。

所有想要充分利用最新技术、保持应用程序灵活和可扩展、增强安全性和弹性并为未来增强做好充分准备的人；应该阅读这个博客。

Java 非常重视跟上现代语言和流行的使用模式，因此 Java 21 不仅具有开拓性，而且还将使您能够利用未来的创新。

谢谢你的阅读 ：）

云服务器部署前后端分离项目（若依）详细教程

镜像下载、域名解析、时间同步请点击

第一次在Linux云服务器上部署前后端分离项目，查了很多资料和视频，踩了许多坑。成功实现部署若依的前后端分离项目后，想记录一下前后端部署的过程，供学习的小伙伴参考。

一定要在开始前先准备好以下工具和环境（可以上网查找安装的方法），后续还会对其进行修改：

• 购买一个云服务器，例如阿里云等等，操作系统为Linux centos7.x
• 在云服务器上安装Nodejs（之前的博客有安装方法）
• 在云服务器上安装Nginx
• 在云服务器上安装jdk1.8+（推荐1.8）
• 在云服务器上安装mysqk5.7+（推荐5.7）
• 在云服务器上安装redis
• 远程连接工具xshell或者finalshell

若依前后端项目地址：https://gitee.com/y_project/RuoYi

若依前后端项目使用手册地址：http://doc.ruoyi.vip/ruoyi/

进入网址将项目下载或者git clone到本地并解压:

在这个项目中，ruoyi-ui文件夹是前端项目，其余为后端项目，我们接下来需要分开打包部署。

通过xshell或者FinalShell远程连接服务器，连接指令：

user为服务器的用户名，一般为root，ip是服务器的ip,默认端口号为22，例如：

如果连接失败可能是服务器没有开启远程连接许可或者端口等等，可以搜寻相关方法解决。

（1）首先将项目中ruoyi-ui这个文件夹上传至服务器，可以用FinalShell的文件管理功能，也可以用服务器管理的上传文件功能，例如宝塔界面里的文件管理：

可以专门建一个目录存储它们，例如在根目录下创建了一个project文件夹

（2）依次输入如下命令，进入ruoyi-ui文件夹，并对前端代码进行打包,生成一个dist文件夹，这就是前端代码打包后的文件：

（3）修改nginx的配置文件（也就是nginx.conf），使其前端项目能够被访问，一般nginx会被安装在/usr/local目录下，因此配置文件路径为/usr/local/nginx/conf/nginx.conf 。如果忘记nginx安装在哪里了，可以用如下命令找到它：

用vim编辑器打开nginx.conf，修改配置。修改的几个地方，最好图中的信息都一样，红色框框圈出来的是容易忽略的地方如下：

1、 修改为root用户

2、修改监听listen的端口号为9000，这个端口号取决于自己想从几号端口访问前端页面，后续也别忘了在防火墙中开启这个端口，不然无法访问；server_name为你的服务器ip，如果你有域名且配置解析好了，也可以再在此添域名

3、找到这些内容并将root 后跟的路径修改为刚才前端代码打包的dist文件夹的路径，保存后退出。如果仍不清楚改哪里，可以翻倒博客最后面的部分，有两张nginx.conf的整体示意图。

4、由于上述前端使用的是9000端口（也可以换为你自己想要的端口，例如80端口），因此要在防火墙中也打开这个端口，外界才可以访问。于此同时，后端也需要一个8080端口，因此也要将其打开，后续部署后端服务要用到。注意有时候可能你想用的端口已经被其他进程占用，可以尝试找到该进程并将其kill掉或者重新开另一个端口号，具体方法不在此赘述，可上网查询。

我用的是阿里云的轻量应用型服务器，因此还需要检查以下宝塔界面的“安全”里面是否开启该端口，以及阿里云服务器工作台里的“安全”->“防火墙”中的端口，如果没有开启，则需要在这里手动开启。此外阿里云的ECS云服务器需要为该端口号添加安全组规则。

5、端口配置好了后，每次修改了nginx的配置文件后一定要重新启动nginx，使新配置生效。如果重启失败，则先找到nginx的进程，然后将其kill掉，再重启nginx：

6、浏览器输入“ip:9000“，例如：198.172.1.1:9000，如果出现出现如下画面，则表示前端启动成功。否则则需要仔细检查两个地方，一个是nginx的配置信息，一个是端口是否真的被完全打开：

（1）配置服务器上的mysql数据库，使mysql数据库可以被远程访问。具体教程可以看https://blog.csdn.net/VariatioZbw/article/details/105823337开启后可以在服务器上远程连接一下看是否成功：

（2）redis数据库也要配置好，例如它的端口要被打开，设置密码，具体方法可以参考网上的方法。

（3）进入mysql数据库，建一个名为ry-vue的数据库

将之前下载好的项目文件夹中的sql文件夹里的两个数据表上传到服务器中，我们可以继续将这两个文件放在之前在服务器根目录下创建好的project目录里面

然后登录进入mysql数据库，使用刚才创建ry-vue数据库，导入两个数据表进入ry-vue数据库中：

(4) 修改项目中ruoyi-admin中的三个文件，如下：

在application.yml中，修改redis的信息，分别为host地址（你的服务器ip），port端口号（你的redis开放的端口号，一般为6379），password密码（你的redis的密码）。

在application-druid.yml中，修改mysql的信息，url的中间填写访问mysql的 ip:端口号，例如：198.172.1.1:3306；username填你的mysql用户名；password填你的mysql密码。

在logback.xml中，找到日志存放路径，value修改为你存放日志的目录，可以在之前创建的project文件夹中建一个logs文件夹，则填为value=”/project/logs“

自此，该修改的已经修改完了。

（5）尝试运行后端项目

可以通过InteliJ IDEA或者eclipse软件来运行这个java后端项目，前提是你运行的本机上应该也具备一定的环境，jdk>=1.8，以及本地8080端口（用于后端）已开启且未被占用。其他的例如mysql，redis可以直接通过服务器ip+端口号远程访问，不需要在本机上配置。

出现如下表示启动成功，可以开始打包后端代码。如果未成功也不用灰心，检查报错，是否关于mysql，redis的（如果是，则可能是这两个没有在你的服务器上配置好或者刚才修改的信息出错了，例如账号，密码不对，或者远程连接未成功，导致本机无法远程访问等等），如果是关于8080端口，可能是由于你本机有程序以及占用了8080端口，这个基本上就不是什么问题，部署到服务器后只要服务器8080端口可用就行。接下来可以直接打包代码。

（6）打包后端代码jar包

熟练使用java的人可以直接通过InteliJ IDEA或者eclipse软件打jar包。不熟悉的有第二种方法，是若依提供的。进入下载的项目文件夹中的bin目录下，直接双击执行package.bat，它会直接在项目中生成target文件夹，里面包含以及打包好的jar包。我们要使用的是ruoyi-admin文件夹下的target里的jar包。运行package.bat需要marven环境>=3.0，自行参考网上方法按照。如下图操作顺序：

将这个ruoyi-admin.jar包上传至服务器，可继续存于刚才建的project目录中。

（1）再此修改nginx配置文件（nginx.conf），添加后端信息。proxy_pass中空余的部分填服务器ip地址，别忘了上面是location /prod-api/。修改后别忘了重启nginx服务，用上面刚才提到的命令。

修改未prod-api是由于前端发送请求的时候就是通过这个接口来发送的

nginx配置文件nginx.conf的整体示意图（包括前端和后端配置修改的所有地方）：

（2）远程连接服务器，进入project目录，后台启动jar包：

用浏览器访问”ip:前端端口号“：

输入验证码登录后成功进入后台：

本文转自：https://blog.csdn.net/weixin_44248258/article/details/124213606

Spring Security+ OAuth+单点登录原理 笔记

1 单点登录

关于单点登录的原理，我觉得下面这位老哥讲的比较清楚，有兴趣可以看一下，下面我把其中的重点在此做个笔记总结

https://juejin.cn/post/6844904079274197005

主流的单点登录都是基于共享cookie来实现的

1.1 同域单点登录

适用场景：都是企业内部系统，所有系统都适用同一个一级域名，并通过不同的二级域名区分

举个例子：公司有一个一级域名cjs.com，我们有三个系统需要实现单点登录，分别是门户系统（sso.cjs.com）、应用系统1（app1.cjs.com）、应用系统2（app2.cjs.com）

1. 门户系统设置 Cookie 的 domain 为一级域名也就是 cjs.com，这样就可以共享门户的 Cookie 给所有的使用该域名（xxx.cjs.com）的系统
2. 使用 Spring Session 等技术让所有系统共享 Session
3. 所有登录都跳转到门户系统去登录，也就说门户系统有两个页面就够了：登录页（login.html）和首页（index.html）。通过首页链接可以进入到各子业务系统。
4. 可以在加一层网关（Spring Cloud Gateway）

1.2 跨域单点登录

由于域名不一样不能共享 Cookie 了，这样就需要通过一个单独的授权服务(UAA)来做统一登录，并基于共享UAA的 Cookie 来实现单点登录。

举个例子：公司接到一个大项目，把其中部分系统外包给第三方来做，或者直接采购第三方服务商的系统，或者是子业务系统1采购服务商A的系统，子系统2采购B服务商的系统。无论什么情况，总之系统集成就需要单点登录。

1. 用户访问系统1，如果未登录，则跳转到UAA系统请求授权，并输入用户名/密码完成登录
2. 登录成功后UAA系统把登录信息保存到 Session 中，并在浏览器写入域为 sso.com 的 Cookie
3. 用户访问系统2，如未登录，则跳转到UAA系统请求授权
4. 由于是跳转到UAA系统的域名 sso.com 下，所以能通过浏览器中UAA的 Cookie 读取到 Session 中之前的登录信息完成单点登录

1.3 基于OAuth2的跨域单点登录

1.4 前后端分离的跨域单点登录

前后端分离的核心概念是后端仅返回前端所需的数据，不再渲染HTML页面，前端HTML页面通过AJAX调用后端的RESTFUL API接口并使用JSON数据进行交互

跨域间的前后端分离项目也是基于共享统一授权服务(UAA)的cookie来实现单点登录的，但是与非前后分离不一样的是存在以下问题需要解决

1. 没有过滤器/，需要在前端判断登录状态
2. 需要自己实现oauth2的授权码模式交互逻辑
3. 需要解决安全性问题，oauth2的clientSecret参数放在前端不安全

• redirect_uri写前端地址
• 重定向到前端页面，页面获取到授权码code，拿code换token

示例参考：

http://localhost:9000/callback.html?code=xxx

</body>

</html>

2 Spring Security OAuth 2.0迁移指南

从 Spring Security 5.2.x 开始，OAuth 2.0 Clients 和 Resource Servers 已经从 Security OAuth 2.x 迁移到 从 Spring Security，而且 Spring Security 不再提供 Authorization Server 的支持。

总之呢，Spring Security OAuth这个项目以后就处于维护状态了，不会再更新了，建议使用Spring Security

迁移以后，很多地方都不一样了，就我注意到的说下几点变化

首先，以前单点登录使用@EnableOAuth2Sso注解，现在推荐使用oauth2Login()方法

其次，授权服务器的写法不一样了

默认的端点都变成 /oauth2 开头了

更多变化可以阅读源码，亦可参见 OAuth 2.0 Features Matrix 查看二者支持的特性

3 @EnableOAuth2Sso的作用

@EnableOAuth2Sso: 标记服务作为一个OAuth 2.0客户端。这意味着它将负责将资源所有者(最终用户)重定向到授权服务器，在那里用户必须输入他们的凭据。完成后，用户被重定向回客户端，并携带授权码。然后，客户端获取授权码，并通过调用授权服务器以获取访问令牌。只有在此之后，客户端才能使用访问令牌调用资源服务器。

4 补充：根据pid递归查找子机构

5 有用的文档

Spring Security相关

• https://docs.spring.io/spring-security/reference/index.html
• https://docs.spring.io/spring-security/reference/servlet/index.html
• https://docs.spring.io/spring-security/reference/servlet/oauth2/index.html
• https://github.com/spring-projects/spring-security-samples/tree/main
• https://github.com/spring-projects/spring-security-samples/tree/main/servlet/spring-boot/java
• https://github.com/spring-projects/spring-security-samples/tree/5.6.x/servlet/spring-boot/java/oauth2/login
• https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide
• https://github.com/jgrandja/spring-security-oauth-5-2-migrate

Spring Boot OAuth相关

• https://docs.spring.io/spring-security-oauth2-boot/docs/current/reference/html5/

原文链接：https://www.tuicool.com/articles/eUruuez

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com