Здравствуйте, vsb, Вы писали:

G>>Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.

vsb>Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.

vsb>Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.

Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам. И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.

Здравствуйте, vsb, Вы писали:

G>>Если ты про горизонтальное масштабирование монолита, то да, но все равно придется реализовывать распределенные функции (иначе монолиты начнут перезатирать бд друг у друга и прочие косяки, связанные с неумением в распределнное взаимодействие), и тогда сама "монолитность" становится избыточным свойством такой системы, и переход на микросервисы становится неизбежным.

vsb>Просто запускаешь монолит на N-серверах и роутишь запросы к нему. Про перезатирать бд друг у друга — я не понял. БД одна обычно и для БД разницы нет, идут к ней 10 коннектов от одного сервера или от 10 разных. Единственное, про что нужно думать, это про распределённый кеш, но решений для этого хватает и ничего изобретать не нужно. Почему переход на микросервисы становится неизбежным — я не понимаю.

vsb>Если упрёшься в БД, то масштабирование БД это отдельная тема, опять же никак не зависящая от монолитов или микросервисов.

Под перезатиранием БД я имею ввиду, что монолиты часто проектируются так, как будто бы у 1 экземпляра монолита 1 БД в эксклюзивном доступе, без оглядки на то, что одой БД могут пользоваться несколько копий монолита. Например, какие-нибудь таблицы с информацией о настройках — юзер меняет через UI глобальные настройку, и все монолиты подцепят эту настройку, чего бы не хотелось. Или таблицы с текущей информацией по каким-то идущим процессам. И получается, что дял того, чтобы несколько монолитов работали с одной БД и не мешали друг другу, не перезатирали части данных или не подцепляли данные от другой копии, нужно проектировать монолит так чтобы он работал распределенно, а это уже первый шаг к микросервисам.