Микросервисы — русскоязычное сообщество

Бывают задачи, которые не стоит делать параллельно. Некоторые виды отчетов, например. Раньше у тебя был сервис таких отчетов со своей очередью на входе, ты в него отправлял задачи и он их обрабатывал тихонько по одному. Ты перешел на монолит и у тебя уже нет этого сервиса, но есть куча монолитов. Как ты поймешь, куда тебя отправлять эти задачи, на какой из экземпляров монолита? Чуть сложнее, когда у тебя есть тяжелые задачи, но ты не можешь их всегда выполнять на том же локальном экземпляре, нужно как-то их балансировать между разными экземплярами. Раньше ты спокойно поднимал новые экземпляры серверов-обработчиков (и это было просто), а вот поднимать новые экземпляры монолита уже сложнее и дороже (и не всегда можно). Не то, что бы это были массовые проблемы, но если просто все слить в один запускаемый файл и поменять все http вызовы на вызовы внутренних методов, то можно получить проблемы.

Не уловил, в чем задача. На другой экземпляр чего? В каких случаях такое может быть?

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

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

Я уверен, что в десятках компаний такие микросервисы есть ) И в большинстве наших бигтехов )

По наклонной пошёл: всё упростил, консолидировал в монолит, убрал скрипты деплоя, удалил кубернетес...

1. Ну, синхронные вызовы не страшно, если нет длинных цепочек. 2. А оно окупится затратами на переделку? 3. Точно ли? Чарты, по идее, можно автоматически сделать. 4. Тут дело не в монолите, надо просто структурное логирование вводить и людей учить. 5. А вот тут модульный вряд ли сильно выиграет, там скорее нужно про модель думать. Но если это java+spring, то вместо микросервисов сделать отдельные jar-ники, которые стартуют в едином пространстве и используют проксю над межсервисными вызовами (которая идет локально при возможности) - не очень сложно и не нарушит общий подход к разработке. Получится, ээ, serverless платформа на спринге )

Где-то тут пример пробегал с микросервисом для получения UUID. С базой данных для хранения выданных, чтобы точно уникальные и всё такое. Такое, конечно, никому не переплюнуть 🤣

По опыту, разработчику гораздо удобнее и проще на любой чих сделать новый микросервис. И куча ранних докладов про микросервисы (с примером микросервисов, которые курсы валют получали) этому способствовали. А более здравый подход стал не маргинальным года два-три назад, разработчики еще не привыкли думать иначе )

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