轻松更新大量微服务中的构建依赖项

Question

在微服务中使用共享库是一种不好的做法。但每个微服务都依赖于框架和库：Spring Boot、Kafka Java Client 等。

如果一个系统由 30 个基于 Spring Boot 的微服务组成，使用 Gradle 或 Maven 作为构建工具并以 Docker 镜像的形式分发，是否有一种简单的方法来更新所有微服务中的 Spring Boot 版本？将所有微服务一一更新需要付出很大的努力。而且系统的微服务越多，需要付出的努力就越多。

更新的原因可能是某些依赖项中存在安全漏洞。例如，Spring Boot 2.2.0.RELEASE依赖于存在漏洞CVE-2020-1938的Tomcat 9.0.27 （仅作为示例）。该漏洞已在 Tomcat 9.0.31 中修复，因此更新到Spring Boot 2.2.4.RELEASE将解决该问题。

build.gradle解决方法是在as中声明 Spring Boot 版本2.2.+。但仍然需要有人重建所有微服务（例如，在 Jenkins 上）。

此外，通过这种方法，您可以放松对版本管理的控制，并将其委托给 Gradle（始终使用可能的最新版本）。为了仍然控制依赖项，可以gradle.properties在 Jenkins 中声明版本并以某种方式安装到工作区中：

spring.version=2.2.4.RELEASE

如果漏洞很严重，则没有时间等待新的 Spring Boot 版本进行修复，并且 Tomcat 必须在build.gradle. 或者甚至替换为 Undertow 也需要更改build.gradle.

使用独立 Tomcat 而不是嵌入式也没有多大帮助，因为微服务作为 Docker 映像分发，而不是作为部署到 servlet 容器的 WAR 文件。

在 Java EE 中，安全更新理论上非常简单。您更新应用程序服务器（例如WildFly）或应用安全补丁，如果应用程序仅使用Java EE API，则无需采取进一步操作。微服务是否有类似的简单依赖更新概念（至少在理论上）？

Answer 1

顺便说一句，微服务通过使组件更加自主和可维护来带来价值，但这也是有成本的：集成它们并维护它们并不便宜。所以微服务粒度也应该在这方面考虑。

如果一个系统由 30 个基于 Spring Boot 的微服务组成，使用 Gradle 或 Maven 作为构建工具并以 Docker 镜像的形式分发，是否有一种简单的方法来更新所有微服务中的 Spring Boot 版本？将所有微服务一一更新需要付出很大的努力。而且系统的微服务越多，需要付出的努力就越多。

使用您引用的 Jenkins 等 CI 工具，每个微服务应用程序中的相关自动化测试，更新其 pom/gradle 文件的 spring 版本，甚至将它们部署在具有 Ansible 等自动化 IT 基础设施工具的集成环境中并不困难。
一般来说，如果项目属于多模块项目，则可以使用 maven/gradle 插件更新所有项目的依赖版本（maven 版本插件和 gradle 版本插件执行此操作）。
如果项目不属于多模块项目，还有其他选择，但您应该添加手动 SCM 检索步骤。
整个任务可以使用 shell 脚本完成，或者更好地使用 jenkins 作业将要使用的 spring boot 版本作为自定义作业参数，并且您可以按需执行。使用 Jenkins 仍然更好，因为您可以编写一个管道作业，集成 SCM 检索、docker 代理、构建执行以及需要时的 shell 执行。总体而言，您可以将执行步骤的所有详细信息（成功或失败）保留在团队使用的工具中。

在 Java EE 中，安全更新理论上非常简单。您更新应用程序服务器（例如 WildFly）或应用安全补丁，并且如果应用程序仅使用 Java EE API，则无需采取进一步操作

从我最近的记忆来看，在所有环境中更新 Java EE 服务器从来都不是一件容易的任务（不像更新文件中的版本那么简单）。
更新Weblogic和Websphere的官方程序非常非常挑剔，更新也需要很多时间，因为这些服务器怎么说……臃肿，而且回滚到以前的版本也并不总是那么容易。