Вторая проблема — это редкие, но внезапные потери сообщений из Redis. Опыт эксплуатации показал, что Redis растеряйка тот еще: его pub-sub механизм не самый надежный, так как клиент, подписываясь на каналы в Redis’е и получая из них сообщения, не отсылает назад никаких подтверждений, а Redis их не повторяет, что порой приводит к потерям.
тут ничего внезапного нет, redis pub-sub всегда был at-most-once системой :) для гарантий at-least-once в редисе есть стримы, на которых тоже можно организовать pub-sub взаимодействие.
в микросервисах передаются недокументированные куски JSON через недокументированное API
так документируйте, OpenAPI и прочее для этого и придумывали. как будто в монолите нельзя недокументированные интерфейсы написать :)
Хуже того, микросервисы позволяют писать код на разных языках и фреймворках
и это прекрасно, потому что позволяет подбирать инструменты под задачу, а не использовать один инструмент для всего. конечно, ситуация когда проект написан на десяти языках — однозначно плохо, но никто не заставляет этого делать и разумные люди будут этого избегать. вы же пишете так, как будто без этого не обойтись, налицо манипуляция фактами
и представьте, сколько времени у вас уйдет на починку бага, если надо изучить каждый язык и фреймворк, и разобраться в каждом из микросервисов
так а что, в монолите разбираться не надо, если не знаком с кодовой базой? вообще странный аргумент, потому что если ты участвовал в разработке проекта, то много чего «изучать» не надо будет, а если не участвовал — так и так разбираться (и чем больше проект — тем дольше разбираться, независимо от его структуры).
Простая задача, в монолите решаемая за несколько часов, займет несколько дней, а то и недель
какие-то цифры с потолка, непонятно откуда взятые
Отдельная проблема — общий код. Что, если сервису A и B нужно использовать общий код?
монорепозиторий
Таким образом, с помощью Монолита можно добиться той же производительности и масштабируемости, только без головной боли и присущих микросервисам недостатков
да вот только головная боль будет. большой проект сложно поддерживать, особенно при разрастании команды. большой проект сложнее контролировать на пример дедлоков и stateful-вещей, мешающих масштабированию.
помимо уменьшения связанности кода, у микросервисов есть еще одно, может быть даже более важное, преимущество — независимые деплои. какой бы чистый код разработчик не писал, с разрастанием кодовой базы сложнее следить за зависимостями, в конечном счете любой код может зависеть от любого (разработчики тоже люди и тоже могут писать неидеальный код, да-да), поэтому и требования к тестированию релизов соответствующие. это уже не говоря о том что код внутри монолита могут писать разные команды с разными потребностями и разным релизным циклом. микросервисы уменьшают эту проблему и, как следствие, time to market
Хочется масштабирования — запускаем несколько копий Монолита на нескольких серверах
все равно нет возможности масштабировать отдельные части системы. если есть модуль, который отжирает CPU — он и будет отжирать процессорное время от остальных задач.
Если разработчики не способны написать чистый код в Монолите, они и микросервисы такие же нечитаемые напишут
ничего не мешает писать чистый код и в монолитном подходе, это правда, но опять-таки при увеличении размера проекта так или иначе происходят нехорошие вещи — текут абстракции, тесты начинают гоняться по полгода, выявляются неприятные зависимости одного кода от другого. контролировать сложность, когда у тебя есть много слабосвязанных сервисов — проще, потому что, как ни крути, сетевой интерфейс обязывает писать low coupled код
самое смешное, что микросервисы — не серебряная пуля, это правда. писать их без соответствующей инфраструктуры, CI/CD и прочего ведет к боли и проблемам. на маленьких проектах в них действительно может не быть смысла (особенно если приложение состоит из CRUD'ов), но они были придуманы не глупыми людьми и не просто так
тут ничего внезапного нет, redis pub-sub всегда был at-most-once системой :) для гарантий at-least-once в редисе есть стримы, на которых тоже можно организовать pub-sub взаимодействие.
так документируйте, OpenAPI и прочее для этого и придумывали. как будто в монолите нельзя недокументированные интерфейсы написать :)
и это прекрасно, потому что позволяет подбирать инструменты под задачу, а не использовать один инструмент для всего. конечно, ситуация когда проект написан на десяти языках — однозначно плохо, но никто не заставляет этого делать и разумные люди будут этого избегать. вы же пишете так, как будто без этого не обойтись, налицо манипуляция фактами
так а что, в монолите разбираться не надо, если не знаком с кодовой базой? вообще странный аргумент, потому что если ты участвовал в разработке проекта, то много чего «изучать» не надо будет, а если не участвовал — так и так разбираться (и чем больше проект — тем дольше разбираться, независимо от его структуры).
какие-то цифры с потолка, непонятно откуда взятые
монорепозиторий
да вот только головная боль будет. большой проект сложно поддерживать, особенно при разрастании команды. большой проект сложнее контролировать на пример дедлоков и stateful-вещей, мешающих масштабированию.
помимо уменьшения связанности кода, у микросервисов есть еще одно, может быть даже более важное, преимущество — независимые деплои. какой бы чистый код разработчик не писал, с разрастанием кодовой базы сложнее следить за зависимостями, в конечном счете любой код может зависеть от любого (разработчики тоже люди и тоже могут писать неидеальный код, да-да), поэтому и требования к тестированию релизов соответствующие. это уже не говоря о том что код внутри монолита могут писать разные команды с разными потребностями и разным релизным циклом. микросервисы уменьшают эту проблему и, как следствие, time to market
все равно нет возможности масштабировать отдельные части системы. если есть модуль, который отжирает CPU — он и будет отжирать процессорное время от остальных задач.
ничего не мешает писать чистый код и в монолитном подходе, это правда, но опять-таки при увеличении размера проекта так или иначе происходят нехорошие вещи — текут абстракции, тесты начинают гоняться по полгода, выявляются неприятные зависимости одного кода от другого. контролировать сложность, когда у тебя есть много слабосвязанных сервисов — проще, потому что, как ни крути, сетевой интерфейс обязывает писать low coupled код
самое смешное, что микросервисы — не серебряная пуля, это правда. писать их без соответствующей инфраструктуры, CI/CD и прочего ведет к боли и проблемам. на маленьких проектах в них действительно может не быть смысла (особенно если приложение состоит из CRUD'ов), но они были придуманы не глупыми людьми и не просто так