Почему бы мне не создать веб-сервис на основе ZeroMQ?

Question

В настоящее время мы находимся в процессе разработки веб-службы подписки на общедоступные данные для зарегистрированных клиентских приложений, в настоящее время эти клиенты используют наши API-данные через токены доступа.

Так что для конечной точки подписки на данные мы думали о разныхподходы, наш текущий подход основан на простых сообщениях HTTP каждые пару секунд клиентам, подписавшимся на конкретное изменение в данном объекте (только когда изменения происходят явно).

EX: Пользователь создает новый документ, все приложения, подписанные на эту конкретную пользовательскую подписку (UserUploadDoc), будут уведомлены через POST.Это действительно просто реализовать.

Но затем мы начали исследовать службы обмена сообщениями, и ZeroMQ, похоже, вполне способен.

Я легко могу представить себе простую службу сообщений, работающую аналогично больничной аптеке, где мы просто что-то транслируем, и кто-то, кто ее слушает, получает это,

Как у медсестры Салли есть звонок наПитомник, и, конечно, сестра Салли может прийти в Питомник, и только она получит полное сообщение.

Пожалуйста, подтвердите, что я совершенно не прав в этом подходе, и, вероятно, следует придерживаться болезненных сообщений HTTP!

Answer 1

Очередь сообщений - отличная идея для этого сценария, так как она добавляет гарантированную доставку, а также контрольный журнал в случае проблем. Например, у вас есть возможность узнать, был ли недоступен конкретный клиент, чтобы получать сообщения в определенное время, или перемотать очередь сообщений и воспроизвести ее для проверки клиентов. Как отмечают другие посты, это добавляет дополнительные накладные расходы, поэтому на самом деле все сводится к анализу затрат и выгод того, стоит ли этот компромисс в вашем конкретном случае.

Как правило, я бы сказал, что если неудача в получении сообщения по какой-либо причине вызовет серьезные проблемы (в больнице, я подозреваю, что это произойдет), то у вас должен быть брокер сообщений. Если бы вы не использовали push-протокол через POST, то, вероятно, клиент должен продолжать опрашивать REST-интерфейс сервера до тех пор, пока он не получит обновление, так что это не будет иметь значения, поскольку пользователь увидит сообщение «невозможно обновить» и сможет предпринять действия , Пока вы счастливы, что ZeroMQ будет достаточно легким / дешевым в обслуживании, я бы сказал, сделайте это.

Answer 2

Я не думаю, что есть правильная или неправильная адаптация ZeroMQ в этом сценарии.Я думаю, что необходимо учитывать следующие факторы:

• Сколько стоит, когда клиенты (все приложения) должны интегрировать интерфейс ZeroMQ в качестве подписчиков вместо более стандартных методов HTTP.
• MQброкеры предлагают временное хранение и управление сообщениями, чтобы обеспечить успешную доставку сообщений между производителями (отправителем) и потребителями (получателями), например постоянный режим.Таким образом, будет больше затрат на пространство, время, управление, но больше надежности.
• Вы все еще можете интегрировать HTTP-интерфейсы с ZeroMQ с дополнительным уровнем прокси для взаимодействия между потребителями ZeroMQ и реальным клиентом.Например, клиент отправляет HTTP-сообщение подписки на потребительский прокси-сервер ZeroMQ, затем потребительский прокси-сервер ZeroMQ «подписывает» производителя ZeroMQ, как только потребительский прокси-сервер ZeroMQ получил широковещательное сообщение, он все равно будет отправлять HTTP-запрос POST фактическому клиенту.В конце концов, он имеет своего рода управление сообщениями, например, модель «издатель-подписчик», и остается простым HTTP-интерфейсом для вещателей и клиентов.

Просто некоторые мысли.

Answer 3

ZeroMQ - отличный выбор для создания сервисов, но вы упоминаете, что система была несколько общедоступной. Это может быть чем-то, что стоит рассмотреть - несмотря на то, что была проделана большая работа по обеспечению устойчивости ZeroMQ к враждебным соединениям, еще предстоит проделать большую работу, чтобы у вас был слой поверх него, чтобы сделать его таким же надежным, как и обычный веб-сервер может быть перед лицом плохих парней. Возможно, вам также придется использовать шифрование и аутентификацию, которые абсолютно выполнимы, но потенциально могут потребовать немного больше работы.

Если ваша служба будет открыта для внешнего мира, вы можете рассмотреть возможность использования чего-то вроде Websockets (или даже HTTP / S, как предлагает Джим), с чем-то вроде Mongrel2, обеспечивающего перевод в ZeroMQ, и затем построением вашего внутреннего услуги с ZMQ.

Конечно, если у меня неправильный конец флешки и сама служба не будет общедоступной, то я бы определенно выбрал ZeroMQ - ее очень легко использовать практически во всех широко используемых языки, и есть несколько простых шаблонов, которые вы можете применить, чтобы добавить соответствующие уровни надежности (подробности см. в руководстве на http://zguide.zero.mq).