есть эспериментальный проект
он очень модульный
в текущем ввиде это он запускается как один процесс
но в будущем обязателньо потребуется для надежности чтобы модули находились в отделных процессах
на данном этапе если этим заморачиваться то это сильно все усложнит потому что арзитектура и клучевые аспекты часто мутируют
как можно было бы на этапе проектирования однопроцессной версии учесть хотя бы частично будущее разделение на отдельные процессы?
как организовать архитекрутру так, чтобы потом минимизировать изменения связанные с тем что сотни связей должны быть сериализованы?
Я изъездил эту страну вдоль и поперек, общался с умнейшими людьми и я могу вам ручаться в том, что обработка данных является лишь причудой, мода на которую продержится не более года. (с) Эксперт, авторитет и профессионал из 1957 г.
Здравствуйте, Kingofastellarwar, Вы писали:
K>есть эспериментальный проект K>он очень модульный K>в текущем ввиде это он запускается как один процесс K>но в будущем обязателньо потребуется для надежности чтобы модули находились в отделных процессах K>на данном этапе если этим заморачиваться то это сильно все усложнит потому что арзитектура и клучевые аспекты часто мутируют K>как можно было бы на этапе проектирования однопроцессной версии учесть хотя бы частично будущее разделение на отдельные процессы? K>как организовать архитекрутру так, чтобы потом минимизировать изменения связанные с тем что сотни связей должны быть сериализованы?
А делает то он что?
В качестве вариантов сходу:
1) шардинг с перебалансировкой
2) стэйтлес сервер. Полезная активность в таком случае изолированна, так что можно балансировать с клиента(либо отдельного прокси-балансера с которым общается клиент?). Сервер(он же сервер?) в таком случае просто выполняет некие действия на пришедших к нему данных.
Здравствуйте, Kingofastellarwar, Вы писали:
K>он очень модульный K>как организовать архитекрутру так, чтобы потом минимизировать изменения связанные с тем что сотни связей должны быть сериализованы?
Для этого модули должны взаимодействовать друг с другом через обмен сообщениями. Через шину или напрямую. Посмотреть можно на Akka и ZeroMQ
Здравствуйте, Kingofastellarwar, Вы писали:
K>как организовать архитекрутру так, чтобы потом минимизировать изменения связанные с тем что сотни связей должны быть сериализованы?
этапы:
1) зафиксировать интерфейсы модулей, работу с модулями вести только через интерфейсы
2) сделать вызовы интерфейсов асинхронными на основе очереди ( каждый модуль получит свою очередь "сообщений" )
3) сделать вместо нескольких очередей для модулей одну общую, добавить в сообщения информацию о модуле-отправителе и модуле-назначении для диспетчеризации
4) вынести очередь в отдельный процесс, реализовать протоколы работы с очередью
обычно имеет смысл отложить пункты 2,3,4 до непосредствнно вынесения модулей в процессы, для очередей лучше брать готовые решения, например redis
Здравствуйте, Kingofastellarwar, Вы писали:
K>как организовать архитекрутру так, чтобы потом минимизировать изменения связанные с тем что сотни связей должны быть сериализованы?
Ключевое слово "потом".
Решать проблемы которых сейчас нет — прямой путь создать эти проблемы.
Лучше всего не делай ничего. Когда понадобится что-то разносить по разным процессам у тебя появится точное понимание как должно выглядеть решение и ты быстро его реализуешь.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Kingofastellarwar, Вы писали:
K>>как организовать архитекрутру так, чтобы потом минимизировать изменения связанные с тем что сотни связей должны быть сериализованы?
G>Ключевое слово "потом". G>Решать проблемы которых сейчас нет — прямой путь создать эти проблемы. G>Лучше всего не делай ничего. Когда понадобится что-то разносить по разным процессам у тебя появится точное понимание как должно выглядеть решение и ты быстро его реализуешь.
Позволю себе не согласиться.
Впрочем, как generic rule of thumb "потом" — сойдёт, но
Непредусмотренные возможности по кластеризации и шардингу позже обойдутся дороже.
Т.е. если достоверно известно что ожидается нагружка, придётся делать кластер, шардировать, партиционировать и т.д., дешевле будет если е вложиться сразу.
Вклад может быть разным, к примеру:
— даже на одном БД сервере можно развести данные по разным схемам и не использовать FK между разными схемами (впоследствие каждая схема уходит на свой сервер)
— избегать JOIN между таблицами разных схем
— не ложить логику в БД
— делать stateless сервисы
— связь между сервисами — только через высокоуровневый интерфейс (предполагая что это в будущем трансформируется во внешние вызовы того же REST или что выберете)
Здравствуйте, velkin, Вы писали:
V>Здравствуйте, Kingofastellarwar, Вы писали:
K>>как организовать архитектуру
V>Архитектура корпоративных программных приложений. Мартин Фаулер
по распределёнке там ничего интересного нету
если что рекомендовать на тему то уж по микросервисам, там вопросы сетевого разделения рассматриваются подробно
