Прежде всего, то, что вы упомянули, явно выполнимо.Вы можете запустить KSQL Server с Docker , так что у вас может быть оркестратор контейнеров, такой как kubernetes или swarm, поддерживающий и планирующий эти экземпляры KSQL Server.
Итак, вы знаете, как это будет работать:
- Каждый экземпляр KSQL присоединится к группе других экземпляров KSQL с таким же
KSQL_SERVICE_ID, которые используют тот же кластер Kafka, определенный KSQL_KSQL_STREAMS_BOOTSTRAP_SERVERS - . Вы можете создать несколько кластеров KSQL Server.т.е. для разных приложений, просто используйте разные
KSQL_SERVICE_ID при использовании одного и того же кластера Kafka.
В результате у вас теперь есть:
- Несколько контейнерных экземпляров KSQL-сервера, управляемых контейнерным оркестратором, таким как Kubernetes.
- ВсеЭкземпляры KSQL подключены к одному и тому же кластеру Kafka (у вас также могут быть разные кластеры Kafka для разных
KSQL_SERVICE_ID) - Экземпляры сервера KSQL могут быть сгруппированы в разные приложения (разные
KSQL_SERVICE_ID) для достижения разделенияпроблем, связанных с тем, что масштабируемость, безопасность и доступность могут быть лучше поддержаны.
Что касается сосуществования нескольких экземпляров сервера KSQL (возможно, с разными KSQL_SERVICE_ID) на одном сервере, вы должны знать доступную машинуресурсы могут быть монополизированы жадным экземпляром, вызывая проблемы для менее жадного экземпляра.С Kubernetes вы можете установить ограничения ресурсов для ваших модулей, чтобы избежать этого, но жадные экземпляры будут ограничены и замедлены.
Совокупный совет относительно мультитенантности :
Мы не рекомендуем использовать KSQL мультитенантно.Например, если у вас на одном узле работают два приложения KSQL, и одно из них является жадным, вы, скорее всего, столкнетесь с проблемами с ресурсами, связанными с многопользовательским режимом.Мы рекомендуем использовать один пул экземпляров KSQL Server для каждого варианта использования.Вы должны развертывать отдельные приложения на отдельных узлах KSQL, потому что становится легче рассуждать о масштабировании и использовании ресурсов.Кроме того, развертывание для каждого варианта использования упрощает анализ отказоустойчивости и репликации.
Возможный недостаток - это накладные расходы, которые вы будете иметь, если будете запускать несколько экземпляров сервера KSQL (площадь приложения Java) в одном и том жепул, в то время как у них нет работы (то есть: нет планируемых задач из-за отсутствия разделов в ваших темах) или просто потому, что у вас очень маленькая рабочая нагрузка.Вы можете выполнять ту же работу с меньшим количеством экземпляров, избегая бездействующих или почти бездействующих экземпляров.
Конечно, вставка всей потоковой обработки, возможно, для совершенно разных вариантов использования или проектов, на одном KSQL-сервере или пуле KSQL-серверов может привести к собственным проблемам внутреннего параллелизма, сложностям цикла разработки, управлению и т. Д.
Думаю, что-то посередине будет работать нормально.Используйте пул экземпляров KSQL Server для одного проекта или варианта использования, который, в свою очередь, может преобразоваться в конвейер, состоящий из топологии из нескольких источников, процессов и приемников, реализованный с помощью ряда запросов KSQL.
ТакжеНе забывайте о механизмах масштабирования Kafka, Kafka Streams и KSQL (построенных поверх Kafka Streams), которые обсуждались в предыдущем опубликованном вами вопросе .
Все эти механизмыможно найти здесь:
https://docs.confluent.io/current/ksql/docs/capacity-planning.html https://docs.confluent.io/current/ksql/docs/concepts/ksql-architecture.html https://docs.confluent.io/current/ksql/docs/installation/install-ksql-with-docker.html