Сообщение Re[3]: message/data bus от 18.03.2024 10:46
Изменено 18.03.2024 10:49 ·
Re[3]: message/data bus
Здравствуйте, binks, Вы писали:
B>·>Не очень ясно что тут сообщение. Шина это просто штука для передачи сообщений.
B>·>Клиент делает запрос: кладёт сообщение в шину в определённый топик запросов. Обработчик запроса получает сообщение, делает вычисление, создаёт сообщение-ответ и кладёт в топик ответов. Клиент получает ответ. Что за "узнать статус"?
B>Я так понимаю что, то что описал это достаточно стандартный сценарий.
Ты описал стандартный request-response сценарий. Шина это про publish/subscribe. Потенциально несколько паблишеров и подписчиков, несколько разных топиков и т.п.
B>Клиент кидает в "шину" HTTP запрос, получает id запроса/задачи. Задача может быть долгоиграющей. Без WebSocket, используем только polling, соответственно клиент через определённый интервал запрашивает результат по id задачи.
В случае шины poll у тебя должен быть только способ транспорта сообщений (при отсуствии возможностей сделать нормальный websocket/etc). По poll нужно просто тупо "ждать" сообщений, любых, без привязки к какому-либо id.
Скажем, в случае UI типично будет как-то так:
1. Юзер жмёт кнопку.
2. Создаётся uuid correlation id и сообщение "команда", описывающее действие юзера.
3. В UI меняется состояние, отображаются "песочные часы", ожидание результата действия для данного id. Или просто "спасибо, понял".
4. Когда приходит сообщение в UI сопоставляется как дальше поменять состояние ui в зависимости от содержимого сообщения.
B>"Шина" это сервер, который принимает запрос, присваивает этому запросу id задачи/запроса. Раскидывает/маршрутизирует задачи на подключённые к ней сервисы.
Нет.
B>"Шина" и сервис работают через какой-то AMPQ. Для того же RabbitMQ есть разные паттерны RPC/RequestResponse. Сам сервис не знает что есть некий id задачи. Сервис, получив запрос от "шины", выполнив работу, обратно в этот же канал отдаёт результат работы. Когда "шина" получает ответ от сервиса, то в какую-то базу пишет ответ от сервиса по id задачи.
B>Если клиент запрашивает результат по id задачи, то "шина" знает что ответить клиенту.
Это скорее всего некий gateway, которые ковертирует request/response пару в поток сообщений туда-сюда.
Суть в том, что с шиной у тебя нет явно связи между сервисами/серверами, кроме как через AMPQ/аналог.
Например, вначале ты реализовал так, что твой request преобразовался в сообщение, потом это сообщение обработалось кем-то и ответ положился обратно, сформировав response:
Шина может помочь легко поменять топологию, добавив, например, ещё один обработчик в цепочку:
Request -> ReqMsg-topic -> [service A] -> Another-topic -> [service B] -> RespMsg-topic -> Response.
Или даже элементарно параллелить обработку
Или позолить вообще для одного request начать выдавать поток событий:
Или на одно и то же сообщение иметь несколько подписчиков. Т.е. юзер шлёт какую-то команду у себя в браузере и видит результат выполнения этой команды и в во всех открытых закладках браузера, и на мобилке и т.п.
Инымы словами, шина нужна не для того, чтобы похитрее типичный Request/Response реализовать, шоб враг не догадался как это всё работает, а для более гибкой передачи данных, чем Request/Response.
B>>>наверное до сотни килобайт (но что там будет дальше не знаю, может гораздо больше).
B>·>Обычно сообщения подразумеваются мелкие, до килобайта. Если больше — делают что-то вроде аттачей: большой результат кладётся в какой-нибудь сторадж, отправляется мелкое сообщение с указанием откуда взять результат.
B>Почему именно такое ограничение?
Потому что размер сообщения обычно определяет отзывчивость системы. Сообщения передаются и обрабатываются последовательно. Пока у тебя передаётся гиговое сообщение, другие сообщения ждут своей очереди. Ещё часто сообщения могут быть получены несколькими подписчиками, но не всем им необходим полный результат. Ещё для сообщений бывают redelivery при обрыве связи.
B>·>Не очень ясно что тут сообщение. Шина это просто штука для передачи сообщений.
B>·>Клиент делает запрос: кладёт сообщение в шину в определённый топик запросов. Обработчик запроса получает сообщение, делает вычисление, создаёт сообщение-ответ и кладёт в топик ответов. Клиент получает ответ. Что за "узнать статус"?
B>Я так понимаю что, то что описал это достаточно стандартный сценарий.
Ты описал стандартный request-response сценарий. Шина это про publish/subscribe. Потенциально несколько паблишеров и подписчиков, несколько разных топиков и т.п.
B>Клиент кидает в "шину" HTTP запрос, получает id запроса/задачи. Задача может быть долгоиграющей. Без WebSocket, используем только polling, соответственно клиент через определённый интервал запрашивает результат по id задачи.
В случае шины poll у тебя должен быть только способ транспорта сообщений (при отсуствии возможностей сделать нормальный websocket/etc). По poll нужно просто тупо "ждать" сообщений, любых, без привязки к какому-либо id.
Скажем, в случае UI типично будет как-то так:
1. Юзер жмёт кнопку.
2. Создаётся uuid correlation id и сообщение "команда", описывающее действие юзера.
3. В UI меняется состояние, отображаются "песочные часы", ожидание результата действия для данного id. Или просто "спасибо, понял".
4. Когда приходит сообщение в UI сопоставляется как дальше поменять состояние ui в зависимости от содержимого сообщения.
B>"Шина" это сервер, который принимает запрос, присваивает этому запросу id задачи/запроса. Раскидывает/маршрутизирует задачи на подключённые к ней сервисы.
Нет.
B>"Шина" и сервис работают через какой-то AMPQ. Для того же RabbitMQ есть разные паттерны RPC/RequestResponse. Сам сервис не знает что есть некий id задачи. Сервис, получив запрос от "шины", выполнив работу, обратно в этот же канал отдаёт результат работы. Когда "шина" получает ответ от сервиса, то в какую-то базу пишет ответ от сервиса по id задачи.
B>Если клиент запрашивает результат по id задачи, то "шина" знает что ответить клиенту.
Это скорее всего некий gateway, которые ковертирует request/response пару в поток сообщений туда-сюда.
Суть в том, что с шиной у тебя нет явно связи между сервисами/серверами, кроме как через AMPQ/аналог.
Например, вначале ты реализовал так, что твой request преобразовался в сообщение, потом это сообщение обработалось кем-то и ответ положился обратно, сформировав response:
Request -> ReqMsg-topic -> [service] -> RespMsg-topic -> Response.Шина может помочь легко поменять топологию, добавив, например, ещё один обработчик в цепочку:
Request -> ReqMsg-topic -> [service A] -> Another-topic -> [service B] -> RespMsg-topic -> Response.
Или даже элементарно параллелить обработку
Request -> ReqMsg-topic -> [service A] --> Another-topic -> [service B] ----> [service D] -> RespMsg-topic -> Response.
\-----------------------> [service C] -----------/Или позолить вообще для одного request начать выдавать поток событий:
Request -> ReqMsg-topic -> [service] -> RespMsg-topic --> Response 1
\-> Response 2
\-> Response 3Или на одно и то же сообщение иметь несколько подписчиков. Т.е. юзер шлёт какую-то команду у себя в браузере и видит результат выполнения этой команды и в во всех открытых закладках браузера, и на мобилке и т.п.
Инымы словами, шина нужна не для того, чтобы похитрее типичный Request/Response реализовать, шоб враг не догадался как это всё работает, а для более гибкой передачи данных, чем Request/Response.
B>>>наверное до сотни килобайт (но что там будет дальше не знаю, может гораздо больше).
B>·>Обычно сообщения подразумеваются мелкие, до килобайта. Если больше — делают что-то вроде аттачей: большой результат кладётся в какой-нибудь сторадж, отправляется мелкое сообщение с указанием откуда взять результат.
B>Почему именно такое ограничение?
Потому что размер сообщения обычно определяет отзывчивость системы. Сообщения передаются и обрабатываются последовательно. Пока у тебя передаётся гиговое сообщение, другие сообщения ждут своей очереди. Ещё часто сообщения могут быть получены несколькими подписчиками, но не всем им необходим полный результат. Ещё для сообщений бывают redelivery при обрыве связи.
Re[3]: message/data bus
Здравствуйте, binks, Вы писали:
B>·>Не очень ясно что тут сообщение. Шина это просто штука для передачи сообщений.
B>·>Клиент делает запрос: кладёт сообщение в шину в определённый топик запросов. Обработчик запроса получает сообщение, делает вычисление, создаёт сообщение-ответ и кладёт в топик ответов. Клиент получает ответ. Что за "узнать статус"?
B>Я так понимаю что, то что описал это достаточно стандартный сценарий.
Ты описал стандартный request-response сценарий. Шина это про publish/subscribe. Потенциально несколько паблишеров и подписчиков, несколько разных топиков и т.п.
B>Клиент кидает в "шину" HTTP запрос, получает id запроса/задачи. Задача может быть долгоиграющей. Без WebSocket, используем только polling, соответственно клиент через определённый интервал запрашивает результат по id задачи.
В случае шины poll у тебя должен быть только способ транспорта сообщений (при отсуствии возможностей сделать нормальный websocket/etc). По poll нужно просто тупо "ждать" сообщений, любых, без привязки к какому-либо id.
Скажем, в случае UI типично будет как-то так:
1. Юзер жмёт кнопку.
2. Создаётся uuid correlation id и сообщение "команда", описывающее действие юзера.
3. В UI меняется состояние, отображаются "песочные часы", ожидание результата действия для данного id. Или просто "спасибо, понял".
4. Когда приходит сообщение в UI сопоставляется как дальше поменять состояние ui в зависимости от содержимого сообщения.
B>"Шина" это сервер, который принимает запрос, присваивает этому запросу id задачи/запроса. Раскидывает/маршрутизирует задачи на подключённые к ней сервисы.
Нет.
B>"Шина" и сервис работают через какой-то AMPQ. Для того же RabbitMQ есть разные паттерны RPC/RequestResponse. Сам сервис не знает что есть некий id задачи. Сервис, получив запрос от "шины", выполнив работу, обратно в этот же канал отдаёт результат работы. Когда "шина" получает ответ от сервиса, то в какую-то базу пишет ответ от сервиса по id задачи.
B>Если клиент запрашивает результат по id задачи, то "шина" знает что ответить клиенту.
Это скорее всего некий gateway, которые ковертирует request/response пару в поток сообщений туда-сюда.
Суть в том, что с шиной у тебя нет явно связи между сервисами/серверами, кроме как через AMPQ/аналог.
Например, вначале ты реализовал так, что твой request преобразовался в сообщение, потом это сообщение обработалось кем-то и ответ положился обратно, сформировав response:
Шина может помочь легко поменять топологию, добавив, например, ещё один обработчик в цепочку:
Или даже элементарно параллелить обработку
Или позолить вообще для одного request начать выдавать поток событий:
Или на одно и то же сообщение иметь несколько подписчиков. Т.е. юзер шлёт какую-то команду у себя в браузере и видит результат выполнения этой команды и в во всех открытых закладках браузера, и на мобилке и т.п.
Инымы словами, шина нужна не для того, чтобы похитрее типичный Request/Response реализовать, шоб враг не догадался как это всё работает, а для более гибкой передачи данных, чем Request/Response.
B>>>наверное до сотни килобайт (но что там будет дальше не знаю, может гораздо больше).
B>·>Обычно сообщения подразумеваются мелкие, до килобайта. Если больше — делают что-то вроде аттачей: большой результат кладётся в какой-нибудь сторадж, отправляется мелкое сообщение с указанием откуда взять результат.
B>Почему именно такое ограничение?
Потому что размер сообщения обычно определяет отзывчивость системы. Сообщения передаются и обрабатываются последовательно. Пока у тебя передаётся гиговое сообщение, другие сообщения ждут своей очереди. Ещё часто сообщения могут быть получены несколькими подписчиками, но не всем им необходим полный результат. Ещё для сообщений бывают redelivery при обрыве связи.
B>·>Не очень ясно что тут сообщение. Шина это просто штука для передачи сообщений.
B>·>Клиент делает запрос: кладёт сообщение в шину в определённый топик запросов. Обработчик запроса получает сообщение, делает вычисление, создаёт сообщение-ответ и кладёт в топик ответов. Клиент получает ответ. Что за "узнать статус"?
B>Я так понимаю что, то что описал это достаточно стандартный сценарий.
Ты описал стандартный request-response сценарий. Шина это про publish/subscribe. Потенциально несколько паблишеров и подписчиков, несколько разных топиков и т.п.
B>Клиент кидает в "шину" HTTP запрос, получает id запроса/задачи. Задача может быть долгоиграющей. Без WebSocket, используем только polling, соответственно клиент через определённый интервал запрашивает результат по id задачи.
В случае шины poll у тебя должен быть только способ транспорта сообщений (при отсуствии возможностей сделать нормальный websocket/etc). По poll нужно просто тупо "ждать" сообщений, любых, без привязки к какому-либо id.
Скажем, в случае UI типично будет как-то так:
1. Юзер жмёт кнопку.
2. Создаётся uuid correlation id и сообщение "команда", описывающее действие юзера.
3. В UI меняется состояние, отображаются "песочные часы", ожидание результата действия для данного id. Или просто "спасибо, понял".
4. Когда приходит сообщение в UI сопоставляется как дальше поменять состояние ui в зависимости от содержимого сообщения.
B>"Шина" это сервер, который принимает запрос, присваивает этому запросу id задачи/запроса. Раскидывает/маршрутизирует задачи на подключённые к ней сервисы.
Нет.
B>"Шина" и сервис работают через какой-то AMPQ. Для того же RabbitMQ есть разные паттерны RPC/RequestResponse. Сам сервис не знает что есть некий id задачи. Сервис, получив запрос от "шины", выполнив работу, обратно в этот же канал отдаёт результат работы. Когда "шина" получает ответ от сервиса, то в какую-то базу пишет ответ от сервиса по id задачи.
B>Если клиент запрашивает результат по id задачи, то "шина" знает что ответить клиенту.
Это скорее всего некий gateway, которые ковертирует request/response пару в поток сообщений туда-сюда.
Суть в том, что с шиной у тебя нет явно связи между сервисами/серверами, кроме как через AMPQ/аналог.
Например, вначале ты реализовал так, что твой request преобразовался в сообщение, потом это сообщение обработалось кем-то и ответ положился обратно, сформировав response:
Request -> ReqMsg-topic -> [service] -> RespMsg-topic -> Response.Шина может помочь легко поменять топологию, добавив, например, ещё один обработчик в цепочку:
Request -> ReqMsg-topic -> [service A] -> Another-topic -> [service B] -> RespMsg-topic -> Response.Или даже элементарно параллелить обработку
Request -> ReqMsg-topic -> [service A] --> Another-topic -> [service B] ----> [service D] -> RespMsg-topic -> Response.
\-----------------------> [service C] -----------/Или позолить вообще для одного request начать выдавать поток событий:
Request -> ReqMsg-topic -> [service] -> RespMsg-topic --> Response 1
\-> Response 2
\-> Response 3Или на одно и то же сообщение иметь несколько подписчиков. Т.е. юзер шлёт какую-то команду у себя в браузере и видит результат выполнения этой команды и в во всех открытых закладках браузера, и на мобилке и т.п.
Инымы словами, шина нужна не для того, чтобы похитрее типичный Request/Response реализовать, шоб враг не догадался как это всё работает, а для более гибкой передачи данных, чем Request/Response.
B>>>наверное до сотни килобайт (но что там будет дальше не знаю, может гораздо больше).
B>·>Обычно сообщения подразумеваются мелкие, до килобайта. Если больше — делают что-то вроде аттачей: большой результат кладётся в какой-нибудь сторадж, отправляется мелкое сообщение с указанием откуда взять результат.
B>Почему именно такое ограничение?
Потому что размер сообщения обычно определяет отзывчивость системы. Сообщения передаются и обрабатываются последовательно. Пока у тебя передаётся гиговое сообщение, другие сообщения ждут своей очереди. Ещё часто сообщения могут быть получены несколькими подписчиками, но не всем им необходим полный результат. Ещё для сообщений бывают redelivery при обрыве связи.