Как лучше сделать архитектуру сервиса с Cassandra?

Question

[vanchenkin]

Привет!

Сейчас архитектура такая: есть два микросервиса: первый собирает данные от клиента через вебсокет, передает второму по http, второй сохраняет эти данные в Cassandra.
Развернуто много инстансов и первого и второго микросервисов. Развернуто много нод кассандры, фактор репликации - 2.
Объем данных - терабайт в день. 90 МБ/с траффика в пике.
Скорость ответа сервисов и мгновенная запись не важна, важно записать данные.

Такая архитектура выглядит плохо:
- если упадет второй микросервис, то данные перестанут писаться
- если нагрузка станет слишком высокой, то микросервисы могут каскадно лечь
- сетевые ошибки при HTTP
- двойное потребление ресурсов из-за HTTP

В связи с этим появилось два варианта улучшения:
- смержить эти два микросервиса в один
- поставить между этими микросервисами надежную Kafka

Cassandra вроде как надежная, но тогда мы уходим от микросервисной архитектуры в сторону монолита, сервисы начинают выполнять несколько задач, что плохо.

С Kafka мы защитимся от пиков нагрузки, но появляется еще один сервис для мониторинга, еще одна связь в цепочке, места для возникновения ошибок. Но мы защитимся от падения Cassadra.

Постарался описать все ограничения, но если что - спрашивайте в комментариях, задачка интересная.

Какой вариант лучше выбрать? Или может есть другие варианты?

Answer 1

[mayton2019]

Объем данных - терабайт в день. 90 МБ/с траффика в пике.
Скорость ответа сервисов и мгновенная запись не важна, важно записать данные.

Между первым и вторым сервисом можно поставить Kafka. Это позволит смягчить ситуацию частичной
недоступности пишущего сервиса. Я здесь далее по топику предполагаю что Kafka и Cassandra - это облачные
решения которые в приципе не падают. А если и падают то очень редко и по крайне жестким авариям датацентров.

В этом случае в качестве точек сбоя можно просто рассматривать два ваших микросервиса.

Еще вариант. Вообще убрать пишущий микро-сервис. Я не знаю как в кассандре. Но в bigdata есть огромное
число т.н. коннекторов. Это что-то типа драйвера который позволяет писать стриминг в базы и наоборот.
Например есть коннектор который пишет сразу из Kafka в таблицы Databricks. Скорее всего для кассандры
тоже есть нечто подобное. Мне кажется с коннектором архитектурно получается проще.

Comments

[vanchenkin]

Спасибо за ответ! Какие минусы если убрать пишущий микро-сервис и записывать сразу в Cassandra?

[mayton2019]

vanchenkin, ну там может быть ваша бизнес логика. Тоесть мы ее просто убираем. Это - минус?

Вот посмотрите тут коннектор. https://docs.confluent.io/kafka-connectors/cassand...
Может вам и не хватит его возможностей.