А куда посмотреть, как это настраивается? Можно ссылку?

Так это от сервера очередей зависит. Для RabbitMQ можно начать с https://www.rabbitmq.com/confirms.html , может в других иначе будет.

Так как бывает ситуация, когда клиенту-человеку надо уточняющий вопрос задать.

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

А я то думал, что в RR планировщике квант таки выделяется нитям процесса, в порядке обхода таблицы процессов, а затем планируются уже потоки

Ты думал неправильно. Планировщикам реального времени границы процессов особенно пофиг (планировщик общего назначения, при желании, может использовать знание о принадлежности нити процессам, но я не знаю ни об одном, который так делает).

И, на один процесс в системе в среднем, выделяется что-то порядка 10ms.

А как ты думал - эти 10мс общие и на нити с SCHED_OTHER, и на нити с SCHED_RR?

нить никогда не вырабатывает свой квант до конца

Об чём и речь, после этого происходит своим чередом процесс планирования

...но в этом случае квант времени на него практически не влияет.

Я так понимаю что тут главная проблема чтоб ответ пришел именно на тот воркер, который обрабатывал предыдущий ответ клиента (ну и отправил уточняющий вопрос), так?

Так это не проблема. Просто на сессию клиента давать один воркер.

тут без разницы упадет MQ или нет, потому что еще и воркер может упасть

Ну придётся заново восстанавливать контекст. Главное, чтобы при наличии контекста, повторного выполнения не происходило.

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

В 1С так сделали. Теперь 90% серверного кода выглядят так:

Функция ВыполнитьНаСервере(Параметры, Ключ)
  Кэш = ПолучитьИзВременногоХранилища(Ключ);
  Если Кэш = Неопределено Тогда
    Кэш = ПолучитьДанные();
  КонецЕсли;
  ....
  Ключ = ПоместитьВоВременноеХранилище(Кэш);
  Возврат Результат;
КонецФункции

По-моему, лучше, когда сервис держит общий контекст всегда и посессионый в кэше со слабым ключом. Чем когда этот контекст по каждому запросу заново формируется (как в HTTP/cgi-bin).

Как то быстро разговор переключился на планировщики реального времени. И тут моя вина, я почему то не держал в голове RR за планировщик реального времени, и говоря о нём, держал в голове OTHER, с которым обычно по умолчанию и пускается инит во всех дистрибутивах общего назначения.

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

Ну, тут видимо сорцы надо посмотреть(я этого не делал), ибо в голове я держал другую модель, и эмпирически она работала.

Как то быстро разговор переключился на планировщики реального времени

Ну, ты почему-то заговорил о SCHED_RR.

Ну, тут видимо сорцы надо посмотреть(я этого не делал)

Тут надо почитать POSIX. То, что когда-то называлось POSIX.4

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

CommonAPI

Если динамически, то да. И писать тогда желательно на чём-то типа MapReduce.

У меня задача попроще: чтобы при падении отдельного сервиса всё остальное не повисало до TCP таймаута. Чтобы до клиентских машин был keepalive и при отваливании соединение сбрасывалось, а не висело вечно. И чтобы отсутствие воркера можно было обнаружить, а не пытаться отправить отсутствующему сообщения. Кстати, в рамках MQ это как-то возможно или опять только через keepalive?

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

Кстати, в рамках MQ это как-то возможно или опять только через keepalive?

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

// Вышесказанное актуально для RabbitMQ, для других опять же надо смотреть документацию.

protobuf/grpc делает сообщения в несколько раз меньше, чем MessagePack

Поздравляю вас, гражданин, в лужу перднувши. Протобуф делает сообщения больше, чем MessagePack. А gRPC каждое сообщение заворачивает в HTTP/2 с десятком заголовков.

Единственный реальный плюс gRPC - стандартный IDL искаропки. В остальном одни минусы.

Касаемо того что очередь никто не слушает - это мониторится

Если в такую очередь отправить сообщение, можно от RabbitMQ добиться, чтобы он автоматом ответное сообщение слал, что служба недоступна? Или только в клиенте через таймаут+запрос к мониторингу отслеживать?

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

Но вообще очереди это про асинхронность в основном, так что это все на правах костылей.

grpc </thread>

Единственный для меня минус — в реализации на C++ очень геморный асинхронный C++ API, без кодогенерации вокруг него почти невозможно использовать удобно. Плюс: в генератор кода можно впихнуть плагин, который это всё сгенерирует.

Я тоже раньше боялся генерации кода, но потом понял, что это на порядки удобнее всех альтернатив, особенно для java/c++. Для языков с динамической/слабой типизацией, наверно, разницы с json-rpc нет, только работает быстрее и по сети меньше данных гоняет.

ZeroMQ работает в синхронном режиме. Но там свои косяки есть.

Как минимум, sandstorm.io, проект от того же человека.

result = conn.query(q).

Мне кажется, или ты сейчас процитировал основной способ организовать бессмысленный простой ресурсов сервера, который хитрые программисты используют для накопления задержек с целью оправдания необходимости борьбы с проблемами многопоточного кода?

Мне кажется, или ты сейчас процитировал основной способ организовать бессмысленный простой ресурсов сервера

А как сделать по другому, если следующей командой будет «if result.x > 0 then ... else ...»?

как сделать по другому

если следующей командой будет «if result.x > 0

Не знаю. Наверное, было бы концептуально(с) организовать для этой ifы «второй» микросервис, и уговорить «первый» отправлять ответ туда.

и уговорить «первый» отправлять ответ туда

Вот это и будет лапша из обработчиков вызовов. Читается хуже чем код с goto.

это и будет лапша

А как же это:

Идеологически хочу её сделать как пачку микросервисов

Читается хуже чем код с goto

Неправильная постановка. «Идейно» задавать вопрос: в каком(в смысле характеристик) языке такая лапша будет выглядеть вкусно? И, соответственно, писать всё в обретённом стиле.

Ясно. Я в комментариях исправился. У меня обратная задача: не выбрать язык для микросервисов, а найти какую-нибудь систему, которая позволит работать с любым языком программирования в рамках одной программы.

не выбрать язык для микросервисов

Я тоже не об этом. Я о том, какими абстракциями должны оперировать авторы компонент (в своих языках), чтобы...

На любом языке можно писать фортрановский код. Вряд ли это особенность фортрана, то же должно быть применимо и к нашему виртуальному лапшеукладчику.

найти какую-нибудь систему, которая позволит работать с любым языком программирования в рамках одной программы

Эта система называется СУБД. А обкидываться объектами между разными ЯП, то еще архитектурное решение. Тот, кто будет поддерживать этот хлам тебя точно не похвалит.

Эта система называется СУБД.

От неё и плясал. Потом понял, что кроме данных нужны ещё и типовые алгоритмы. Можно, конечно, принудительно запихнуть всё в PL/pgSQL и прочий PL/* или даже на C расширения написать, но как-то оно некрасиво получается.

А обкидываться объектами между разными ЯП, то еще архитектурное решение.

У Микрософта с COM/OLE вроде неплохо получилось. Есть MS Office и можно объекты для него писать на любом языке. И наоборот из любого языка редактировать документы.

Но хочу уточнить, может есть уже что-то более популярное.

Угу, gRPC.

/thread