T
Я работал и с монорепо, и с монолитом, и с одним пакеджом на все, и микросервисами. И я могу сравнить плюсы плюсы и минусы того или инного решение. И я полностью поддерживаю @devsinglesly
Size: a a a
2020 September 18
T
кайф микросервисов еще в том, что можно оставлять хоть версии 10 летней давности на микросервисах которые пишутся 1 раз на 100 лет. И ничего с ними не произойдет.
Имхо омновное преимущество микросервисов проявляется при 50+ человек. Тогда можно легко разбить на ращные зоны ответсвенности так, чтобы одни другим не мешали добавлять новые фичи в приложение. Именно с точки зрение менеджмента и деливери тут основной бенефит
АП
ты не понял. Это был моно репозиторий с одним package.json, за который ты топишь. Мы выкатили обновление для сервиса который там откровенно говоря занимался какой то ерундой. А по итогу обновились зависимости во всех 3. А железки не могли работать с новым форматом и мы упали.
погоди
у тебя есть три микросервиса в одной репе
они общаются через одного брокера? ты накатывал обновление, и система полетела потому что с другой стороны есть железки, которые используют этот же брокер, но на них обновление не накатили?
всё верно описал?
просто при такой ситуации проблема вовсе не в монорепе
у тебя есть три микросервиса в одной репе
они общаются через одного брокера? ты накатывал обновление, и система полетела потому что с другой стороны есть железки, которые используют этот же брокер, но на них обновление не накатили?
всё верно описал?
просто при такой ситуации проблема вовсе не в монорепе
D
погоди
у тебя есть три микросервиса в одной репе
они общаются через одного брокера? ты накатывал обновление, и система полетела потому что с другой стороны есть железки, которые используют этот же брокер, но на них обновление не накатили?
всё верно описал?
просто при такой ситуации проблема вовсе не в монорепе
у тебя есть три микросервиса в одной репе
они общаются через одного брокера? ты накатывал обновление, и система полетела потому что с другой стороны есть железки, которые используют этот же брокер, но на них обновление не накатили?
всё верно описал?
просто при такой ситуации проблема вовсе не в монорепе
это не микросервисы. вы путаете
D
микросервисы не могут общаться между собой кроме как по открытому АПИ интерфейсу
A
погоди
у тебя есть три микросервиса в одной репе
они общаются через одного брокера? ты накатывал обновление, и система полетела потому что с другой стороны есть железки, которые используют этот же брокер, но на них обновление не накатили?
всё верно описал?
просто при такой ситуации проблема вовсе не в монорепе
у тебя есть три микросервиса в одной репе
они общаются через одного брокера? ты накатывал обновление, и система полетела потому что с другой стороны есть железки, которые используют этот же брокер, но на них обновление не накатили?
всё верно описал?
просто при такой ситуации проблема вовсе не в монорепе
я похоже понимаю к чему ты пытаешься клонить) На железе ты не можешь обновить софт просто. Потому что он пишется один раз на 100 лет.
GS
это не микросервисы. вы путаете
А что это?
A
микросервисы не могут общаться между собой кроме как по открытому АПИ интерфейсу
да, там есть некоторый флоу. Который реализует rpc в брокерах. И в либе в одной из версий поменялся формат
АП
я похоже понимаю к чему ты пытаешься клонить) На железе ты не можешь обновить софт просто. Потому что он пишется один раз на 100 лет.
ну отлично, значит пакет, который обновляет формат общения, менять нельзя
опять-таки, менять его нельзя для всех микросервисов
разве не проще следить за этим, если есть одно место, через которое можно этот пакет обновить?
опять-таки, менять его нельзя для всех микросервисов
разве не проще следить за этим, если есть одно место, через которое можно этот пакет обновить?
D
А что это?
это монолит, микросервис не должен знать о том как устроен другой микросервис. как я понял у господина они знают друг о друга черзе брокер и лезут в данные друг друга
A
ну отлично, значит пакет, который обновляет формат общения, менять нельзя
опять-таки, менять его нельзя для всех микросервисов
разве не проще следить за этим, если есть одно место, через которое можно этот пакет обновить?
опять-таки, менять его нельзя для всех микросервисов
разве не проще следить за этим, если есть одно место, через которое можно этот пакет обновить?
вот, и потом такой пакет появляется не один, который ты не можешь просто так поменять, и все это превращается в сущий ад.
ки
здраствуйте. советуйте метод для обновление данных в mongodb
GS
это монолит, микросервис не должен знать о том как устроен другой микросервис. как я понял у господина они знают друг о друга черзе брокер и лезут в данные друг друга
Т.е. если в приложении есть множество сервисов, которые общаются через промежуточную среду (брокер, очередь), и для внешнего пользователя также считаются отдельными сервисами, то это монолит?
Wat?
Wat?
CM
здраствуйте. советуйте метод для обновление данных в mongodb
Не совсем понял про что это
A
это монолит, микросервис не должен знать о том как устроен другой микросервис. как я понял у господина они знают друг о друга черзе брокер и лезут в данные друг друга
не, там в другом проблема была. У тебя rpc в одной версии работает в формате
req - topic/id/req
res - topic/id/res
а в другой версии
req - topic/id
res - topic/id/res.
И всё.
req - topic/id/req
res - topic/id/res
а в другой версии
req - topic/id
res - topic/id/res.
И всё.
АП
вот, и потом такой пакет появляется не один, который ты не можешь просто так поменять, и все это превращается в сущий ад.
так погоди
у тебя тут явная ситуация, что ВСЕ микросервисы должны быть завязаны на ГАРАНТИРОВАННО ОДНУ версию пакета
как раз таки монорепозиторий решает эту проблему, а кучка отдельных репозиториев создаёт тот самый адок
у тебя тут явная ситуация, что ВСЕ микросервисы должны быть завязаны на ГАРАНТИРОВАННО ОДНУ версию пакета
как раз таки монорепозиторий решает эту проблему, а кучка отдельных репозиториев создаёт тот самый адок
A
так погоди
у тебя тут явная ситуация, что ВСЕ микросервисы должны быть завязаны на ГАРАНТИРОВАННО ОДНУ версию пакета
как раз таки монорепозиторий решает эту проблему, а кучка отдельных репозиториев создаёт тот самый адок
у тебя тут явная ситуация, что ВСЕ микросервисы должны быть завязаны на ГАРАНТИРОВАННО ОДНУ версию пакета
как раз таки монорепозиторий решает эту проблему, а кучка отдельных репозиториев создаёт тот самый адок
нет. У тебя не должны все микросервисы быть подвязанный на одну версию пакета
D
Т.е. если в приложении есть множество сервисов, которые общаются через промежуточную среду (брокер, очередь), и для внешнего пользователя также считаются отдельными сервисами, то это монолит?
Wat?
Wat?
нет, почему. тут вопрос в данных. если один сервис знает как устроены данные другого, это уже монолит и вообще нарушение границ
я так понял у товарища именно так
я так понял у товарища именно так
АП
нет. У тебя не должны все микросервисы быть подвязанный на одну версию пакета
как это
ты сам описал проблему, которая возникла при частичном обновлении
ты сам описал проблему, которая возникла при частичном обновлении