Использование общих (shared) библиотек в микросервисах - плохая практика. Но каждый микросервис в любом случае имеет зависимости на фреймворки и библиотеки. Например, Spring Boot, Kafka Java Client и т.д.
Если система состоит из 30 микросервисов, основанных на Spring Boot и использующих Gradle или Maven в качестве инструмента для сборки и распространяемых в виде Docker образов, существует ли простой способ обновить версию Spring Boot во всех микросервисах? Обновление всех микросервисов одного за другим занимает много усилий. И чем больше микросервисов в системе, тем больше усилий требуется.
Причиной для обновления может быть уязвимость в зависимостях.
Например, Spring Boot 2.2.0.RELEASE зависит от Tomcat 9.0.27, который имеет уязвимость
CVE-2020-1938 (уязвимость взята просто в качестве примера). Уязвимость была исправлена в Tomcat 9.0.31, поэтому обновление до Spring Boot 2.2.4.RELEASE решает проблему.
Есть вариант объявить версию Spring Boot в
build.gradle как
2.2.+. Но это вносит неопределенность относительно используемых версий, и кто-то все еще должен пересобрать все микросервисы.
Если уязвимость критична, нет времени ждать новой версии Spring Boot с исправлением, и Tomcat должен быть явно обновлен в
build.gradle. Или даже заменить на Undertow, что также требует изменений в
build.gradle.
Использование standalone Tomcat вместо встроенного (embdedde) также не очень помогает, поскольку микросервисы распространяются как Docker образы, а не как файлы WAR, которые разворачиваются в Servlet контейнере.
В Java EE обновления безопасности
в теории были очень просты. Вы обновляете сервер приложений (например, WildFly) или устанавливаете security patch, и если приложение использует только Java EE API, никаких изменений больше не требуется. Существует ли аналогичная концепция простых обновлений зависимостей для микросервисов (по крайней мере, в теории)?
Простой
