Архитектура сервиса для сбора и обработки текстовых данных. Нужна здоровая критика. /?

Question

[thethanosdaddy]

Задача:
Спроектировать следующий сервис по описанию. Есть N рабочих мест пользователей, на которых установлены агрегаторы текстовых данных. Данные поступают на сервера и проходят обработку на извлечение текста для дальнейшего полнотекстового поиска. Сервис должен масштабироваться.

За основу я взял микросервисную архитектуру. При этом клиенты только отправляют данные и не ожидают никакого ответа. Аналогично и промежуточные сервисы. Масштабирование в моей схеме предполагается за счет повышения производиельности наиболее нагруженных микросервисов (с изменением их "веса" у балансировщика), либо за счет увеличения их количества. Web-сервер в конце схемы это просто пример конечного пользователя. Там может быть что угодно.

Answer 1

[Владимир Коротенко]

Лично я не понимаю что делают клиенты. Скрапят веб и отдают данные на сервер? Или просто принимают данные, а сервер агрегирует и потом отдаёт другим клиентам?

Comments

[thethanosdaddy]

Клиенты собирают текстовые данные с самого ПК, что печатал, что читал (детали реализации здесь не важны). Затем отправляют данные на сервер, который делает свою часть работы и передает дальше. Конечный пользователь это система, которая отслеживает и предотвращает утечку информации. Но моя задача здесь только работа конкретно с текстом.

[Владимир Коротенко]

thethanosdaddy, ок ищите по dlp системам. Касперский и инфоватч хорошо так описывали. Нгинкс в общем то не так и нужен пишите свой сервер что бы клиенты пушили данные в него. Возможно что и по udp. Fts движков целая куча, только обращаю внимание это не особо нужно. Длп система принимает порцию данных от клиента , и в реалтайме выставляет оценку ну и отправляет оповещение если баллы выше критических

Answer 2

[uvelichitel]

database сервисов полнотекстового поиска это - реплики? Они полностью синхронны, или предполагается механизм партиционирования/шардинга? Этот database вообще можно рассматривать отдельным сервисом (отдельным от сервисов полнотекстового поиска). Благо движков DB имеющих свои механизмы масштабирования достаточно в природе.

Comments

[thethanosdaddy]

Эти БД полностью независимы друг от друга, так как нужны они только для самого поиска и временного хранения данных. В моей голове они не должны вообще знать ни друг о друге, ни о том, что хранится в другой БД, ни даже о том, откуда данные поступают.

Answer 3

[Griboks]

Могу заметить, что вы забыли балансировщик перед веб-сервером.
Ну и получается, что самое узкое место - это как раз и есть балансировщик. Если это тупо одна машина, то сервис 100% упадёт.

Comments

[thethanosdaddy]

А что балансировать переде Web-сервером, если он один (на схеме)? А если web-серверов будет несколько, то должно хватить обычного dns.

[Griboks]

thethanosdaddy,

Сервис должен масштабироваться.

Вам придётся рисовать аж целых 2 новых стрелочки для добавления всего 1 нового сервера, т.е. сложность растёт как n*m вместо n+m.

Answer 4

[Everything_is_not_so_bad]

Моя схема:

Запись данных: Клиенты --> LB --> API --> MQ брокер --> обработчики очереди --> СУБД
То есть API получает данные от клиента, отправляет MQ брокеру (RabbitMQ/Apache Kafka) и сразу отвечает со статусом 200/202.
API и обработчики очереди масштабировать по необходимости. Запись в материализованном представлении данных. СУБД с репликацией master-slave.

Чтение данных: LB --> API --> кэш/СУБД
Здесь можно взять даже какой-нибудь фреймворк типа RoR/Django.

Comments

[thethanosdaddy]

"Моя схема" это та, которую вы используете или то, как вы бы сделали мою задачу?

[Everything_is_not_so_bad]

thethanosdaddy, это предложение моего видения архитектуры.

[Everything_is_not_so_bad]

И уточнение под чтением данных (Б): когда в любой момент времени пользователи заходят в панель админки (или что там у вас будет) через API и видят там результаты агрегации данных. Но необязательно только чтение. Просто по этому пути не должно быть сбора данных от агентов, с которых идет сбор текстовых данных.
И даже это API не обязан быть на том же стеке технологий, как API при сбора данных в режиме записи (А).

[thethanosdaddy]

Роман Мирр, а каким образом LB сочетается с MQ брокер?