Мы используем ZeroMQ в нашем проекте в качестве брокера сообщений, как показано на рисунке ниже. Это позволяет нам разделить две разные стороны и масштабировать их независимо друг от друга. Мы отправляем данные от одной стороны (Service1) и получаем их от другой стороны (Service1) благодаря ZeroMQ.
Поскольку он не предлагает гарантированную доставку сообщений из коробки, и поскольку это крайне важно для чтобы не потерять какие-либо данные при отправке, мы проверяем брокер сообщений, если он жив, отправляя тактовые импульсы в обратном направлении в качестве обходного пути.
Мы используем типы сокетов PUB-SUB для отправки данных и типы сокетов SUB-PUB для отправки биений в обратном направлении.
Мы заметили, что данные и пульс иногда могут проходить через различные балансировщики нагрузки в нашей топологии. Это вызывает такую проблему, что мы не можем заметить, когда балансировщик нагрузки при передаче данных (например, LB1) выходит из строя только потому, что по-прежнему работает балансировщик нагрузки, передающий пульс (например, LB2). Наша логика предполагает, что все в порядке только потому, что он все еще получает сердцебиение. Но на самом деле есть проблема, наши данные не передаются, поскольку балансировщик нагрузки не работает.
Мы попытались объединить сокеты данных и пульса. Мы думали, что сможем преодолеть другую проблему балансировки нагрузки, если обработаем эти два разных сообщения в одном сокете. Мы искали тип сокета в ZeroMQ, который позволяет двустороннюю неблокирующую связь, а также дает возможность обеим сторонам отправлять сообщения в любое время без блокировки.
Дилер - Дилер показался хорошим вариантом, так как он допускает двустороннюю и неблокирующую связь. Но у нас также есть другое требование. Мы хотим, чтобы наши экземпляры Service1 не привязывались только к конкретному посреднику сообщений, но каждый раз отправляли сообщение другому посреднику сообщений. Вот почему каждый экземпляр Service1 связан с каждым экземпляром посредника сообщений в образе. Поэтому на этот раз тип DEALER не позволяет отправлять тактовые импульсы каждому подписчику Service1, поскольку структура DEALER - DEALER удобна для стиля 1: 1. Экземпляр Service1 не будет получать каждый пинг, а только часть, которая неприемлема для нашего сценария.
Сервис1 - Сервис1.java
ZMQ.Context context;
ZMQ.Socket dataSocket;
ZMQ.Socket heartbeatSocket;
dataSocket = context.socket(ZMQ.PUB);
dataSocket.connect(messageBrokerDataReceiveEndpoint);
heartbeatSocket = context.socket(ZMQ.SUB);
heartbeatSocket.connect(messageBrokerHeartbeatEndpoint);
MessageBroker - Broker.java
ZMQ.Context context;
ZMQ.Socket dataSendSocket;
ZMQ.Socket dataReceiveSocket
dataSendSocket = context.socket(ZMQ.XPUB);
dataSendSocket.bind(messageBrokerDataSendEndpoint);
dataReceiveSocket = context.socket(ZMQ.XSUB);
dataReceiveSocket.bind(messageBrokerDataReceiveEndpoint);
ZMQ.proxy(dataSendSocket, dataReceiveSocket, null);
MessageBroker - Heartbeat.java
//run this block in a scheduled way (e.g. 500ms)
ZMQ.Context context;
ZMQ.Socket heartbeatSocket;
heartbeatSocket = context.socket(ZMQ.PUB);
heartbeatSocket.bind(messageBrokerHeartbeatEndpoint);
Сервис2 - Сервис2.java
ZMQ.Context context;
ZMQ.Poller poller;
ZMQ.Socket dataSocket;
dataSocket = context.socket(ZMQ.SUB);
dataSocket.connect(messageBrokerDataSendEndpoint);
/*
poller checks each message broker instance and if there is something new,
it fetches and shares the data with each Service2 instance
*/
Нам интересно, есть ли какой-либо тип или структура сокетов, которые предлагает ZeroMQ, которые бы соответствовали нашим требованиям. За упоминание их снова;
* нам нужно отправить сообщение от одной стороны другой
* нам нужно передавать данные и пульс по одному и тому же сокету
* Экземпляры Service1 должны иметь возможность взаимодействовать с каждым экземпляром брокера сообщений, а брокер сообщений должен иметь возможность пересылать сообщение каждому экземпляру Service2
Мы ценим, если вы можете предложить подходящий тип сокета или другую архитектуру, которая по-другому отвечает нашим потребностям.