Между "приказ самурая" и "творчество раба" есть разница. Тоёта хочет денег, для этого оптимизирует процессы на фабриках, процессы включают "нечёткую логику" в виде работников, значит в этом направлении самурай тоже обязан думать, ну и он придумал - нужно "нечёткость" поставить на службу самураю. Точнее, японцы это дело заимствовали из СССР, хотя не до конца ясно, на сколько процентов. Итогом заимствования стала система, где каждый работник попадал в ситуацию, когда трудно было делать некачественно, а качественно делать было выгодно. Так они решали задачу, поставленную главным самураем.
Обратите внимания - в ней нет ничего "снизу". Она поставлена полностью сверху. Всё, что не касалось вопросов локальных улучшений в процессе накопления денег, не подлежало обсуждению с настоящими самураями. То есть строгая иерархия ставила каждого работника в тесные рамки, внутри которых у него была некоторая свобода, но за пределами - никакой свободы не было. И пассивное большинство вполне находило удовольствие в возне с локальными улучшениями, чем оно практически всегда и ограничивалось. Смотреть же выше было просто нельзя - это прерогатива старшего самурая, а старший самурай не может ошибаться, и если самураю сказать, что он ошибается, то долг самурая - отрубить голову сказавшему. Так поддерживалась жёсткость иерархии в Японии с древних времён.
Посмотрите японские фильмы про самураев, там очень наглядно показаны все эти поклоны и ритуальные танцы около старших, даже если они толстые и ни на что не способные ленивцы. В военное время, видимо, это было весьма эффективно. Но сегодня такой подход выродился в проблему.
Ну а про фабрику в америке - ну да, что-то там японцы внедрили. Только принцип был всё тот же - самурай всегда прав. Самурай даже был готов вести переговоры с силой в виде профсоюзов, но ни в коем случае не вёл переговоры с работниками.
Я, конечно, несколько утрирую, но суть именно такая - древняя традиция централизованной диктатуры.
Здесь скорее проявлялся диктаторский стиль руководства в японской промышленности - подчинённый есть никто и его предложения даже слушать вряд ли будут. Хотя по задачам, поставленным диктатором, подчинённый обязан вносить дельные предложения и самоотверженно умирать во благо корпорации (дух самурая). Поэтому разговор с подчинённым не имеет смысла в тех задачах, которые ему не поручал главный самурай.
Но что интересно, верховные самураи всё же как-то сумели додуматься до всех этих канбанов и прочих "точно вовремя". И при этом рассматривали подчинённых лишь как полезный и бездушный инструмент. То есть скорее всего сами дошли до понимания, без помощи рабов.
А потом была достигнута граница эффективности "верховного самурайства". Но отношение к рабам не сильно изменилось. То есть закостенели (и скорее всего уже поумирали) умные верховные самураи. А после них остались лишь бесхребётные слизни. Так-то вот кончаются диктатуры.
Сторонники свободной конкуренции точно так же сильно всё упрощают. А сарказм они не понимают, потому что свободная конкуренция "только для меня" выгоднее, чем все остальные предложения, поскольку они "не только для меня". То есть помимо логически порочного подхода здесь присутствует ещё и мотив выгоды (правда многие довольствуются лишь порочной логикой, даже не задумываясь о выгоде).
Анализ, вот та засада, в которую попадаются "управленцы 21-го века". В прошлые века они туда тоже попадались, но как-то так навязчиво не выпячивали случайные достижения, поэтому выглядели "прилично", без заскоков. А в 21-м веке весь пар идёт в саморекламу, что делает попытки анализировать просто бессмысленными. Ну и сложность несколько подросла. В итоге топы стали главным стопором.
Очень просто. Пример - два вора идут на дело. Они вынуждены доверять друг другу. Иначе дело погорит. И после дела тоже доверяют. Иначе получится ситуация "кто первый сдаст".
Вы, как и многие сторонники искажённой модели социализма, имевшей место в СССР, упускаете из вида массу деталей, в которых порылся дьявол.
Глобально оптимизировать систему с пятью степенями свободы вполне возможно, но когда степеней свободы будет миллион, или даже миллиард, то вы уже сами понимаете своё полное бессилие.
Примитив, к которому сводится общество сторонниками социализма, коммунизма, марксизма и тому подобного, никогда не позволит обеспечить именно глобальную оптимизацию "для всех". Хотя глобальная оптимизация для царствующих паразитов вполне возможна, хотя и она будет далека от потенциально достижимой эффективности.
Сложные задачи требуют сложных решений. Отойдёте от примитива - найдёте решение. Или не найдёте. Потому что в сравнении со сложностью задачи все мы ничтожны. Но если не отходить от примитива - точно решений не найдёте.
10 лет - оптимистично. Масштабирование технологии стоит копейки. Максимум год и все богатые конторы смогут себе позволить поувольнять почти всех в поддержке первой линии. Правда есть нюанс - им не дадут доступ к технологии. Поэтому вся их деятельность по поддержке будет полностью зависеть от соответствующего провайдера умного железа. Это риск. Из-за него внедрение несколько затормозится.
Но, с другой стороны, у OpenAI есть конкуренты. Во что выльется конкурентная борьба? Пока технология несколько хуже уверенных в превосходстве человека над ИИ её есть смысл продавать. Поэтому службу поддержки всё же быстро разгонят и заменят железом. При всей медлительности года за два управятся, максимум три.
Но к этому моменту ИИ будет уже сильно умнее. Что будет тогда? Будет лишь одно ограничение - скорость масштабирования.
Психология появляется тогда, когда возникают желания. Нейросеть кормят входными данными и стимулами при попадании в ответ или промахе. Кроме этого там ничего нет. То есть нет места для зарождения желаний.
Аналогия - вас будят и показывают изображение. Вы натренированы на ответ с названием объекта на изображении. В момент, когда название произнесено, вас усыпляют. Не ответить нельзя, паузу перед ответом допускать нельзя. Нет времени для желаний. Машина не хочет спать, не болеет, не сожалеет, она - робот. Без чувств. Без психологии.
Вы выбрали ложное направление исследования.
Или же время для вашего исследования ещё не наступило. Пока в мире главное - сколько денег даст робот. Для этого нужна только логика. Ничего, кроме логики. Хотя да, ещё нужны данные, на которых оперирует логика. Но это тоже мёртвая сущность.
Да, в варианте от IBM ESB использует на каждый чих по WebSphere (сервер приложений). Но зато вы получаете готовую инфраструктуру, на которую стандартным образом ставятся приложения, которые так же написаны в соответствии со стандартами. Плюс графическое представление связей между очередями, с графическими редакторами для фильтров и отображений одних типов сообщений на другие.
Но никто же не заставляет использовать именно IBM. Есть много очередей, которые утверждают, что они на самом-то деле message broker. Только в каждом случае нужно смотреть, какой функционал там реально есть, и какого нет. Чаще всего много чего нет. Например в кафке есть маршрутизация и фильтрация, но на самом деле это всего лишь обработчики на Java, которые имеют доступ к топологии, которую, в свою очередь, внутри этих же обработчиков нужно писать руками. То есть формально похоже на брокер, но по факту нужно много ручных доработок.
Общий смысл такой - надо перебирать варианты. Наверное Java вам не нужна, поэтому вы наверняка исключите очереди на ней. Так что ваша специализация на Си вам должна подсказать, какие очереди для вас правильные. А среди них смотрите возможность автоматически строить цепочки обработки. Но может ничего приличного и не найдёте, всё-таки не зря IBM за много денег продаёт свою ESB и брокера.
А производительность зависит от многих факторов - выбрали опцию хранить сообщения в оракле - получите соответствующую производительность. Выберете потоковую запись на диск - производительность сильно улучшится. Но скорее всего вам и не нужна скорость в сотни тысяч сообщений в секунду, так что можно и в БД сообщения складывать.
В общем - задачу анализа вариантов я с вас не сниму.
Спасибо за подробный ответ. Его суть сводится к использованию очереди. Очередь даёт нам асинхронность, которая даёт устойчивость инфраструктуре. Я за использование очередей, но вы эту технологию использовали не имея хорошего представления об альтернативах. Альтернатива здесь известна давно - enterprise service bus (ESB).
ESB есть не просто набор очередей. Нормальный комплект включает множество адаптеров. И веб-сервисы в качестве адаптеров - самая стандартная функциональность. WSDL описывает адресацию и протокол. XSD описывает содержимое, поступающее с/на адаптер. Стандартные библиотеки на обоих концах взаимодействия дают вам именно вашу структуру в вашем представлении (не знаю, как это выглядит в Си, но обычно это классы, экземпляры которых вы получаете/отдаёте). Вызов тоже выглядит привычно для вашего ЯП (функция). Поступление данных - та же функция, но уже с вашей реализацией и описанной ранее структурой на входе. Если в какой-то части библиотеки не реализуют, например интересующий вас вариант входных функций, вы их можете легко сделать сами, или написать генератор, если функций много.
Это была часть, отвечающая за вход/выход, о которых вы много говорили. А дальше - те самые очереди. Но с маршрутизацией и какой-то обработкой вроде фильтрации/маппинга.
Основной плюс комплексного решения на основе известных стандартов - вы в основном рисуете лишь нужные вам бизнес-сущности. Всё остальное - генерируется или оборачивается стандартными библиотеками.
Другое дело, если вы не знакомы с полноценной реализацией такого взаимодействия. Полный цикл действительно реализуют не так много продуктов. Какая-нибудь Kafka реализует лишь свои собственные интерфейсы, ActiveMQ - поддерживает ряд стандартов, наверняка есть адаптеры для веб-сервисов. Но по отдельности это всё неполноценные решения, поскольку заметную часть придётся дописывать самому, особенно в случаях вроде кафки. Полноценные решения, вроде продуктов от IBM (Message Broker, который ближе к Си, или ESB, который полностью на Java), позволяют автоматически получать почти всю цепочку. Хотя в случае интеграции с Си я не знаю, какие есть варианты.
Ориентация на стандарты - ключ к такой архитектуре. Если стандартов нет, то нет и генераторов и прочих вспомогательных библиотек.
Ну и в вашем случае так же придётся писать какие-то адаптеры для вашей очереди. Хотя может быть вы нашли какую-то очередь с готовым адаптером protobuf, тут я не знаю.
Я пишу на Java, но даже в этой экосистеме сейчас сильно влияние моды, плюс ещё вопрос с санкциями. Но тем не менее, достаточно полноценные решения, где почти всё происходит автоматически, достаточно только описать нужные сущности, всё же существуют. А вот в среднем опыта разработки таких решений мало, ибо мода и каждый сам себе архитектор.
Ну и по микросервисам - хорошо, конечно, если вы ничем не ограничены по железу, сетям и т.д., но снимая сложность в разработке отдельных функций, вы перекладываете её на ту сущность, которая поддерживает взаимодействие функций. Здесь опять нужно очень много думать про правильный подход, потому что иначе в итоге вы запутаетесь, кто куда и когда что шлёт и почему получает. Описание мешанины из фильтрующих и преобразующих посредников станет невыносимым. Хотя если задача стандартная - обычный учёт каких-то бизнес-операций, то в ограничения вы не упрётесь, но только лишь потому, что сама задача примитивная - получил и сохранил, потом показал, и более ничего. Поэтому и процветают "архитектуры", которые решают несуществующие задачи, оставаясь в рамках примитивных требований.
вы не возражаете против самой концепции RPC поверх очереди сообщений?
Я не понимаю, чем обоснован выбор технологий. До очередей мы ещё не дошли.
если бы вы предоставили какой-то чуть более конкретный вариант формата
Я же представлял - XML XSD WSDL.
Берёте любой инструмент моделирования сущностей и на выходе получаете XSD. Включаете XSD в WSDL (опять же используя массу готовых инструментов), описываете методы (вызовы) - получаете RPC, который можно интерпретировать как ООП на уровне данных. Зачем ООП на уровне вызовов - не понимаю. Собственно в Си нужно всего лишь подключить библиотеку, которая отправляет и получает соответствующий XML на/с соответствующего адреса. Всё есть уже готовое, зачем велосипед?
Не знаю, возможно в С++ эти технологии никто не использует, но весь мир работает с ними и их аналогами. Поэтому и возник вопрос - зачем свой собственный протокол? Зачем потрачены усилия на его оформление и реализацию? Эти усилия, возьми вы привычные технологии, можно было бы сэкономить. Пока не вдаёмся в остальные концепты, только выбор - запилить свой велосипед вместо взять готовый. Не верю, что в С++ нет готовых велосипедов, а это означает, что они вам не подошли и вы захотели сделать свой. Чем не подошли? Ответа нет. Чем ваш лучше? Ответа нет.
Хотя один ответ вы старательно обходите стороной - личные предпочтения. На самом деле не стоит прятать такой мотив, особенно если других не видно. Это не плохо, если кто-то согласен подождать, когда вы всё сделаете. Опыт получите, тоже хорошо. Но статья как бы намекает, что есть и другие плюсы. Вот по ним и идёт разговор.
Команда должна говорить на одном технологическом языке
Это никак не относится к выбору протокола и форматов данных. Заменяем названия и получаем один язык.
Исходные коды разных разработчиков должны быть максимально изолированы друг от друга
Это никак не относится к протоколам и форматам данных.
делать новые фичи как отдельные проекты
Это никак не относится к протоколам и форматам данных.
Проверять соблюдение технических требований бэкенда должны специализированные инструменты
Это относится к протоколам и форматам данных лишь в части стандартизации, которой в вашем случае меньше, значит меньше и "стандартизированных инструментов".
Лучшая и самая достоверная документация - это исходный код
Это никак не относится к протоколам и форматам данных.
человек должен иметь возможность посмотреть траффик между его компонентами
Это относится к протоколам и форматам данных лишь в части читабельности форматов. Вы выбрали нечитабельный бинарный формат. Вы не видите несоответствия?
единый центр притяжения для всей информации
Это никак не относится к протоколам и форматам данных.
Итого: либо нет никакой связи с вашим выбором, либо связь негативная.
Но есть более реалистичный намёк:
А хотелось мне API, которое формулируется в терминах обычного ООП
Но и здесь нет никаких проблем с приближением к ООП. Ранее предложенные альтернативы отлично отображаются на объекты, данные и методы.
мне надо было поверх очереди прикрутить каким-то образом стилистику ООП
А это снова противоречие. Здесь "стилистика ООП" предполагает синхронность вызова. Вы же, нарушив стилистику, сделали вызовы асинхронными.
мне пока видится так, что у вас инструмент первичен
На самом деле я люблю велосипедить. Но всё же я стараюсь понимать, что я получаю взамен отвергнутого готового решения. В вашем случае я та к и не понял - зачем? Пока вижу лишь один мотив - захотелось творить.
Не знаю, как дела обстоят для C++, но скорее всего вы потеряли возможность использовать много полезных инструментов. А что приобрели? Возможность использовать привычный инструмент сериализации? И в довесок необходимость допиливать его под такие требования, которые уже реализованы для стандартных инструментов на основе XML, но не реализованы для выбранного вами.
Пилить свою реализацию приятно, но как-то бы это обосновать посерьёзнее, нежели просто "выбрал то, что знаю, остальное дописал как вижу". Например - указать на преимущества вашего ПО в сравнении с другими подходами. Хотя здесь мы опять возвращаемся к вопросу "что приобрели".
Зачем столько детализированных описаний внутренностей программы, когда давно существуют готовые механизмы на основе XML (или JSON, если хочется модного)?
Описание классов - XSD, описание сервисов - WSDL, возможности по документированию там встроенные, протокол - HTTP, куча готовых инструментов, набор идеологий на выбор для приверженцев любых вкусов и фломастеров (вроде enterprise service bus и т.д.).
Между "приказ самурая" и "творчество раба" есть разница. Тоёта хочет денег, для этого оптимизирует процессы на фабриках, процессы включают "нечёткую логику" в виде работников, значит в этом направлении самурай тоже обязан думать, ну и он придумал - нужно "нечёткость" поставить на службу самураю. Точнее, японцы это дело заимствовали из СССР, хотя не до конца ясно, на сколько процентов. Итогом заимствования стала система, где каждый работник попадал в ситуацию, когда трудно было делать некачественно, а качественно делать было выгодно. Так они решали задачу, поставленную главным самураем.
Обратите внимания - в ней нет ничего "снизу". Она поставлена полностью сверху. Всё, что не касалось вопросов локальных улучшений в процессе накопления денег, не подлежало обсуждению с настоящими самураями. То есть строгая иерархия ставила каждого работника в тесные рамки, внутри которых у него была некоторая свобода, но за пределами - никакой свободы не было. И пассивное большинство вполне находило удовольствие в возне с локальными улучшениями, чем оно практически всегда и ограничивалось. Смотреть же выше было просто нельзя - это прерогатива старшего самурая, а старший самурай не может ошибаться, и если самураю сказать, что он ошибается, то долг самурая - отрубить голову сказавшему. Так поддерживалась жёсткость иерархии в Японии с древних времён.
Посмотрите японские фильмы про самураев, там очень наглядно показаны все эти поклоны и ритуальные танцы около старших, даже если они толстые и ни на что не способные ленивцы. В военное время, видимо, это было весьма эффективно. Но сегодня такой подход выродился в проблему.
Ну а про фабрику в америке - ну да, что-то там японцы внедрили. Только принцип был всё тот же - самурай всегда прав. Самурай даже был готов вести переговоры с силой в виде профсоюзов, но ни в коем случае не вёл переговоры с работниками.
Я, конечно, несколько утрирую, но суть именно такая - древняя традиция централизованной диктатуры.
Здесь скорее проявлялся диктаторский стиль руководства в японской промышленности - подчинённый есть никто и его предложения даже слушать вряд ли будут. Хотя по задачам, поставленным диктатором, подчинённый обязан вносить дельные предложения и самоотверженно умирать во благо корпорации (дух самурая). Поэтому разговор с подчинённым не имеет смысла в тех задачах, которые ему не поручал главный самурай.
Но что интересно, верховные самураи всё же как-то сумели додуматься до всех этих канбанов и прочих "точно вовремя". И при этом рассматривали подчинённых лишь как полезный и бездушный инструмент. То есть скорее всего сами дошли до понимания, без помощи рабов.
А потом была достигнута граница эффективности "верховного самурайства". Но отношение к рабам не сильно изменилось. То есть закостенели (и скорее всего уже поумирали) умные верховные самураи. А после них остались лишь бесхребётные слизни. Так-то вот кончаются диктатуры.
Затратный способ - много пробовать.
Тоже затратный способ - иметь много информаторов (желательно в виде друзей).
Малозатратный способ - оставить всё как есть. Хотя долговременно затраты могут оказаться чрезмерными, но это ведь когда будет...
Сторонники свободной конкуренции точно так же сильно всё упрощают. А сарказм они не понимают, потому что свободная конкуренция "только для меня" выгоднее, чем все остальные предложения, поскольку они "не только для меня". То есть помимо логически порочного подхода здесь присутствует ещё и мотив выгоды (правда многие довольствуются лишь порочной логикой, даже не задумываясь о выгоде).
Качественный обзор. Коротко и по делу.
И более рациональный календарь тоже было бы неплохо "замутить".
Анализ, вот та засада, в которую попадаются "управленцы 21-го века". В прошлые века они туда тоже попадались, но как-то так навязчиво не выпячивали случайные достижения, поэтому выглядели "прилично", без заскоков. А в 21-м веке весь пар идёт в саморекламу, что делает попытки анализировать просто бессмысленными. Ну и сложность несколько подросла. В итоге топы стали главным стопором.
Очень просто. Пример - два вора идут на дело. Они вынуждены доверять друг другу. Иначе дело погорит. И после дела тоже доверяют. Иначе получится ситуация "кто первый сдаст".
Вы, как и многие сторонники искажённой модели социализма, имевшей место в СССР, упускаете из вида массу деталей, в которых порылся дьявол.
Глобально оптимизировать систему с пятью степенями свободы вполне возможно, но когда степеней свободы будет миллион, или даже миллиард, то вы уже сами понимаете своё полное бессилие.
Примитив, к которому сводится общество сторонниками социализма, коммунизма, марксизма и тому подобного, никогда не позволит обеспечить именно глобальную оптимизацию "для всех". Хотя глобальная оптимизация для царствующих паразитов вполне возможна, хотя и она будет далека от потенциально достижимой эффективности.
Сложные задачи требуют сложных решений. Отойдёте от примитива - найдёте решение. Или не найдёте. Потому что в сравнении со сложностью задачи все мы ничтожны. Но если не отходить от примитива - точно решений не найдёте.
А вы правильно представляете?
Уверенно нести чушь на произвольную тему это одно, а рассказать где завис перевод, оперируя простыми данными, это совсем другое.
Ну и чушь оно уверенно несёт очень редко.
Ваша ставка принята. Ответ будет заметен на глаз лет через пять.
10 лет - оптимистично. Масштабирование технологии стоит копейки. Максимум год и все богатые конторы смогут себе позволить поувольнять почти всех в поддержке первой линии. Правда есть нюанс - им не дадут доступ к технологии. Поэтому вся их деятельность по поддержке будет полностью зависеть от соответствующего провайдера умного железа. Это риск. Из-за него внедрение несколько затормозится.
Но, с другой стороны, у OpenAI есть конкуренты. Во что выльется конкурентная борьба? Пока технология несколько хуже уверенных в превосходстве человека над ИИ её есть смысл продавать. Поэтому службу поддержки всё же быстро разгонят и заменят железом. При всей медлительности года за два управятся, максимум три.
Но к этому моменту ИИ будет уже сильно умнее. Что будет тогда? Будет лишь одно ограничение - скорость масштабирования.
У современного ИИ нет психологии.
Психология появляется тогда, когда возникают желания. Нейросеть кормят входными данными и стимулами при попадании в ответ или промахе. Кроме этого там ничего нет. То есть нет места для зарождения желаний.
Аналогия - вас будят и показывают изображение. Вы натренированы на ответ с названием объекта на изображении. В момент, когда название произнесено, вас усыпляют. Не ответить нельзя, паузу перед ответом допускать нельзя. Нет времени для желаний. Машина не хочет спать, не болеет, не сожалеет, она - робот. Без чувств. Без психологии.
Вы выбрали ложное направление исследования.
Или же время для вашего исследования ещё не наступило. Пока в мире главное - сколько денег даст робот. Для этого нужна только логика. Ничего, кроме логики. Хотя да, ещё нужны данные, на которых оперирует логика. Но это тоже мёртвая сущность.
Да, в варианте от IBM ESB использует на каждый чих по WebSphere (сервер приложений). Но зато вы получаете готовую инфраструктуру, на которую стандартным образом ставятся приложения, которые так же написаны в соответствии со стандартами. Плюс графическое представление связей между очередями, с графическими редакторами для фильтров и отображений одних типов сообщений на другие.
Но никто же не заставляет использовать именно IBM. Есть много очередей, которые утверждают, что они на самом-то деле message broker. Только в каждом случае нужно смотреть, какой функционал там реально есть, и какого нет. Чаще всего много чего нет. Например в кафке есть маршрутизация и фильтрация, но на самом деле это всего лишь обработчики на Java, которые имеют доступ к топологии, которую, в свою очередь, внутри этих же обработчиков нужно писать руками. То есть формально похоже на брокер, но по факту нужно много ручных доработок.
Общий смысл такой - надо перебирать варианты. Наверное Java вам не нужна, поэтому вы наверняка исключите очереди на ней. Так что ваша специализация на Си вам должна подсказать, какие очереди для вас правильные. А среди них смотрите возможность автоматически строить цепочки обработки. Но может ничего приличного и не найдёте, всё-таки не зря IBM за много денег продаёт свою ESB и брокера.
А производительность зависит от многих факторов - выбрали опцию хранить сообщения в оракле - получите соответствующую производительность. Выберете потоковую запись на диск - производительность сильно улучшится. Но скорее всего вам и не нужна скорость в сотни тысяч сообщений в секунду, так что можно и в БД сообщения складывать.
В общем - задачу анализа вариантов я с вас не сниму.
Спасибо за подробный ответ. Его суть сводится к использованию очереди. Очередь даёт нам асинхронность, которая даёт устойчивость инфраструктуре. Я за использование очередей, но вы эту технологию использовали не имея хорошего представления об альтернативах. Альтернатива здесь известна давно - enterprise service bus (ESB).
ESB есть не просто набор очередей. Нормальный комплект включает множество адаптеров. И веб-сервисы в качестве адаптеров - самая стандартная функциональность. WSDL описывает адресацию и протокол. XSD описывает содержимое, поступающее с/на адаптер. Стандартные библиотеки на обоих концах взаимодействия дают вам именно вашу структуру в вашем представлении (не знаю, как это выглядит в Си, но обычно это классы, экземпляры которых вы получаете/отдаёте). Вызов тоже выглядит привычно для вашего ЯП (функция). Поступление данных - та же функция, но уже с вашей реализацией и описанной ранее структурой на входе. Если в какой-то части библиотеки не реализуют, например интересующий вас вариант входных функций, вы их можете легко сделать сами, или написать генератор, если функций много.
Это была часть, отвечающая за вход/выход, о которых вы много говорили. А дальше - те самые очереди. Но с маршрутизацией и какой-то обработкой вроде фильтрации/маппинга.
Основной плюс комплексного решения на основе известных стандартов - вы в основном рисуете лишь нужные вам бизнес-сущности. Всё остальное - генерируется или оборачивается стандартными библиотеками.
Другое дело, если вы не знакомы с полноценной реализацией такого взаимодействия. Полный цикл действительно реализуют не так много продуктов. Какая-нибудь Kafka реализует лишь свои собственные интерфейсы, ActiveMQ - поддерживает ряд стандартов, наверняка есть адаптеры для веб-сервисов. Но по отдельности это всё неполноценные решения, поскольку заметную часть придётся дописывать самому, особенно в случаях вроде кафки. Полноценные решения, вроде продуктов от IBM (Message Broker, который ближе к Си, или ESB, который полностью на Java), позволяют автоматически получать почти всю цепочку. Хотя в случае интеграции с Си я не знаю, какие есть варианты.
Ориентация на стандарты - ключ к такой архитектуре. Если стандартов нет, то нет и генераторов и прочих вспомогательных библиотек.
Ну и в вашем случае так же придётся писать какие-то адаптеры для вашей очереди. Хотя может быть вы нашли какую-то очередь с готовым адаптером protobuf, тут я не знаю.
Я пишу на Java, но даже в этой экосистеме сейчас сильно влияние моды, плюс ещё вопрос с санкциями. Но тем не менее, достаточно полноценные решения, где почти всё происходит автоматически, достаточно только описать нужные сущности, всё же существуют. А вот в среднем опыта разработки таких решений мало, ибо мода и каждый сам себе архитектор.
Ну и по микросервисам - хорошо, конечно, если вы ничем не ограничены по железу, сетям и т.д., но снимая сложность в разработке отдельных функций, вы перекладываете её на ту сущность, которая поддерживает взаимодействие функций. Здесь опять нужно очень много думать про правильный подход, потому что иначе в итоге вы запутаетесь, кто куда и когда что шлёт и почему получает. Описание мешанины из фильтрующих и преобразующих посредников станет невыносимым. Хотя если задача стандартная - обычный учёт каких-то бизнес-операций, то в ограничения вы не упрётесь, но только лишь потому, что сама задача примитивная - получил и сохранил, потом показал, и более ничего. Поэтому и процветают "архитектуры", которые решают несуществующие задачи, оставаясь в рамках примитивных требований.
Я не понимаю, чем обоснован выбор технологий. До очередей мы ещё не дошли.
Я же представлял - XML XSD WSDL.
Берёте любой инструмент моделирования сущностей и на выходе получаете XSD. Включаете XSD в WSDL (опять же используя массу готовых инструментов), описываете методы (вызовы) - получаете RPC, который можно интерпретировать как ООП на уровне данных. Зачем ООП на уровне вызовов - не понимаю. Собственно в Си нужно всего лишь подключить библиотеку, которая отправляет и получает соответствующий XML на/с соответствующего адреса. Всё есть уже готовое, зачем велосипед?
Не знаю, возможно в С++ эти технологии никто не использует, но весь мир работает с ними и их аналогами. Поэтому и возник вопрос - зачем свой собственный протокол? Зачем потрачены усилия на его оформление и реализацию? Эти усилия, возьми вы привычные технологии, можно было бы сэкономить. Пока не вдаёмся в остальные концепты, только выбор - запилить свой велосипед вместо взять готовый. Не верю, что в С++ нет готовых велосипедов, а это означает, что они вам не подошли и вы захотели сделать свой. Чем не подошли? Ответа нет. Чем ваш лучше? Ответа нет.
Хотя один ответ вы старательно обходите стороной - личные предпочтения. На самом деле не стоит прятать такой мотив, особенно если других не видно. Это не плохо, если кто-то согласен подождать, когда вы всё сделаете. Опыт получите, тоже хорошо. Но статья как бы намекает, что есть и другие плюсы. Вот по ним и идёт разговор.
Ну давайте сравним:
Это никак не относится к выбору протокола и форматов данных. Заменяем названия и получаем один язык.
Это никак не относится к протоколам и форматам данных.
Это никак не относится к протоколам и форматам данных.
Это относится к протоколам и форматам данных лишь в части стандартизации, которой в вашем случае меньше, значит меньше и "стандартизированных инструментов".
Это никак не относится к протоколам и форматам данных.
Это относится к протоколам и форматам данных лишь в части читабельности форматов. Вы выбрали нечитабельный бинарный формат. Вы не видите несоответствия?
Это никак не относится к протоколам и форматам данных.
Итого: либо нет никакой связи с вашим выбором, либо связь негативная.
Но есть более реалистичный намёк:
Но и здесь нет никаких проблем с приближением к ООП. Ранее предложенные альтернативы отлично отображаются на объекты, данные и методы.
А это снова противоречие. Здесь "стилистика ООП" предполагает синхронность вызова. Вы же, нарушив стилистику, сделали вызовы асинхронными.
На самом деле я люблю велосипедить. Но всё же я стараюсь понимать, что я получаю взамен отвергнутого готового решения. В вашем случае я та к и не понял - зачем? Пока вижу лишь один мотив - захотелось творить.
Логика не той системы
Не знаю, как дела обстоят для C++, но скорее всего вы потеряли возможность использовать много полезных инструментов. А что приобрели? Возможность использовать привычный инструмент сериализации? И в довесок необходимость допиливать его под такие требования, которые уже реализованы для стандартных инструментов на основе XML, но не реализованы для выбранного вами.
Пилить свою реализацию приятно, но как-то бы это обосновать посерьёзнее, нежели просто "выбрал то, что знаю, остальное дописал как вижу". Например - указать на преимущества вашего ПО в сравнении с другими подходами. Хотя здесь мы опять возвращаемся к вопросу "что приобрели".
Почитайте хотя бы минимум, для начала. Ну и потом - извинитесь перед Конан Дойлем.
Все тиали синего цвета. Есть там такое ограничение. И ваш ответ становится неправильным. По второму - А, и вы опять дали неправильный ответ.
Зачем столько детализированных описаний внутренностей программы, когда давно существуют готовые механизмы на основе XML (или JSON, если хочется модного)?
Описание классов - XSD, описание сервисов - WSDL, возможности по документированию там встроенные, протокол - HTTP, куча готовых инструментов, набор идеологий на выбор для приверженцев любых вкусов и фломастеров (вроде enterprise service bus и т.д.).
Зачем велосипед из своих кондовых описаний?