клиентских запросов и передачи данных и сервис сбора статистики), с сервиса статистики нужно слать данные на основной сервис. Пока реализовано простейшим способом- отправка сообщений по https с одного сервиса на другой. Является ли такой подход норм решением ? Или стоит сразу смотреть другой принцип общения веб-сервисов - gRpc (правда проекты еще на 2.2 core), или возможно RabbitMQ, или что-то еще ?
Смотря как заморачиваться. Например если сервис-потребитель ляжет, то посыпятся таймауты. И Вам придется где-то хранить сообщения или как-то их самому в очередь сапомисную помещать. Но в случае, если и Ваш сервис уйдет в рестарт - все потеряется. Если эти и подобные заморочки некритичны и можно себе позволить потерю данных или известно, как быстро можно их перезапросить и объем данных небольшой - то можно забить и посмотреть, как оно будет (ленивый вариант). Но я бы сразу закладывал какой-нить механизм очередей. Причем даже если сейчас это не целесообразно, то механизм отправки мессаг можно тоже сделать очередеподобным и спрятать все это за каким-нить интерфейсом. А потом просто сделать имплементацию на настоящих очередях и переключиться. Так или иначе очереди с гарантированной доставкой (если актуально, опять же) все же избавляют от головной боли с ретраями при обрывах связи и так далее.
Обсуждают сегодня