postgresql-embedded maintainer here.
Спасибо за статью, кто-то давно должен был написать что-то подобное, поскольку изложенная проблема актуальна долгое время, но при этом ни одной внятной статьи на данную тему я пока не видел.
Когда создавался проект postgresql-embedded, я к сожалению, не нашёл otj-pg-embedded и поэтому на коленке собрал своё решение, которое постепенно приобрело некоторую популярность. Основано оно было на библиотеке, которую использует embed.mongo, а в ней было обнаружилось немало архитектурных проблем, что в итоге сказалось на удобности API… Но история долгая, с тех пор API попричесался, а некоторые изложенные в статье проблемы на текущий момент решены.
Присоединяюсь к предыдущему комментарию — большая просьба подредактировать текст и убрать слова про «Детище Яндекса», поскольку они довольно далеки от реальности.
Хочу также слегка оправдаться за доставку артефакта из внешней сети. Данный вопрос поднимался в issues. На текщий момент это не совсем тривиально, но тем не менее довольно легко сконфигурировать с помощью PostgresDownloadConfigBuilder, который передаётся в RuntimeConfigBuilder. Там можно задать любой источник архивов, в том числе и локальный maven репозиторий.
Схема, которую мы используем, довольно универсальна и позволяет охватить широкий спектр задач. ActiveMQ даёт массу преимуществ. В частности позволяет гибко управлять конфигурацией и оперативно подстраиваться к меняющимся требованиям (например, по количеству консьюмеров). Помимо очередей мы используем JMS для обмена данными внутри кластера через топики и для транспорта файлов между нодами. Также важна и её надёжность.
С точки зрения самой технологии, мы не проводили серьёзное исследование насколько ActiveMQ лучше или хуже чем, например, Kafka. Вполне вероятно, что решение с другим брокером нам ты также подошло.
Сообщения, само собой, из очередей этого конкретного инстанса могут потеряться. В наших проектах очереди, как правило, не копятся, поэтому потери данных в случае падения минимальны, что для наших целей допустимо.
Если бы требования к целостности данных были выше можно было бы, например, сделать очереди персистентными и настроить репликацию.
Вообще, у нас несколько подходов к внедрению. В основном мы выкладываемся с использованием deb-пакетов, а сервисы стартуют как отдельный java-процесс или процесс с embedded Jetty. ActiveMQ, как правило, запускается отдельно, а вот Hazelcast мы тоже чаще всего встраиваем в сам сервис.
Мониторинги живости приложений у нас осуществляется внутренней системой, которая с заданной периодичностью осуществляет ряд проверок на живость. Например, проверяет доступность входных REST-ручек и работоспособность маршрутов, посылая в них фейковые сообщения и ожидая ответа на определённой очереди из ActiveMQ. В случае возникновения проблем, мониторинг оповещает всех заинтересованных лиц.
Мониторинг активности мы осуществляем с помощью Graphite, просто отправляем различные метрики в процессе работы туда. А в Graphite уже строим различные наглядные графики, которые выводим на большой телевизор :).
Также существует практика мониторинга очередей ActiveMQ, поскольку если они забиваются, то система утрачивает работоспособность. Это происходит, как правило, если маршруты составлены неверно, либо имеются ошибки в обработчиках сообщений.
Не хочется быть занудой и сильно офтопить, но цитата «Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live» на самом деле принадлежит не Макконелу, а John Woods либо Martin Golding.
Спасибо за статью, кто-то давно должен был написать что-то подобное, поскольку изложенная проблема актуальна долгое время, но при этом ни одной внятной статьи на данную тему я пока не видел.
Когда создавался проект postgresql-embedded, я к сожалению, не нашёл otj-pg-embedded и поэтому на коленке собрал своё решение, которое постепенно приобрело некоторую популярность. Основано оно было на библиотеке, которую использует embed.mongo, а в ней было обнаружилось немало архитектурных проблем, что в итоге сказалось на удобности API… Но история долгая, с тех пор API попричесался, а некоторые изложенные в статье проблемы на текущий момент решены.
Присоединяюсь к предыдущему комментарию — большая просьба подредактировать текст и убрать слова про «Детище Яндекса», поскольку они довольно далеки от реальности.
Хочу также слегка оправдаться за доставку артефакта из внешней сети. Данный вопрос поднимался в issues. На текщий момент это не совсем тривиально, но тем не менее довольно легко сконфигурировать с помощью PostgresDownloadConfigBuilder, который передаётся в RuntimeConfigBuilder. Там можно задать любой источник архивов, в том числе и локальный maven репозиторий.
С точки зрения самой технологии, мы не проводили серьёзное исследование насколько ActiveMQ лучше или хуже чем, например, Kafka. Вполне вероятно, что решение с другим брокером нам ты также подошло.
Если бы требования к целостности данных были выше можно было бы, например, сделать очереди персистентными и настроить репликацию.
Мониторинги живости приложений у нас осуществляется внутренней системой, которая с заданной периодичностью осуществляет ряд проверок на живость. Например, проверяет доступность входных REST-ручек и работоспособность маршрутов, посылая в них фейковые сообщения и ожидая ответа на определённой очереди из ActiveMQ. В случае возникновения проблем, мониторинг оповещает всех заинтересованных лиц.
Мониторинг активности мы осуществляем с помощью Graphite, просто отправляем различные метрики в процессе работы туда. А в Graphite уже строим различные наглядные графики, которые выводим на большой телевизор :).
Также существует практика мониторинга очередей ActiveMQ, поскольку если они забиваются, то система утрачивает работоспособность. Это происходит, как правило, если маршруты составлены неверно, либо имеются ошибки в обработчиках сообщений.