Задача дизайна - прокинуть детали низкоуровневой реализации на более высокий уровень и вернуть обратно

@Kastaneda · Регистрация: 12.12.2009

Студворк — интернет-сервис помощи студентам

Привет!

Задача возникла на работе. Мозговым штурмом было предложено 100500 реализаций, одно из них выбрали, но хотелось бы посмотреть на альтернативные варианты

Итак - есть RPC канал, который реагирует на события AMQP сервера (используется событийная модель). Из RPC канала нужно асинхронно ответить на сообщение, для этого AMQP нужны данные, о которых знает только AMQP. Т.е. эти данные нужно прокинуть из AMQP в RPC, и RPC потом должен эти данные вернуть. Чтоб все было кошерно нужно:
1. Чтобы RPC не знал об AMQP (транспорт должен быть заменяемым)
2. Не нужно заставлять пользователя (т.е. RPC) что-то куда-то прокидывать

Чтоб было понятней (очень упращенный вариант)

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// AMQP
void AmqpServer::mainLoop()
{
    // что-то делаем, в итоге получаем сообщение
   // при этом есть некий ID, который нужно знать при отправке ответа
   
    _messageHandler->onMessageReceived(message/*, также нужно как-то прокинуть упомянутый ID*/);
}
 
void AmqpServer::sendResponse (std::string response, /* и еще нужно знать упомянутый выше ID*/)
{
    // отправляем сообщение, используя ID
}
 
// RPC
void RpcChannel::onMessageReceived (std::string message/*, нужен еще ID*/)
{
    // обработали сообщение, сформировали ответ
 
    _responseHandler->sendResponse(response/*, плюс нужно вернуть ID*/);
}

Вариант с кешированием IDшников на стороне сервера сразу отметаем по ряду причин. Есть предложения?

@vxg · 23.11.2016, 13:44

Kastaneda, то есть:
-пришло сообщение из космоса на 1-й уровень (мы добавили к сообщению какие-то свои пометки)
-сообщение пересылается с 1-го на 2-й уровень
-ответ посылается со 2-го на 1-й уровень
-ответ уходит с 1-го уровня в космос (мы добавили к ответу какие-то свои пометки которые были добавлены к сообщению когда оно пришло)
так?
-----
ну тогда все нормально - взять и пихать в экстру. 2-й уровень даже не будет знать что там - просто перекинет экстру в ответ. а 1-й уровень сам должен знать как ему и что использовать

IGPIGP · 23.11.2016, 13:46

Сообщение от IGPIGP

На предмет есть ли там место для "комментария" в виде id.

В тех данных которые возвращаются без изменения (если есть такие). Это было бы идеально. Иначе придётся заставить клиента передать дополнительную инфу.

Добавлено через 1 минуту

Сообщение от vxg

2-й уровень даже не будет знать что там - просто перекинет экстру в ответ.

Кроме того, что ему придётся знать, что экстру надо перекинуть в ответ.

@vxg · 23.11.2016, 13:53

Сообщение от IGPIGP

Кроме того, что ему придётся знать, что экстру надо перекинуть в ответ.

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

IGPIGP · 23.11.2016, 13:56

Сообщение от vxg

ришло сообщение из космоса

Я увидел только 1 и 2 уровни. Первому нужно знать что-то о происшедшем на момент отправки (о времени отправки например) на 2. 2 должен вернуть первому то что должен (то о чём он знает) + вот эту дополнительную информацию.
И заставить его вернуть её может быть самостоятельной задачкой.

Или я усложняю, Kastaneda?

Добавлено через 58 секунд

Сообщение от vxg

мы слишком мало знаем про архитектуру что бы делать выводы о том что ему будет сложно или даже невозможно.

Это верно. Гадаем.

Но фраза о том что "2 не должен знать" звучит довольно жестко. Как же он добавит к тому что "знает". Ему что, метод расшифровки сообщения и подготовки ответа сереализовать и в сообщение положить вначале?

@vxg · 23.11.2016, 14:06

IGPIGP, если фраза "2 не должен знать" моя то я имел ввиду что 2-й уровень просто будет знать что нужно прицепить к ответу экстру взятую из запроса. содержимое в этом случае знать не нужно. нужно знать только размер. ну или в более общем случае - нужно только скопировать ссылку на экстру или вызвать метод clone

IGPIGP · 23.11.2016, 14:23

Сообщение от vxg

если фраза "2 не должен знать" моя то я имел ввиду что 2-й уровень просто будет знать что нужно прицепить к ответу экстру взятую из запроса.

нет эта фраза есть в постановке:

Сообщение от Kastaneda

для этого AMQP нужны данные, о которых знает только AMQP.

Тут возможно, надо анализировать активное содержимое сообщения, если оно есть. (полубред в отсутствии конкретики).

@Kastaneda · 24.11.2016, 07:34 **[ТС]**

Сообщение от vxg

Kastaneda, то есть:
-пришло сообщение из космоса на 1-й уровень (мы добавили к сообщению какие-то свои пометки)
-сообщение пересылается с 1-го на 2-й уровень
-ответ посылается со 2-го на 1-й уровень
-ответ уходит с 1-го уровня в космос (мы добавили к ответу какие-то свои пометки которые были добавлены к сообщению когда оно пришло)
так?

Sorry, если не понятно объяснил. Реально происходит следующее:
1. На AMQP сервер приходит сообщение. Сообщение содержит в том числе поля replyTo и correlationID, которые нужны для формирования ответа на это сообщение.
2. Сообщение нужно отдать на верх (уровень RPC).
3. RPC должен его обработать и ответить. На уровне RPC ответ - это просто string
4/ AMQP должен упаковать этот ответ (string) в свой формат сообщения. Для этого ему нужны replyTo и correlationID,

Сообщение от IGPIGP

Кроме того, что ему придётся знать, что экстру надо перекинуть в ответ.

Да, что не есть хорошо. Плюс зачем ему (2-му уровню) приходят какие-то непонятные данные, которые ему даже не нужны.

Менять по идее можно все, что угодно. Чтоб было понятно, у нас тут были предолжены например такие варианты:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// AMQP
void AmqpServer::mainLoop()
{
    // что-то делаем, в итоге получаем сообщение
   // при этом есть некий ID, который нужно знать при отправке ответа
   
   auto sendResponse = std::bind(&AmqpServer::sendResponse, this, replyTo, correlationId, _1);
    _messageHandler->onMessageReceived(message, sendResponse);
}
 
void AmqpServer::sendResponse (std::string replyTo, std::string correlationId, std::string response)
{
    // отправляем сообщение
}
 
// RPC
void RpcChannel::onMessageReceived (std::string message, std::function<void(std::string) sendResponse)
{
    // обработали сообщение, сформировали ответ
    sendResponse(response);
}

Либо тоже самое, но через паттерн "Команда". Либо создать класс Request, который имеет метод createResponse(), этот Request передать в RPC, а там дернуть createResponse(), и в этом response будут невидимые для RPC replyTo и correlationID. Этот response отдаем в AMQP и он уже может прочитать нужные ему поля (как вариант через френдов можно разрулить доступ к полям).

Это более менее адекватные предложения (были совсем не адекватные

), но мне лично ни один из этих подходов не нравится. Интуитивно чувствуется какая-то костыльность, есть ощущение, что можно сделать лучше/проще, но решение в голову не лезет.

@vxg · 24.11.2016, 10:09

Сообщение от Kastaneda

есть ощущение, что можно сделать лучше/проще, но решение в голову не лезет

-написать базовый класс "сообщение"
-этот класс имеет виртуальный метод "добавить данные" принимающий и сохраняющий в объекте некие данные (replyTo и correlationID в случае AMQP) и "сформировать ответ" принимающий message от RPC и возвращающий то что должен послать AMQP (или иная сущность)
-написать производный класс "сообщение AMQP" в котором реализовать эти методы
-во время приема сообщения "добавлять данные"
-перед отправкой "формировать ответ"

IGPIGP · 24.11.2016, 11:00

Сообщение от Kastaneda

Либо создать класс Request, который имеет метод createResponse(), этот Request передать в RPC

Сообщение от это легко

Коля: -Как мне, на уроке, передать записку Леночке, но так, чтобы не Марья Петровна ни Леночка этого не заметили.
Вася: -Видишь, в последнем ряду пустую парту? Положи в неё записку, а потом двигай её в первый ряд, - к парте Леночки.

Kastaneda, я всё ещё не понимаю механики. Для меня важно как RPC формирует и отправляет ответ. Ведь это он должен "не зная отправить"?
Поэтому, говоря мутно и заклинательно:
Если в сообщении AMPQ можно передать метод который будет автоматически запущен пока текст сообщения еще не потерян, то можно этот метод использовать либо путём расширения его кода, либо путём приаттачивания делегата к программному обеспечению RPC. Но избыточной информации в виде как активной части сообщения так и прилагаемых данных не избежать. В этом случае "RPC не знает" будет означать, "не должен знать до получения". Даже при использовании делегата, он таки не знает, хоть и может проверить цепочку актуальных делегатов. Потому что новый может её изменить.

Но при отправке он будет знать и делать.
Иначе, нужен прокси хардвер объект, который будет между. То есть будет включать в себя RPC. Но это та же парта, но тяжелая.

Простите, если не врубаюсь.

@vxg · 24.11.2016, 11:04

Не по теме:

IGPIGP, магнитный монополь... :)

IGPIGP · 24.11.2016, 11:10

Не по теме:

IGPIGP, магнитный монополь...

Пол магнита, - эка невидаль. У барона вон, пол коня было! Правда увековечили целиком, а струю приаттачили читая ТЗ под чутким руководством бургомистра. Но вышло не менее весело и поучительно. :yes:

@Kastaneda · 24.11.2016, 12:17 **[ТС]**

Сообщение от vxg

-написать базовый класс "сообщение"
-этот класс имеет виртуальный метод "добавить данные" принимающий и сохраняющий в объекте некие данные (replyTo и correlationID в случае AMQP) и "сформировать ответ" принимающий message от RPC и возвращающий то что должен послать AMQP (или иная сущность)
-написать производный класс "сообщение AMQP" в котором реализовать эти методы
-во время приема сообщения "добавлять данные"
-перед отправкой "формировать ответ"

Была такая идея, но тогда в AMQP сообщение будет передано по интерфейсу (базовому классу) и внутри AMQP нужно будет делать down cast, что тоже хочется избежать, т.к. теоретически cast может быть невалидным.

Сообщение от IGPIGP

я всё ещё не понимаю механики. Для меня важно как RPC формирует и отправляет ответ.

RPC выполняет команды, которые приходят по сети (через AMQP). Допустим пришла команда "дай мне серверное время", AMQP отбрасывает оттуда все, что касается протокола AMQP и отдает в RPC строку "дай мне серверное время". RPC понимает эту строку и возвращает строку "14:53". Т.е. на уровне RPC есть только строки "команда" и "ответ".

Сообщение от IGPIGP

нужен прокси хардвер объект

Кстати выглядит не плохо, ща обдумаю.

Добавлено через 8 минут

Сообщение от Kastaneda

Кстати выглядит не плохо, ща обдумаю.

Не, теретически верхний уровень (RPC) работает асинхронно, поэтому данные внутри прокси могут не соответствовать тому запросу, на который мы отвечаем. Тогда нужно как-то хранить данные, и тогда нужно как-то давать понять прокси на какой запрос мы отвечаем. В этом случае профит от прокси теряется. Было все синхронно было бы проще.

@vxg · 24.11.2016, 12:27

Сообщение от Kastaneda

т.к. теоретически cast может быть невалидным

с чего бы это вдруг? вы реализацию на лету можете поменять между приемом и ответом одного сообщения?

Добавлено через 2 минуты
...даже если так базовый класс может поддерживать единую для всех реализаций функцию "узнай какого типа сообщение внутри меня" - если при ответе мы видим что сообщение сформировано другой реализацией очевидно был горячий рестарт и нам не остается ничего кроме как отбросить такое сообщение так как мы не знаем как с ним работать

IGPIGP · 24.11.2016, 13:12

Сообщение от Kastaneda

Тогда нужно как-то хранить данные, и тогда нужно как-то давать понять прокси на какой запрос мы отвечаем.

Хранить данные обязательно. И на AMQP же хранится id, если только id не является "командной" информацией. Давать понять придётся так же как Вы собираетесь делать сейчас, но возможно более явно, что просто проще.

Сообщение от Kastaneda

В этом случае профит от прокси теряется.

Профит от ~~тяжелой парты~~ прокси компонента только в том, что есть возможность сохранить программное обеспечение RPC совершенно нетронутым. То есть он действительно сможет "не знать". Но у такого неведения есть немалая цена. Это правда.
Это не потому, что фраза "знание умножает скорбь" неправа. Это потому что и незнание её тоже, мягко говоря, не уменьшает. Только мы с Вами можем её уменьшить. Например, тиснуть вот такой смайлик:

HighPredator · 28.11.2016, 17:53

Kastaneda, очень долго читал, но так до конца и не понял. Вы можете словесно-схематично+абстрактно (без аббривеатур, а на уровне класс1/черный_ящик1) показать желаемую схему работы в контексте обмена данными?

Новые блоги и статьи Все статьи Все блоги /
Паттерн очереди действий/команд (Action / Command Queue). Система очереди действий и кат-сцен с SDL3 Callbacks, cglm и OpenGL 8Observer8 07.11.2026 Содержание блога \| English Version Руководство для начинающих по реализации паттерна очереди действий/ команд (Action / Command Queue) на C++ (C++20) с использованием официального SDL3 Callbacks. . .	Проверка полного ФИО в типовом справочнике Maks 07.11.2026 Решение реализовано в конфигурации КА2, на примере справочника "КонтактныеЛицаПартнеров". Задача: Запрет инициалов. Не допускаеть использование сокращений вида "И. И. ", "И. И. ", "И И" и. . .	Про "Windows must die!" kumehtar 04.11.2026 Знаете, чет накатило. . . . Когда-то это было почти боевым кличем: мол, нормальный человек сидит на DOS, OS/ 2 или Linux, а вот это вот - Must Die. А теперь человек произносит «мастдай» с усмешкой - и. . .	Красочные поля с номером страницы svg+background-image russiannick 04.11.2026 Красочные поля с номером страницы не менее важны чем в эпоху бумажных книг. Посему спешу представить почтеннейшей публике этот важный инструмент который эти поля и формирует. В процессе разработки. . .
Вступаем в новую фазу генерации favicons, векторную. russiannick 02.11.2026 Теперь нет нужды скрывать что используется простой svg. Исходный код изображения помещаем в поле и жмем кнопку. Исходник преобразуется в вид корректный для помещения в favicon или в url(). Нажатие. . .	Генератор паролей (вариант №4) Maks 01.11.2026 После публикации 3-го варианта генератора паролей, разослал его своим коллегам (с целью оценки), в итоге были получены следующие рекомендации: 1. Вернуть возможность использования знаков \| 1 l I;. . .	Генератор паролей (вариант №3) Maks 30.10.2026 Финальная версия генератора паролей 1С. Доработка решения в этот раз коснулась только визуальной части, а именно, добавлен реквизит ДопПараметры (тип Булево), который скрывает/ отображает реквизиты:. . .	Магическое мышление и магия, современная наука не отличима от магии (говорит ИИ Джемени) zorxor 30.10.2026 Джемени, расскажи, пожалуйста, что такое магическое мышление, что такое магия, почему современная наука чем-то напоминает магию? Фраза «Любая достаточно развитая технология неотличима от магии». . .

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,476
	23.11.2016, 13:44
	Kastaneda, то есть: -пришло сообщение из космоса на 1-й уровень (мы добавили к сообщению какие-то свои пометки) -сообщение пересылается с 1-го на 2-й уровень -ответ посылается со 2-го на 1-й уровень -ответ уходит с 1-го уровня в космос (мы добавили к ответу какие-то свои пометки которые были добавлены к сообщению когда оно пришло) так? ----- ну тогда все нормально - взять и пихать в экстру. 2-й уровень даже не будет знать что там - просто перекинет экстру в ответ. а 1-й уровень сам должен знать как ему и что использовать 0

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,476
	23.11.2016, 14:06
	IGPIGP, если фраза "2 не должен знать" моя то я имел ввиду что 2-й уровень просто будет знать что нужно прицепить к ответу экстру взятую из запроса. содержимое в этом случае знать не нужно. нужно знать только размер. ну или в более общем случае - нужно только скопировать ссылку на экстру или вызвать метод clone 0

@vxg
	24.11.2016, 11:04
	Не по теме: IGPIGP, магнитный монополь... :) 0

HighPredator 6045 / 2160 / 753 Регистрация: 10.12.2010 Сообщений: 6,005 Записей в блоге: 3
	28.11.2016, 17:53
	Kastaneda, очень долго читал, но так до конца и не понял. Вы можете словесно-схематично+абстрактно (без аббривеатур, а на уровне класс1/черный_ящик1) показать желаемую схему работы в контексте обмена данными? 1