Мне нужно разработать и внедрить платформу доставки услуг. У меня есть различные услуги в моем текущем проекте, и все эти инструменты используют разные технологии. Некоторые из них - это параллельные функции, упрощающие отображение на основе erlang, а некоторые - простые сценарии bash для объединения некоторых текстовых файлов.Каков наилучший способ общения приложений в архитектуре микрообслуживания
Я слышал о XML/RPC, Protocol Buffer, сообщение-пакет, суп и AMQP. в настоящее время я использую JSON, но загрузка и демпинг больших файлов json - это немного времени/памяти. Есть ли какой-либо новый или надежный способ сделать мост между различными технологиями в инфраструктуре HTTP с широким диапазоном поддержки языка программирования и хорошей документацией?
EDIT1: Мне также нужно упомянуть, что я считаю, что сложность намного более агрессивна, чем проблемы с задержкой или другие связанные с подключением проблемы. Поэтому замена JSON не должна усложнять дизайн.
Спасибо в продвижении.
если ваш файл JSON будет большим, вы гарантированно страдать штраф от HTTP задержки в любом случае. Меняются ли вызовы службы динамически и очень часто? – Anzel
да, например, служба авторизации будет называться 2 миллиона раз в день. и не все json-файлы, но некоторые из них большие. – Farsheed
, если ваш стек связан с инфраструктурой HTTP, я чувствую, что вам лучше пойти с базой данных (NoSQL) в качестве платформы связи, с возможной последовательностью, кешированием и асинхронными вызовами службы, чтобы минимизировать узкое место. Конечно, я не знаю, что именно делают ваши микроуслуги, это просто вариант для вас. – Anzel