SP
Короч, делай чё хочешь)
Size: a a a
2020 October 24
NF
SP
Я не понимаю как увеличение нагрузки на хранилище коррелирует с утверждением что "это ок сервисам шарить хранилище". Для менг это просто бессмысленно. Либо ты тему незаметно сменил
NF
Я не понимаю как увеличение нагрузки на хранилище коррелирует с утверждением что "это ок сервисам шарить хранилище". Для менг это просто бессмысленно. Либо ты тему незаметно сменил
я про вариант когда хранилище справляется с увеличением нагрузки, а монолит нет и мы отделяем от него кусок чтобы это исправить
NF
а не про вариант когда у нас хранилище не справляется и мы такие "ну щас на микросервисы перейдем и хранилише справится"
k
я про вариант когда хранилище справляется с увеличением нагрузки, а монолит нет и мы отделяем от него кусок чтобы это исправить
так это шаринг в чисто физическом смысле
SP
Да, изоляция нужна только на логическом уровне, а разделять базы физически(отдельные инстансы) это уже от нагрузок
SP
Но поскольку был пример "один читает другой пишет" то и логического разделения нет
SP
И поскольку оба завязаны на одни и те же данные смысла разделять эти сервисы нет
SP
Изменения в одном могут вызвать изменения в другом, надо будет их деплоить одновременно и мы теряем вообще любой потенциальный Профит от микросервисов
SP
А расходы остаются
NF
мб мб, звучит конечно убедительно
NF
Да, изоляция нужна только на логическом уровне, а разделять базы физически(отдельные инстансы) это уже от нагрузок
для меня просто привычна скорее ситуация когда модули в монолите взаимодействуют с отдельными и чаще всего разными частями бд, которые почти не пересекаются(разве что связанным с auth) т.е. логически они скорее разделены чем нет, а то что ro и wo в разные сервисы смысла разделять в этом смысле правда нет, это в принципе понятно
˸A
С этими всеми синхронизациями тоже легко "выстрелить в ногу"
Сегодня бизнес говорит: нам окей, если данные будут синкаться не моментально. А завтра бизнес к тебе приходит с просьбой запилить кнопочку "форсировать синк", ибо у них проблемы, что товар уже можно заказать на сайте, а система Х про эти товары ещё не знает - и из-за этого проблемы в работе с такими заказами...
Сегодня бизнес говорит: нам окей, если данные будут синкаться не моментально. А завтра бизнес к тебе приходит с просьбой запилить кнопочку "форсировать синк", ибо у них проблемы, что товар уже можно заказать на сайте, а система Х про эти товары ещё не знает - и из-за этого проблемы в работе с такими заказами...
DE
С этими всеми синхронизациями тоже легко "выстрелить в ногу"
Сегодня бизнес говорит: нам окей, если данные будут синкаться не моментально. А завтра бизнес к тебе приходит с просьбой запилить кнопочку "форсировать синк", ибо у них проблемы, что товар уже можно заказать на сайте, а система Х про эти товары ещё не знает - и из-за этого проблемы в работе с такими заказами...
Сегодня бизнес говорит: нам окей, если данные будут синкаться не моментально. А завтра бизнес к тебе приходит с просьбой запилить кнопочку "форсировать синк", ибо у них проблемы, что товар уже можно заказать на сайте, а система Х про эти товары ещё не знает - и из-за этого проблемы в работе с такими заказами...
То есть просит с 0,5 сек сократить до 0.1 ?
˸A
То есть просит с 0,5 сек сократить до 0.1 ?
Проблема с продакт-овнером: просит не сократить, а просит "добавить кнопочку" для мануального форса (там не о секундах речь, конечно же)
DE
Проблема с продакт-овнером: просит не сократить, а просит "добавить кнопочку" для мануального форса (там не о секундах речь, конечно же)
Добавьте кнопочку с // do nothing
˸A
Добавьте кнопочку с // do nothing
Не пройдёт QA
DE
Через CSS анимашку ей на ~5 сек сделайте