Транспорт для бэкенда на NET Core
Как известно, WCF полноценно не поддерживается в Net Core/Standart, серверной части нет, а при использовании клиентов standart при подключении к сервисам на framework могут возникать различные проблемы, которые приводят к дедлокам и прочим неприятным вещам. ( например, нельзя настроить ConcurrencyMode для CallBackBehavior)
Изучая матчасть, заметил, что везде советуют использовать signalR. Но возникает вопрос, насколько он производителен? TCP он не поддерживает, http априори медленнее, а требования к производительности у нас достаточно высоки.
Какой транспорт вместо WCF сейчас(2020 г.) лучше использовать в рамках Net Core для взаимодействия бэк сервисов с требованием высокой пропускной способности? Или же теперь остается возможность использования только внешних брокеров сообщений?
Ответы (1 шт):
SignalR - это по сути обертка над несколькими протоколами, в приоритете WebSocket, если он не доступен, то Long polling и другие протоколы. Он неплох для Real Time веб приложений. Если требуется обычное синхронное взаимодействие между сервисами, то можно использовать обычный REST, принципе ASP.NET Core сейчас довольно быстр. Если нужно асинхронное взаимодействие, то Kafka, NATS или любой другой стриминг сообщений. Ну а если этого не достаточно (сначала следует дойти до таких нагрузок). То искать что-то специфичное. Для многих задач, например финансовых, есть свои протоколы, которые подходят только для этих задач, но из-за этого они быстрее остальных.