Ну, например, есть 100500 адресов, которые нужно провалидировать. Есть кластер из 10 машин, которым нужно очень быстро разбросать адреса, без повторения. Можно и через Rabbit, но если уже есть Кафка, то почему не использовать её, чтобы не плодить инфраструктуру.
Очень интересное, и главное простое решение. Если добавить extension timescaledb, то нет необходимости в управлении партициями. Плюс из коробки добавляются плюшки связанные с агрегациец данных и автоматически обновляемые materialized views
А в чём, собственно проблема? Запускается N монолитов и на стороне баласировщика выставляются правила. И не нужно беспокоиться, где какой сервис бежит.
Описание проблем монолита показывают просто очень плохое понимание архитектуры. Можно два монолита параллельно на двух машинах запустить и обновления могут быть абсолютно без даутайма.
GPS нужна для чернового подхода. Когда ракета в пределах десятка метров от башни, башня может сканировать ракету в реальном времени и взять управление на себя, а там точность может быть миллиметры, в зависимости от системы и количества сенсоров.
Наконец-то можно и на православной Jave ИИ пользоваться. Ждём Vector API.
Мы пользуемся langchain4j
И какое решение есть для 3,000,000?
Ну, например, есть 100500 адресов, которые нужно провалидировать. Есть кластер из 10 машин, которым нужно очень быстро разбросать адреса, без повторения. Можно и через Rabbit, но если уже есть Кафка, то почему не использовать её, чтобы не плодить инфраструктуру.
JMS (Artemis, RabbitMQ, etc.) предоставляет очереди из которых читают подписчики и каждое сообщение обрабатывается только одним подписчиком.
Pub-sub это здорово, но что делать, если событие должно обрабатываться только один раз, а нод в кластере много. Как Кафка работает с очередями?
Тут вопрос в том, что более эффективно - создать новый процесс и обработать быстро, или обработать в том же потоке но чуть медленнее
А почему возможности Java для трансформации картинок не используются?
Очень интересное, и главное простое решение. Если добавить extension timescaledb, то нет необходимости в управлении партициями. Плюс из коробки добавляются плюшки связанные с агрегациец данных и автоматически обновляемые materialized views
Ни о чём
А в чём, собственно проблема? Запускается N монолитов и на стороне баласировщика выставляются правила. И не нужно беспокоиться, где какой сервис бежит.
Описание проблем монолита показывают просто очень плохое понимание архитектуры. Можно два монолита параллельно на двух машинах запустить и обновления могут быть абсолютно без даутайма.
GPS нужна для чернового подхода. Когда ракета в пределах десятка метров от башни, башня может сканировать ракету в реальном времени и взять управление на себя, а там точность может быть миллиметры, в зависимости от системы и количества сенсоров.
Так и не получилось заточить Swagger без спринг бута. Такое впечатление, что на буте весь мир клином сошёлся
Спасибо, очень полезная статья.
У меня Prusa с цветом. Не работает без бубнов, от сова совсем. Вернул одиночный цвет. Работает, как часы
Так и JSP компилится в байткод, который тоже JIT. Там просто 2 шага
1. JSP to Java
2. Java to bytecode
Уже было и прошло. JSP это и есть PHP
Спасибо. Отличная статья с понятными описаниями плюсов и минусов решений. С нетерпением жду следующей части.
Не сказал бы, что Graalvm заброшен