Comments 15
1) А теперь представьте, что MsA разрабатывает одна команда, а MsB другая?
2) А ещё у вас 20 сервисов. Вы обновили в одном пакет и сломали другие 19. Придется вам не обновляться...
3) Также если у вас 20 сервисов, шанс что пакеты устаканится стремится к нулю
1) А теперь представьте, что MsA разрабатывает одна команда, а MsB другая?
Ээ… Разрабатывают разные команды… и?
2) А ещё у вас 20 сервисов. Вы обновили в одном пакет и сломали другие 19. Придется вам не обновляться…
На практике вообще не проблема. На практике есть небольшой набор общих для всех микросервисов пакетов, (а конкретно mongoose, axios, nats, express, ..) и некоторым микросервисам нужны специфичные пакеты, которые больше никто не использует.
Например один микросервис отвечает за рендеринг PDF, другой за вебсокеты, третий за связь со сторонним приложением.
Добавить специфичный пакет в базовый образ — не страшно, это никак не отразится на других 19. Обновить свой специфичный пакет (например рендеринга PDF) — опять же, не страшно. Другие 19 он никак не заденет.
Другое дело если пакет общий. Например, если вышла новая мажорная версия mongoose с брейкин ченджем. Тогда либо надо собрать силу волю и команды в кулак — и всем вместе обновится. Либо, если вам так нужна новая фича в монгусе, а других подбить на апдейт не получается — то просто базируете свой микросервис не на общем BaseMS, а на Node по старинке. (но на практике такого не помню)
3) Также если у вас 20 сервисов, шанс что пакеты устаканится стремится к нулю
Повторюсь — добавлять и обновлять специфичные пакеты в базовый образ — не страшно.
Что за потребность такая сэкономить 3Гб ценой организационных ограничений при наличии нескольких команд? Экономическая целесообразность этого шага, на мой взгляд, сильно отрицательная.
Отмечу, кстати, что это уменьшение скорее не на 3Гб, — а скорее уменьшение в 20+ раз. Это сильно сказывается, когда приходится обновлять установ на продакшене или тестовом контуре. Одно дело, когда удаленный сервак выкачивает 3 Гб, и совсем другое, когда 0.15 Гб. Да даже не удаленный сервак, а локальное хранилище образов гораздо лучше себя чувствует.
А целиком все микросервисы обновляются периодически. У нас есть npm-пакет с интерфейсами и т.д. общий для всех микросервисов, он обновляется нередко. И каждый раз пушить 3 Гб, а потом тянуть их — так себе
У нас есть npm-пакет с интерфейсами и т.д. общий для всех микросервисов, он обновляется нередко
Дайте угадаю, у вас еще и БД общая и микросервисы общаются друг с другом напрямую, а не разавязаны через какую-нибудь кафку?
То что БД развели - это важный шаг от "распределенного монолита".
Однако единый npm-пакет с интерфейсами и общение через HTTP - на мой взгляд идут в "минус".
Например по HTTP, классический сценарий - один сервис вызвал другой, тот третий, а третий решил немного "подумать", вся цепочка начинает просаживаться по ресурсам или перестаёт выполнять свои функции.
Но вот практический пример: в реквесте один параметр из опционального решили сделать обязательным, обновили базовый образ, автоматом обновили везде package.json, — и вдруг перестал собираться всеми забытый микросервис. Это же прекрасно, что ошибка обнаружилась на этапе компиляции, а не на проде где-то что-то отвалилось и надо искать где и что. Это вот прям жирнейший плюс общего пакета
Over-engineering в чистом виде.
Достаточно ведь просто сделать контейнеры с микросервисами, в которых исключительно production зависимости. Устанавливать их через multistage (в большинстве случаев, эта установка уже под кешом внутренней сети).
Ну и просто не раздувать количество зависимостей. Иначе шутка о том, что npm выкачивает пол интернета, станет правдой...
Делаем микрообразы с микросервисами