Комментарии 12
По итогу, складывается ощущение что проблем больше доставил NestJS, а не Kafka.
Там хватает таких мест. В седьмой версии столкнулись в пакете @nestjs/cqrs с тем, что любое исключение в @EventsHandler'е валит процесс.
Не подскажете, в чем преимущество JS на бэке перед давно обосновавшимися там C# и Java?
Скорее всего на JS изначально писали.
По моему мнению, история JS на беке иногда начинается с историй про то, что удобно когда фронт и бек написан на одном языке, и можно на начальных стадиях развития проекта одним разработчиком закрыть сразу много "дыр", а потом уже разделяться на более глубокий бек и фронт.
Могут еще так же затесаться истории про пороги вхождения в язык и т.п.
Kafka для работы в режиме запрос-ответ - не лучший выбор. Хотя бы потому, что в ней нет для подписчиков push. Только poll. Отсюда и вытекает то, что чем больше сообщений за один poll будет обрабатывать подписчик - тем лучше.
gRPC, но в его случае мы столкнулись со сложностями описания Protobuf-схем (они у нас динамические), а ещё были вопросы к масштабированию.
Не понял, что значит динамическая схема. Как можно организовать коммуникацию сервисов без контрактов?
А с масштабированием у gRPC проблем нет. Хотите - через балансировщик, хотите - через тот же Zookeeper.
В общем случае. Kafka - массивы информации между сервисами. RabbitMQ - роутинг сообщений. gRPC - взаимодействие точка-точка.
А в Вашем случае, когда задержки столько важны, я бы посмотрел в сторону Redis
Динамическая схема - возможные поля описаны в БД в отдельной коллекции. В процессе мы дошли до того, что совершенно не страшно и быстро триггерить генерацию типов и схем при изменении бд разными хуками, но на тот момент - было как было.
По поводу масштабируемости gprc - это вопрос момента. Видимо в тот момент у меня было недостаточно экспертизы в этом, были какие то проблемы в TS с ним, да и быстро окинув взглядом статьи разные - увидел много мнений, кто то говорил "сложно масштабировать", кто то говорил "не сложно".
По поводу общего случая - для чего и что подходит - абсолютно согласен
- для "точка точка" - пошли по более простому пути и по хттп стали стучаться от сервиса к сервису.
- по поводу что Кафка изначально и не для этого - это понятно, просто необходимо было для исследования поведений Кафки в таких странных для нее случаях
Динамическая схема - возможные поля описаны в БД в отдельной коллекции.
И что с того? Ну будут все возможные поля в схеме. Protobuf эффективно эту проблему решает.
триггерить генерацию типов и схем при изменении бд
Точно так же можно генерировать схемы при деплое. У нас необходимые схемы автоматически создаются по метаданным БД и обновляются в schema registry при деплое.
для "точка точка" - пошли по более простому пути и по хттп стали стучаться от сервиса к сервису
gRPC из коробки делает это. Причем по HTTP/2, в бинарном сжатом виде, да еще и с поддержкой потоков как от клиента, так и от сервера.
А чем все же Redis не устроил, раз уж так важны низкие задержки? Он существенно обгоняет и Kafka, и RabbitMQ.
По схемам - я абсолютно с тобой согласен, мы так все в итоге настроили для других реализаций, но это другая история. А про данную статью - в моменте разработки - эти идеи почему то не подошли или не пришли в голову.
По поводу Redis - изначально цель была исследовать как из коробки работает NestJs Microservices, где было обещано бесшовное переключение транспорта между сервисами. Так как Кафка была в этой "коробке" - и так как необходимо было чуть поднять экспертизу по ней - выбрана была она, чтоб убить несколько зайцев сразу.
Ну как оказалось - из коробки оно не работает, да и как и предполагалось, к сожалению, не подошло к вопросу ответу
По gRPC - да спасибо, я внимательнее это все изучу - и так как он "в коробке неста" - попробую его затащить в будушем!
Так, если какое-либо событие в одном сервисе триггерит бизнес логику в другом, это уже не микросервисная архитектура, а распределенная. К слову, распределенная система создавала больше проблем, чем монолиты, что и привело к появлению микросервисной архитектуры.
У вас что-то с Zookeeper не так. Все 3 хоста должны быть в одном состоянии если они в одном кластере.
Как мы Kafka с NestJS microservices подружить пытались