Всем привет! В этой статье я бы хотел затронуть тему горизонтального масштабирования SpringBoot-приложений, использующих вебсокеты. Основная особенность таких приложений - наличие состояния (state). Вебсокеты для работы используют постоянное TCP-соединение, собственно оно и является этим состоянием. А наличие состояния обычно вызывает проблемы при масштабировании. 

Stateless-сервисам все равно на какой из множества инстансов попал очередной запрос, или кто именно вычитал сообщение из очереди. Но когда на серверной стороне возникает понятие клиентской сессии, все запросы, связанные с этим клиентом, должен обрабатывать один и тот же инстанс. Либо должна быть возможность передать эту сессию на другой инстанс. Сложность реализации этого требования варьируется от "добавить одну строчку в конфиг балансировщика" до "написать подсистему мониторинга топологии сервиса и роутинга запросов, сложность которой может превышать сложность основного приложения". К счастью, для решения стандартных задач, как правило, существуют стандартные инструменты. Давайте посмотрим, что за инструменты используются при масштабировании вебсокетных приложений, написанных на SpringBoot.

Привет! Все приложения что-то делают с данными. Некоторые преобразовывают их из одного формата в другой и счастливо про них забывают. Другим повезло меньше, и им приходится эти данные где-то хранить, чтобы обратиться к ним позже. Или чтобы другое приложение могло обратиться к ним позже. И самым распространенным способом для хранения до сих пор являются реляционные базы данных.

А еще для приложений пишут тесты, чтобы проверить корректность их работы. И когда возникает необходимость протестировать работу приложения с БД, то выясняется, что здесь могут быть свои тонкости. За подробностями добро пожаловать под кат.

Привет! Когда-то обновление версии сервиса было сложной задачей. Нужно было последовательно выполнить ряд действий, перезапустить инстансы, и не забыть предварительно забэкапить наши данные. Пользователям сервиса показывалось предупреждение, что сервис временно недоступен, и куча усилий тратилась на то, чтобы максимально снизить время этой недоступности.

Сейчас же у нас есть супер-мощные инструменты для управления сервисами. Они позволяют иметь несколько разных версий сервиса одновременно. Бизнес-пользователи могут управлять тем, какую версию видит та или иная группа пользователей. Обновление и откат версии сервиса могут происходить без прерывания работы пользователей. И когда появился такой мощный и красивый молоток, все начали хотеть забивать гвозди только им. Даже те, кому это, на самом-то деле, вообще не нужно. И тут есть проблема - наличие инструмента не означает автоматической готовности сервисов для того, чтобы этот инструмент с ними можно было использовать. И если обновлять сервисы старым способом было сложно, то новым это делать еще сложнее. Давайте посмотрим, почему это так, и как вообще получить этот ваш Zero Downtime.

Привет! В этой статье я бы хотел рассказать, как Spring'овая аннотация @Transactional ведет себя при возникновении исключений. Про это немало написано, в том числе на Хабре. Например, тут или тут. Поэтому, чтобы не повторяться, я не буду подробно расписывать как и почему исключения влияют на откат транзакций, а вместо этого просто покажу несколько примеров.

Всем привет! Есть достаточно распространенная задача: нужно вставить новую запись в БД, но если она уже там есть, то её следует обновить. Эта ситуация может встретиться, например, если у вас есть 2 источника данных, каждый из которых передает половину информации об объекте, и ваш сервис должен склеить части вместе по какому‑то внешнему идентификатору. Но вы не знаете, в каком порядке к вам попадут эти половинки. Предлагаю посмотреть, как это можно сделать, если сервис использует Spring Data JPA.

Про то, как поднять контейнер Nginx и настроить для него автообновление сертификатов LetsEncrypt, есть довольно много статей. В этой будет описана довольно нестандартная схема. Основные моменты:

1. Nginx разворачивается как сервис в Docker Swarm, а не как standalone-контейнер;
2. Для проверки используется схема DNS-01, а не гораздо более популярная HTTP-01;
3. Для DNS-провайдера GoDaddy в настоящий момент нет DNS-plugin'а для certbot'а, но есть API по управлению доменными записями.