Меняем архитектуру проекта на распределённую — с чего начать?
В нашей компании решили перейти на распределённую архитектуру - большая часть вопросов уже решена, и теперь каждый отдельный проект должен продготовиться работать распределённо, на нескольких серверах.
Мне нужно определить где мой проект может столкнуться с проблемами, и если некоторые вещи видно невооруженным глазом (допустим, понятно что если логин прошел через node1 а потом load-balancer прислал запрос того-же юзера на node2 то будет ошибка), то к другим аспектам я даже не знаю как подойти.
Итак, вопрос - Что почитать для более детального понимания последствий такого перехода? Да и вообще, более конкретные детали и примеры имплементации. Пока всё что нашла это топики в стиле "Выбрали Spark\Hadoop\Cassandra, настроили, и всё тип-топ". Я понимаю, что даже тот пример с логином можно решить при грамобной настройке (грубо говоря "Bind user to node after login"), но всё таки хочется посмотреть какие у других были подводные камни, и желательно как с ними справились.
Много чего почитать стоит, например, как это устроено в облаках, пол очереди, CDN... Куча всего есть. Или попросить пообщаться предметно с кем-нибудь тут. Вопросы по архитектуре редко когда в переписке оптимально решаются
Иван Шумов, не ожидала решить этот вопрос полным решением моей проблемы в архитектуре. Читаю всё что могу найти по теме, но всё сходится к простейшим примерам в изолированной среде с чистым проектом. Понимаю, что "за меня" никто не распишет все нужные изменения (специально не стала вдаваться в подробности конкретного проекта), но я просто не вижу как даже начать натягивать огромный, запутанный, многолетний проект на шаблон "распределённой архитектуры".
>Bind user to node after login
что первый вариант что этот - не очень решения при распределенной архитектуре.
====
вам нужно переделать мышление, о том как вообще следует выстраивать работу в распределенных архитектурах.
но ничего страшного, можно начать с курсов на курсере или что-нибудь в таком стиле посмотреть
потом можно говорить о каких-то конкретных подводных камнях.
Курс посмотрю, спасибо.
Проблема в подходе смены мышления в том, что обычно всё объясняется в рамках "лабораторного" мира - проект начинается с нуля, выбираются инструменты, и под них подстраивается то что пишем. Конечно, это тоже полезно, ведь итог должен быть почти одинаковый, но я не могу взять и переписать миллионы строк кода по новым парадигмам - нужны минимальные потери. Именно поэтому я страшиваю про примеры перехода а не выстраивания "с нуля".
Архитектор информационных систем и баз данных. Ful
Данные сессии не на ноде храните, а например в редисе и все теоретически должно взлететь. Треш будет в обновлении нод. Одновременно же должны и старые версии и новые версии работать.
Вот-вот, именно этот трэш я и хочу предусмотреть. Но когда до сих пор это был синглтон, мне вообще не понятно как и откуда его начинать "перетягивать" на новую модель.
Там миллион всяких тонкостей в зависимости от точки изменений. Я думаю для начала надо чтобы ноды заработали параллельно, а потом модель обновления под каждое изменение.
Средний
Средний
