Управление версиями продуктов Microservices

Я вхожу в архитектуру микросервисов на основе докеров, и у меня есть 3 микросервиса, которые вместе создают один продукт, например, "CRM-система".

Теперь я хочу, чтобы мой клиент смог обновить свой продукт, когда захочет. У меня есть 3 разных версии моих микросервисов, которые нужно увидеть клиенту? Я предполагаю, что версия продукта должна быть независимой от микросервисов, потому что копирование одной из версий микросервисов заставит меня пойти побольше проблем, чем вообще не иметь версии.

Так есть ли какая-то модель, идея справиться с такой ситуацией?

Единственное, что приходит мне на ум - это иметь другой репозиторий, который будет версироваться, когда один из микросервисов будет готовить готовый пакет. Тем не менее, у меня теперь есть версия, о которой ни один из моих владельцев продуктов (ПО) никогда не узнает.

Ответы

Ответ 1

Управление версиями микросервиса

Прежде всего убедитесь, что Semantic Versioning (SemVer) строго соблюдается микросервисами. Не делать этого рано или поздно приведет к проблемам несовместимости.

Записывайте только изменения API в этой версии, не смешивайте их с внутренним версированием микросервиса (например, для управления версиями схемы DB для службы с БД).

Версия продукта

Представьте версию для продукта, как вы уже сказали. Следующий SemVer также имеет смысл здесь, но, возможно, его нужно будет ослабить, чтобы удовлетворить маркетинговые потребности (например, позволить увеличить прирост главной версии, даже если SemVer потребует лишь незначительной модификации). В крайних случаях используйте специальные "технические версии" и "маркетинговые версии". Это, тем не менее, более сложно для клиентов.

Также обратите внимание, что вам нужно будет определить, что означает версия SemVer с точки зрения вашего приложения, так как приложение в целом не имеет "API".

Управление зависимостями

Теперь конкретная версия продукта представляет собой список микросервисов определенных версий. Обратите внимание, что это по существу управление зависимостями в том же смысле, что и apt, npm, bower и т.д. Трудно сказать, насколько сложно ваше решение, но я рекомендую хотя бы поддержать понятие "минимально необходимых версий". Если у докера есть встроенный механизм, попробуйте использовать его (я не знаю докера очень хорошо, поэтому не могу сказать).

Таким образом, вы можете указать, что ваш продукт в версии 4.8.12 требует обслуживания A в версии 1.12.0 и службы B в версии 3.0.4.

Механизм обновления должен следовать стратегии, которая придерживается SemVer. Это означает, что установка определенной версии продукта автоматически устанавливает новейшие службы с той же основной версией. В приведенном выше примере это может, например, установить 1.12.2 службы A и 3.3.0 службы B. Предоставление механизма для сохранения уже установленных служб, соответствующих требованиям зависимости, может быть хорошей идеей, чтобы пользователи не раздражались по механизму обновления.

Ответ 2

Для этой литературы используется 5-мерная модель:

  • версия (хочет изменить)
  • статус (жизненный цикл: создание, тестирование, развертывание, выход на пенсию)
  • просмотр (источник, развертывание, документация)
  • иерархия (продукт, микросервис)
  • вариант (в основном аналогичный, описывающий различия, семейства продуктов)

Большинство систем обрабатывают только некоторые из этих размеров. Чтобы обрабатывать все пять, вы должны описать (исправить) свой процесс разработки.

Когда вы смотрите только на версию плюс иерархию, как вы здесь, с продуктом и микросервисом, версиями отдельно: версия продукта должна измениться, как только пользователи продукта заметят что-то другое. Возможно, вы захотите сообщить, что из версии управления микросервисом можно использовать мажоритарную нумерацию: малый не должен влиять на версию продукта, майор должен. Или вы можете использовать диапазоны версий/семантическое управление версиями.

Ссылка:

Управление проектными данными: пять измерений каркасов САПР, управление конфигурацией и управление данными о продуктах. ван ден Хамер, П. Лепотер, К. Филипс Реш., Эйндховен;

Эта статья представлена в: Материалы IEEE Дата публикации: январь 1996 г. Том: 84, выпуск: 1 На странице: 42-56 ISSN: 0018-9219 Ссылки Цитировано: 26 КОД: IEEPAD INSPEC Номер доступа: 5175049 Цифровой идентификатор объекта: 10.1109/5.476025 Текущая версия Опубликовано: 2002-08-06