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

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

BE>Это как раз не проблема. Указывать для какого юзера настройки необходимо все равно.
BE>Гораздо серьезнее проблема что другие инстансы не сразу подхватывают изменение настроек сделанное на другом инстансе. А так как балансировщик обычно раскидывают клиентские подключения по случайным серверам начинаются проблемы пока кеш не обновится.

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

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

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

BE>Это как раз не проблема. Указывать для какого юзера настройки необходимо все равно.
BE>Гораздо серьезнее проблема что другие инстансы не сразу подхватывают изменение настроек сделанное на другом инстансе. А так как балансировщик обычно раскидывают клиентские подключения по случайным серверам начинаются проблемы пока кеш не обновится.

Ну да, у монолита обычно локальный кэш, так надо распределенный кэш прикручивать, hazelcast или gridgain из коробки такое умеют. А это тоже шаг в сторону микросервисов. Правда у распределенного кэша всё равно остается задержка или рассогласование, но это уже неизбежное следствие любой распределённой системы, по теореме CAP — "выбирайте два из трёх".