Синхронизация развертывания между микросервисами

Question

Допустим, есть две среды: staging и prod .
Есть также два микроуслуги: A и B .
Микросервисы уже развернуты в обеих средах и в каждой работающей версии сервиса 1. Итак, у нас есть:

• подготовка: A1, B1
• prod: A1, B1

Теперь одна группа разработчиков внедряет новую функцию в микросервисе A (либо синхронный API, либо asyn c один через посредник сообщений) и развертывает A2 для подготовки. Затем другая команда внедряет новую функцию в B, которая использует новую функцию из A2, а также развертывает ее в стадии (B2). Теперь у нас есть:

• подготовка: A2, B2
• prod: A1, B1

Новые функции тестируются в промежуточной среде клиентом и имеются одобрен для использования в производстве. Вопрос заключается в том, как определить, какие службы следует развернуть в первую очередь для производства. Очевидно, что B2 не должен быть развернут в первую очередь, потому что это зависит от A2. Существуют ли какие-либо инструменты / стратегии для отслеживания этого?

Я могу себе представить, что все сервисы отслеживают, от каких версий других сервисов они зависят, и во время развертывания эти версии проверяются на соответствие тем, что выполняется в целевой среде. а если чего-то не хватает, то развертывание отклоняется.

Это поднимает вопрос - должно ли развертывание микросервиса быть параллельным или одно-микросервисным за один раз?

И что если перед развертыванием A2 и B2, чтобы продвинуться, будет A3 выпущен к организации, и будет зависеть от B2? Теперь мы должны запланировать развертывание в производство следующим образом:

A2 => B2 => A3

Это реальные примеры, которые мне приходят в голову, но, возможно, в архитектуре микросервиса можно избежать такая ситуация по каким-то правилам?

Answer 1

Управление версиями в точках интеграции может быть опцией.

Например, если microservice-A получает информацию от microservice-B посредством вызова REST, когда microservice-B хочет изменить интеграцию (например, изменение в контракте на остальные вызовы), microservice-B может добавить новую конечную точку с помощью новое версионное отображение типа "/ getInformationFromMeV2" без удаления старого. Таким образом, при развертывании microservice-B microservice-A может некоторое время использовать старую конечную точку. После развертывания microservice-A вы также можете удалить старую конечную точку из microservice-B при следующем развертывании.

Примечание. Конечно, если microservice-A хочет использовать недавно разработанную конечную точку из microservice-B, microservice-B должен быть развернут до микросервиса A.

---

Для асинхронной c связи вы все равно можете применить этот подход. Если вы используете коммуникацию на основе брокера, например Kafka (предположим, что вы хотите сначала развернуть microservice-A):

• Если microservice-A является потребителем , тогда новые топи c создано, и microservice-A также подписывается на новый topi c, а для microservice-A развернута новая версия. В этот момент microservice-A получает сообщения как из новых, так и старых тем (конечно, пока не будет развернут microservice-B, все сообщения будут отправлены на старый topi c) после того, как microservice-B также будет развернут, старый topi c удаляется.

• Если microservice-A является производителем , снова создается новая topi c и после развертывания microservice-A новые сообщения отправляются в новые topi c. Когда Microservice-B также развернут, он начинает читать сообщения с начала новой topi c, а старая topi c удаляется.

При таком подходе вы можете развертывать микросервисы независимо от того, насколько удобна архитектура микросервисов.