[Перевод] Проблема фантомной записи: почему ваша реализация идемпотентности незаметно теряет данные

В проде бывает так, что одна и та же операция часто повторяется : клиент не дождался ответа и ретраит, балансер порвал соединение, очередь переиграла сообщение. Вспоминаем про идемпотентность - это правило «повтор не должен создавать новый платёж/заказ». Чтобы отличать повтор от новой операции, используют idempotency key (ключ идемпотентности) . Это обычная уникальная строка-идентификатор, которую клиент или апстрим отправляет вместе с запросом (часто в заголовке Idempotency-Key ). Сервис сохраняет этот ключ у себя и связывает с результатом операции. Далее приходит запрос с тем же ключом - сервис не выполняет бизнес-действие второй раз, а дедуплицирует на основе ключа идемпотентности. Но так ли всё просто? Многолетний опыт анализа инцидентов показал, что на практике большое количество систем всё же регулярно допускают дублирования, хотя делали всё по методичке. В новом переводе от команды Spring АйО рассмотрим не самые очевидные ошибки и то, о чём стоит подумать, при реализации идемпотентного API.

https://habr.com/ru/companies/spring_aio/articles/1043208/

#java #kotlin #spring #spring_boot #spring_framework #springboot #spring_data

Axelix. Cпецназ для Вашей Spring Boot экосистемы

Привет, Хабр! Меня зовут Михаил Поливаха. Я думаю, что в Хабе Spring АйО меня уже относительно знают. В рамках Spring АйО мы довольно часто занимаемся подбором технического материала и его ревью. Сам же я довольно регулярно выступаю на конференциях, контрибьючу в Open Source и т.д. Также, часто наши материалы крутятся вокруг Java разработки и конечно же Spring-а. И данной пост, хоть и будет с одной стороны сильно связан с Java и Spring Framework, но, тем не менее, не похож на остальные. На днях произошло довольно знаковое событие. Мы с небольшой командой примерно год писали инструмент, который призван существенно упростить весь процесс отладки, тестирования и мониторинга Spring Boot приложений в production. И вот этот проект наконец-то получил первый Milestone Релиз. Проект называется Axelix .

https://habr.com/ru/companies/spring_aio/articles/1041836/

#spring #spring_boot #axelix #opensource #spring_framework

[Перевод] Соль и перец в безопасности паролей

Безопасность данных сегодня стала главным приоритетом для любого веб-ресурса. Базовым стандартом защиты учетных записей является хеширование паролей. Этот процесс превращает конфиденциальные символы в необратимый код. Без него утечка базы данных мгновенно скомпрометирует пользователей. Однако обычного хеширования недостаточно из-за угрозы быстрых хакерских атак. Для защиты разработчики применяют «соль» (salt) — случайные данные, добавляемые к паролю. Минус соли в том, что она хранится рядом с хешем и не спасает от мощного перебора. Тогда на помощь приходит «перец» (pepper), скрытый в коде сервера. Его главная проблема — высокий риск потерять доступ ко всем аккаунтам при компрометации самого секретного ключа. Эта статья поможет вам разобраться в эволюции методов криптографической защиты. Вы узнаете, как правильно комбинировать эти инструменты для надежной аутентификации.

https://habr.com/ru/companies/spring_aio/articles/1038478/

#java #kotlin #hash #cryptography #spring #spring_boot #spring_framework #spring_security #security #password

[Перевод] Эволюция API без боли: ArchUnit, Gradle и правила для библиотек

В Netflix тысячи Java-репозиториев. Когда в библиотеку вносят изменение, часть пользователей может перестать собираться или начать работать некорректно. Чаще всгео эта проблема возникает потому, что public контракты являются public только для авторов библиотеки, а не для пользователей. С новом переводе от команды Spring АйО разбираемся, как ребята из Netflix ввели простые метки для API: @Public - можно использовать снаружи, @Experimental - тоже можно, но интерфейс может меняться, @Deprecated - готовится к удалению. Все остальное считается внутренним и использованию извне не подлежит. Но сами аннотации проблему не решают, нужна проверка на масштабе. Решение - ArchUnit + Nebula ArchRules. ArchUnit анализирует скомпилированный байткод, поэтому одинаково работает для Java/Kotlin/Scala и проверяет реальный код на classpath. Команды пишут правила (например: «вне пакета библиотеки нельзя зависеть от ее deprecated/internal API»), публикуют их как отдельный arch-rules JAR, а runner автоматически запускает проверки в репозиториях и делает отчеты с точной строкой нарушения.

https://habr.com/ru/companies/spring_aio/articles/1037012/

#java #kotlin #api #versioning #neflix #spring #spring_boot #spring_framework #springboot

[Перевод] Команда Spring о Spring Framework 7 и Spring Boot 4

В новом переводе от команды Spring АйО рассмотрим выход Spring Boot 4 и Spring Framework 7. InfoQ взяли интервью у core команды Spring с целью узнать, куда движется самая популярная в Java экосистема. Spring Boot 4 модуляризировал автоконфигурацию. Теперь при запуске проверяется меньше классов в classpath, а uber-jar будет более компактным: будут подключаться только нужные модули. Параллельно Spring Boot 4 переходит на Jackson 3, но добавлен модуль совместимости с Jackson 2, потому что экосистема ещё догоняет. Spring Framework 7 тащит core resilience в ядро: RetryTemplate , @Retryable и @ConcurrencyLimit доступны без отдельной зависимости. @Retryable работает и с реактивными типами (через Retry из Project Reactor); для обычных вызовов используется RetryTemplate с политикой retry/backoff. @ConcurrencyLimit помогает ограничивать доступ к ресурсу, что особенно полезно с Virtual Threads.

https://habr.com/ru/companies/spring_aio/articles/1034282/

#java #kotlin #spring #spring_boot #spring_framework #springboot #spring_data #ai #agents

Веселимся со Spring: pet-проект по распознаванию речи

Не писал на Spring уже лет 8 и решил по фану написать мини пет проект с api и распознаванием речи. Звучит круто, лет 8-10 назад это заняло бы … вечность, тогда и llm, достаточно качественно распознающих русскую речь, да еще на скромном домашнем пк не было. В общем решил в выходной повеселиться. Погнали веселиться

https://habr.com/ru/articles/1033338/

#Java #Spring_Framework #Vosk #speech_recognition #распознавание_речи #REST_API #WAV #Java_Sound_API #pet_project #веселье

[Перевод] Самый простой способ устроить утечку памяти в Java

В новом переводе от команды Spring АйО рассмотрим утечки памяти в Java. Не секрет, что GC освобождает только недостижимые объекты. Утечка в Java начинается там, где объект уже не нужен, но на него все еще есть цепочка ссылок от живого потока. Симптомы обычно одинаковые: куча растет, GC срабатывает чаще, паузы увеличиваются, финал - java.lang.OutOfMemoryError: Java heap space . В целом вывод такой, что нужно смотреть график heap в VisualVM/JVisualVM/JConsole, снимать heap dump (jmap), в Eclipse MAT запускать Leak Suspects и проверять цепочки удерживающих ссылок.

https://habr.com/ru/companies/spring_aio/articles/1022018/

#java #kotlin #performance #spring #jdk #gc #spring_boot #spring_framework #springboot

[Перевод] Раздувание памяти JDK 17 в контейнерах: разбор инцидента

В новом переводе от команды Spring АйО разберем тему раздувания памяти в JDK 17. Апгрейд микросервисов с JDK 8 на JDK 17 прошел dev и QA спокойно, но в проде через 2-3 часа все начало падать. Утилизация памяти выросла в 4 раза, контейнеры стали ловить OOMKill и перезапускаться, Uptime SLA просел, массовый инцидент. Раньше JVM использовала около 50% памяти контейнера и обслуживала ~400 потоков. После релиза стало 95-100% и 1600+ соответственно. При этом heap выглядел нормально, около Xmx, а раздувалась нативная память: ~800 MB -> 3,4-3,6 GB. Виноваты несколько эффектов, которые в контейнерах усиливаются: JVM начала создавать намного больше потоков, OS стала выделять JVM гораздо больше, а дефолтный GC в JDK 17 добавил накладные расходы. Всё это из-за простого бага в JDK, который при миграции утащил за собой весь production.

https://habr.com/ru/companies/spring_aio/articles/1019086/

#jdk_17 #jdk #java #performance #gc #kot #memory #spring #spring_boot #spring_framework

[Перевод] OpenTelemetry со Spring Boot

В новом переводе от команды Spring АйО смотрим, как подружить современный Spring Boot и OpenTelemetry так, чтобы данные уходили по OTLP в любой совместимый бэкенд. В экосистеме Spring большая часть телеметрии была завязана на Micrometer Project (Был ещё spring-cloud-sleuth если кто помнит). Но полноценного all-in-one решения для того, чтобы Spring Boot приложение просто начало экспортировать телеметрию по OTLP не было. До Spring Boot 4. На данный момент для интеграции OTel в Spring Boot приложения есть 3 пути: Java Agent (минимум кода, но чувствителен к версиям и может конфликтовать с другими агентами), сторонний OTel starter (стартер от самих OpenTelemetry, но тянет alpha-зависимости) и новый spring-boot-starter-opentelemetry , доступный в Spring Boot 4.0. Про него и будет речь.

https://habr.com/ru/companies/spring_aio/articles/1017016/

#java #kotlin #spring #opentelemetry #performance #springboot #spring_framework #spring_boot

[Перевод] Spring Data. На пути к более строгой типизации

В новом переводе от команды Spring АйО разберем, почему stringly-typed API со временем становятся хрупкими, чем помогают метамодели вроде Querydsl и JPA Criteria, и как новый механизм в Spring Data даёт более лёгкую и естественную альтернативу без лишней инфраструктуры сборки.

https://habr.com/ru/companies/spring_aio/articles/1014920/

#spring #spring_data #spring_boot #spring_framework #java #kotlin #jooq