【发布时间】:2020-06-13 09:39:26
【问题描述】:
在微服务中使用共享库是一种不好的做法。但是每个微服务都依赖于框架和库: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 中的Spring Boot 版本声明为2.2.+。但是仍然有人必须重建所有微服务(例如,在 Jenkins 上)。
此外,通过这种方法,您可以放松对版本管理的控制并将其委托给 Gradle(始终尽可能使用最新版本)。为了仍然可以控制依赖关系,可以在 gradle.properties 中声明版本并由 Jenkins 以某种方式挂载到工作区中:
spring.version=2.2.4.RELEASE
如果漏洞很严重,则没有时间等待带有修复的新 Spring Boot 版本,并且必须在 build.gradle 中明确更新 Tomcat。甚至替换为 Undertow 也需要更改 build.gradle。
使用独立的 Tomcat 而不是嵌入式也没有多大帮助,因为微服务是作为 Docker 映像而不是作为部署到 servlet 容器的 WAR 文件分发的。
在 Java EE 中,安全更新理论上非常简单。您更新应用程序服务器(例如 WildFly)或应用安全补丁,如果应用程序仅使用 Java EE API,则无需进一步操作。微服务是否有类似的简单依赖更新概念(至少在理论上)?
【问题讨论】:
-
虽然不规范,但这是一个非常有趣的问题。
-
这就是许多公司转向 monorepo 的原因。
标签: java spring-boot architecture microservices software-design