@thethanosdaddy

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

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

За основу я взял микросервисную архитектуру. При этом клиенты только отправляют данные и не ожидают никакого ответа. Аналогично и промежуточные сервисы. Масштабирование в моей схеме предполагается за счет повышения производиельности наиболее нагруженных микросервисов (с изменением их "веса" у балансировщика), либо за счет увеличения их количества. Web-сервер в конце схемы это просто пример конечного пользователя. Там может быть что угодно. 608fb06db46cc164879578.png
  • Вопрос задан
  • 141 просмотр
Пригласить эксперта
Ответы на вопрос 4
firedragon
@firedragon
Senior .NET developer
Лично я не понимаю что делают клиенты. Скрапят веб и отдают данные на сервер? Или просто принимают данные, а сервер агрегирует и потом отдаёт другим клиентам?
Ответ написан
uvelichitel
@uvelichitel
habrahabr.ru/users/uvelichitel
database сервисов полнотекстового поиска это - реплики? Они полностью синхронны, или предполагается механизм партиционирования/шардинга? Этот database вообще можно рассматривать отдельным сервисом (отдельным от сервисов полнотекстового поиска). Благо движков DB имеющих свои механизмы масштабирования достаточно в природе.
Ответ написан
Griboks
@Griboks
Могу заметить, что вы забыли балансировщик перед веб-сервером.
Ну и получается, что самое узкое место - это как раз и есть балансировщик. Если это тупо одна машина, то сервис 100% упадёт.
Ответ написан
2ord
@2ord
продвинутый чайник
Моя схема:

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы