Очень интересное, и главное простое решение. Если добавить extension timescaledb, то нет необходимости в управлении партициями. Плюс из коробки добавляются плюшки связанные с агрегациец данных и автоматически обновляемые materialized views
А в чём, собственно проблема? Запускается N монолитов и на стороне баласировщика выставляются правила. И не нужно беспокоиться, где какой сервис бежит.
Описание проблем монолита показывают просто очень плохое понимание архитектуры. Можно два монолита параллельно на двух машинах запустить и обновления могут быть абсолютно без даутайма.
GPS нужна для чернового подхода. Когда ракета в пределах десятка метров от башни, башня может сканировать ракету в реальном времени и взять управление на себя, а там точность может быть миллиметры, в зависимости от системы и количества сенсоров.
Может где-то и есть руководство, но вменяемого я не нашёл. Как заточить такой сервис на облаке и дать возможность тысячам пользователей параллельно генерить картинки используя различные модели или LoRa. И желательно платить только за время, пока генерация картинок идёт. Если кто знает, пожалуйста напишите в комментариях или в личку. Спасибо
Переизобрели велосипед. Раньше возвращали репрезентацию в XMLe и сделав XSLT трансформацию рисовали UI. Теперь XML заменили JSONом, а XSLT какой-то другой библиотекой.
Очень интересное, и главное простое решение. Если добавить extension timescaledb, то нет необходимости в управлении партициями. Плюс из коробки добавляются плюшки связанные с агрегациец данных и автоматически обновляемые materialized views
Ни о чём
А в чём, собственно проблема? Запускается N монолитов и на стороне баласировщика выставляются правила. И не нужно беспокоиться, где какой сервис бежит.
Описание проблем монолита показывают просто очень плохое понимание архитектуры. Можно два монолита параллельно на двух машинах запустить и обновления могут быть абсолютно без даутайма.
GPS нужна для чернового подхода. Когда ракета в пределах десятка метров от башни, башня может сканировать ракету в реальном времени и взять управление на себя, а там точность может быть миллиметры, в зависимости от системы и количества сенсоров.
Так и не получилось заточить Swagger без спринг бута. Такое впечатление, что на буте весь мир клином сошёлся
Спасибо, очень полезная статья.
У меня Prusa с цветом. Не работает без бубнов, от сова совсем. Вернул одиночный цвет. Работает, как часы
Так и JSP компилится в байткод, который тоже JIT. Там просто 2 шага
1. JSP to Java
2. Java to bytecode
Уже было и прошло. JSP это и есть PHP
Спасибо. Отличная статья с понятными описаниями плюсов и минусов решений. С нетерпением жду следующей части.
Не сказал бы, что Graalvm заброшен
В большинстве случаев необходимо получить ответ в специфическом формате, например в JSON.
А ещё можно добавить systemd сервис и тогда, при рестарте системы, не придётся руками поднимать приложение
Последняя версия на сайте 23.0.3
Всё это уже есть. Вопрос в том, как создать и держатьна облаке предзагруженные модели и не платить за десятки машин, которые нужно поддерживать
Было бы очень интересно понять, как такое сделать
Может где-то и есть руководство, но вменяемого я не нашёл. Как заточить такой сервис на облаке и дать возможность тысячам пользователей параллельно генерить картинки используя различные модели или LoRa. И желательно платить только за время, пока генерация картинок идёт. Если кто знает, пожалуйста напишите в комментариях или в личку. Спасибо
Как раз на прошлой неделе генерили код под Java из OpenAPI. Он даже не компилировался.
Переизобрели велосипед. Раньше возвращали репрезентацию в XMLe и сделав XSLT трансформацию рисовали UI. Теперь XML заменили JSONом, а XSLT какой-то другой библиотекой.