Комментарии 3
Событийно-ориентированная архитектура (event-driven architecture, EDA) под новым соусом названием
Текста написано много, но он будто обо всем и ни о чем. Сразу к примеру перейдем. Итак, в примере операция, которая будто и не требует декомпозиции, декомпозирована на три составляющие. Это, вроде как, должно помочь нам избавиться от узкого горлышка, как пишут в преимуществах.
Давайте подумаем, что произойдет. Первая часть системы быстро (относительно) прочитает все файлы и забьет очередь картинками, которые будут без дела пылиться в оперативной памяти компьютера и ждать своей очереди. Затем по одному их прочитает обработчик, и, сразу по завершении обработки, сейвер их сохранит. Это в общем-то частая проблема, когда приходится обрабатывать видеопоток или что-то подобное, обработка как правило занимает времени больше, чем чтение, поэтому обработать поток видео покадрово - тяжелая для вычислительной машины задача, добавляют балансировщики, которые подают на обработку только ценные кадры. То есть, не очень понятно, а зачем читать условные 100 картинок сразу в оперативную память, если можно их читать по одной?
Возможно, подразумевается, что данный паттерн будет реализован в рамках серверного приложения. То есть, 100 пользователей загрузили свои 100 картинок, и сотый идет в курилку, на обед, играет в теннис, подтягивается на турнике, пока его картинка дождется своей очереди? Понятное дело, что если там нейросети, то без очереди не обойтись. Но если нет инференса тяжелой модели, а просто алгоритмическая часть, как в примере, то почему бы эти сто операций обработки не распараллелить хотя бы на, скажем, три-четыре потока?
Итак, написав прошлые три абзаца, я пришел вот к чему. Нам нужно разделить операцию загрузки картинок (или любых других данных) в ОЗУ (или сначала в какое-нибудь хранилище, а при надобности - из него в ОЗУ) от операции обработки этих картинок (данных), а по завершении обработки пользователю показывался либо результат, либо какое-то сообщение, что все, мол, ок. Причем, это решение должно масштабироваться, а отдельные компоненты должны не зависеть друг от друга, не считая интерфейса взаимодействия между этими компонентами.
Разве это не микросервисы? Окей, тут важен порядок, в отличие от event-driven (если я правильно понял текст из википедии), но что это в корне меняет? Либо в статье что-то не так изложено, либо тут действительно чего-то принципиально нового и не написано...
Паттерн Space-Based для масштабируемых систем