Исправление byko3y, (текущая версия) :
Ты не понял, это не запросы, это платежи. Парсинг, конверсии, клиринг, сверка с процессингом и абс через esb, прохождения шлюзов иб, журналирование, подготовка отчетных документов. Взаимодействие с десятком внешних подсистем. И вот это все нужно делать 1000 раз в секунду. И если это по твоему низкая нагрузка, то ну я не знаю что сказать
У нас тоже CRM/документы с сохранением истории. Люди уже совсем забыли, что одно ядро процессора умеет выполнять миллиарды операций в секунду, таких ядер на сервере могут быть десятки, а это значит десятки-сотни миллиардов операций на одном компьютере. В банках до сих пор процессинг работает на коболе, который некогда исполнялся на железе по производительности где-то на уровне 8086.
далеее идет клиринг. А это уже нетривиальная задача, там нужно идти в бд, и это намного дольше чем сходить в кеш. Поэтому обязателен backpressure, иначе в клиринг нажрется сообщений, что все реплики загнутся и каюк конвеиру
Я очень сомневаюсь, что в клиринге используются сложные разветвленные потоки обработки, и backpressure прокидывается сквозь примитивный сервис конверсии, в данном случае. То есть, то, о чем я писал — корутин здесь выше крыши, никакой развитой реактивности не нужно. Под ту система, которую ты описываешь, как раз разрабатывался язык Go, который и представляет собой правильную Java, где корутины из коробки, работа в них почти не отличается от обычного синхронного кода, при этом решает те же задачи, которые решаются асинхронным и многопоточным кодом, потому что корутины могут выполняться и так, и так.
Исходная версия byko3y, :
Ты не понял, это не запросы, это платежи. Парсинг, конверсии, клиринг, сверка с процессингом и абс через esb, прохождения шлюзов иб, журналирование, подготовка отчетных документов. Взаимодействие с десятком внешних подсистем. И вот это все нужно делать 1000 раз в секунду. И если это по твоему низкая нагрузка, то ну я не знаю что сказать
У нас тоже CRM/документы с сохранением истории. Люди уже совсем забыли, что одно ядро процессора умеет выполнять миллиарды операций в секунду, таких ядер на сервере могут быть десятки, а это значит десятки-сотни миллиардов операций на одном компьютере. В банках до сих пор процессинг работает на коболе, который некогда исполнялся на железе по производительности чуть слабее Raspberry Pi.
далеее идет клиринг. А это уже нетривиальная задача, там нужно идти в бд, и это намного дольше чем сходить в кеш. Поэтому обязателен backpressure, иначе в клиринг нажрется сообщений, что все реплики загнутся и каюк конвеиру
Я очень сомневаюсь, что в клиринге используются сложные разветвленные потоки обработки, и backpressure прокидывается сквозь примитивный сервис конверсии, в данном случае. То есть, то, о чем я писал — корутин здесь выше крыши, никакой развитой реактивности не нужно. Под ту система, которую ты описываешь, как раз разрабатывался язык Go, который и представляет собой правильную Java, где корутины из коробки, работа в них почти не отличается от обычного синхронного кода, при этом решает те же задачи, которые решаются асинхронным и многопоточным кодом, потому что корутины могут выполняться и так, и так.