Я смотрю на эту диаграмму архитектуры KNative Eventing
И обратите внимание, что цвет стрелок, который входит в пользовательский Службы синего цвета, то есть Службы могут вызываться только по протоколу HTTP.
Протокол HTTP является синхронным и также ориентирован на запрос / ответ.
Это противоречит природе событий, где вместо этого мы должны стремиться к проектированию систем, ориентированных на подписку / уведомление и асинхронных.
Источник служебных сообщений на диаграмме - Кафка. Это брокер сообщений, основной целью которого является поддержка асинхронной доставки сообщений и случаев подписки / уведомления.
Почему бы KNative Eventing изменить этот исходный транспортный характер канала с асинхронной подписки / уведомления на синхронный запрос / ответ, вызывающий службы.
Правда ли, что Сервисы могут вызываться только через HTTP в KNative Eventing (без специальной работы по разработке собственных колясок и оболочек сервисов)? Это выглядит значительным ограничением.
Если да, то почему? Это сделано намеренно, или это временное решение. Почему Сервис не может напрямую использовать канал (например, при поддержке Kafka) и почему «подписчик канала» не может быть встроен в оболочку для изображений Service Docker или в коляску.