Java *

Продолжаем серию «Kotlin для новичков». Сегодня разбираем фундамент, без которого не обходится ни одно приложение: строки и коллекции. Как правильно резать подстроки, форматировать JSON, чем List отличается от MutableList и зачем enum в Kotlin круче, чем в Java. Заглядывайте, будет полезно!

Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом.

Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.

 Описание

Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах.

В чем его суть. Представим сервис А, который обращается к сервису Б. Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми.

Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure).

Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
 

Один экран в приложении, а на бэкенде несколько REST-вызовов, куча эндпоинтов и ответы, где 90% полей не используются. Теряем в скорости, усложняется фронтенд и приходится версионировать контракт, когда меняется формат данных.

GraphQL предлагает другой подход: один API-эндпоинт и запрос, в котором клиент сам указывает, какие поля ему нужны. Это снижает overfetching, уменьшает количество сетевых затрат и упрощает договоренности между фронтом и бэком за счет схемы как явного контракта и живой документации.

В новом переводе от команды Spring АйО разберем, где GraphQL реально помогает: как уйти от разрастания эндпоинтов, как держать контракт синхронизированным и что делать с типичными проблемами производительности и наблюдаемости, когда данные собираются из разных источников.

«Talk is cheap. Show me the code.»

Недавно мне в руки попала книга «Искусство неизменяемой архитектуры: теория и практика управления данными в распределенных системах». В ней описаны довольно радикальные, но логичные подходы к проектированию: полный отказ от UPDATE и DELETE в пользу INSERT, идентификация сущностей через хеш-суммы и построение распределенных систем без боли.

Чтобы не быть голословным и проверить, работают ли эти концепции в реальном коде, а не только в теории, я написал небольшой тестовый проект. Это не продакшен-решение, а скорее полигон для проверки идей.

В этой статье разберем, как выглядит REST-сервис на Kotlin + Spring Boot, живущий по законам неизменяемости, и к каким результатам это привело.

Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Александр Ланцов — ведущий разработчик Мир Plat.Form. Если вы больше любите смотреть видео, то смотрите запись доклада на YouTube или VK Видео.

Всем привет! Меня зовут Евгений Оселедец, я ведущий разработчик в компании Axenix. В этой статье расскажу, как мы упаковали React и Java в единое автономное desktop-приложение с помощью Electron для Windows, Linux и macOS — без Docker, без предустановленной Java у пользователя и без необходимости интернет-соединения. Расскажу, с какими техническими вызовами мы столкнулись и какие решения сработали на практике.

Привет, Хабр! Я Юрий Дергач, я возглавляю ЦК DevOps и релизного управления в РСХБ. Мы с командой развиваем инфраструктуру и автоматизируем разработку продуктов компании. При внедрении наших проектов группы «Экосистема Свое», основанных на стеке Java Spring, в Kubernetes, возникли вопросы, связанные с различными методами балансировки нагрузки между микросервисами.

В этой статье мы обсудим два основных подхода к балансировке нагрузки между Backend-компонентами приложений на стеке Java Spring Cloud в Kubernetes. Мы также рассмотрим преимущества и недостатки каждого метода.

Вы слышали о Kafka, MQTT, S3, Iceberg, Trino, PostgreSQL, Redis и Flink? А насколько хорошо вы знаете эти технологии? По каждой из них написаны огромные книги («Kafka: The Definitive Guide», около 800 страниц), и каждый день выходят новые публикации про тонкости.

Эта статья про другое.

Вместо внутренностей движков и законов распределённых систем посмотрим на эти технологии как на кубики LEGO: какую роль каждая из них играет в архитектуре и как они стыкуются друг с другом. Это будет практический туториал: начнём с минимальной конфигурации и постепенно соберём сложную систему. Статью можно просто читать как обзор архитектуры, а можно запускать каждую конфигурацию и изучать её в деталях. Для этого достаточно Git, Git LFS и Docker Compose. Всё запускается в контейнерах. Даже примеры на Java собираются через Docker multi-stage build.

Привет Хабр! Меня зовут Артур Валиев, и я разработчик небольшого мобильного приложения с названием «Echo Layer».

Меня давно не отпускала одна мысль: почти все разговоры о приватной переписке в какой‑то момент упираются не в шифрование, не в криптографию, не в архитектуру, а в банальную человеческую инерцию. Можно сколько угодно строить красивую систему, можно делать open source, end‑to‑end encryption, писать про zero knowledge и отсутствие серверных логов, но потом ты возвращаешься в реальную жизнь и видишь, что люди всё равно сидят там, где им удобно. В Telegram, в WhatsApp, в VK, сейчас уже и MAX, в корпоративных чатах, в почте, в комментариях, где угодно. И если для приватности нужно сначала всех пересадить в новое приложение, то задача почти обречена.

Именно в этот момент у меня и сместился фокус. Я перестал думать о мессенджере как о конечном продукте. Мне стало интереснее другое: а можно ли не строить новый канал связи, а встроить приватный слой поверх уже существующих каналов? Не просить человека менять привычки, не ломать его сценарий общения, не заставлять его уговаривать собеседника «перейти вот сюда», а аккуратно встать между пользователем и текстом. Потому что, если честно, в большинстве случаев мессенджер — это просто оболочка. Внутри всё равно есть текст, который пользователь написал, и текст, который приложение потом отправило. Значит, если контролировать текст до отправки, можно контролировать довольно много.

Так Echo Layer и появился. Не как «новый безопасный чат», а как попытка превратить сам ввод текста в место, где может жить приватность.

За годы работы сначала разработчиком, а потом автоматизатором сталкивался с необходимостью запускать тесты параллельно. Действовал в основном интуитивно и шёл строго по документации. Недавно закралась мысль поставить серию экспериментов и посмотреть фактам в глаза. Результаты оказались предсказуемые, но тем не менее интересными.

Эта статья для тех, кто делает первые шаги в распараллеливании тестов на Java. Будет полезна как автотестерам, так и начинающим разработчикам.

Будем анализировать выводы полученные в ходе эксперимента, а не голую теорию из документации. После прочтения сможете повторить все самостоятельно как на готовом примере из статьи, так и на своих проектах.

Всем привет! Меня зовут Михаил, я главный эксперт в ОТП Банке.

Думаю, многие из вас сталкивались с легаси, которое нужно дорабатывать и оптимизировать. Сегодня хочу поделиться реальным кейсом как мы ускорили отправку данных в смежную систему.

Разберем всё по шагам, с замерами производительности. Поехали!

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.

Причина миграции — импортозамещение.

Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям.

Ключевое нефункциональное требование — выполнить миграцию без простоя системы и без заметного влияния на пользователей.

Может возникнуть логичный вопрос: если такие миграции уже делались не раз, почему просто не взять готовое решение? На практике универсального подхода не существует.

Где‑то допустим простой на несколько часов, где‑то — нет. В одних системах хватает простого переноса, в других приходится использовать сложные стратегии вроде двойной записи. Многие статьи подробно разбирают инструменты, но их применение в конкретном проекте — это отдельная инженерная задача. К тому же у каждой системы есть свои ограничения и нюансы. Поэтому дальше я разберу конкретный кейс и те решения, которые были приняли по ходу миграции.

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

Всем привет! Меня зовут Александр, и сегодня я расскажу о результатах перевода учебного проекта со Spring WebFlux и Netty на Spring MVC и Tomcat с виртуальными потоками и проверки обоих вариантов под нагрузкой в 2000rps. В качестве подопытного будет выступать система микросервисов, разработанная в рамках курса CloudJava.

Привет, Хабр!

Почему инженеры хотят делать новое, а неделя уходит на сопровождение, алерты и переключение контекстов? Поводом для этой статьи стали два материала, которые неожиданно сошлись в одной точке: доклад Романа Елизарова про опыт разработчика и отчет Chainguard Engineering Reality Report 2026. Мы сопоставили взгляд сильного практика и международные данные, чтобы понять, куда на самом деле утекает внимание инженерных команд и почему DX сегодня — это уже не про удобство, а про экономику внимания.

GitHub, GitLab или Bitbucket — куда податься начинающему разработчику в 2026? Казалось бы, какая разница — Git везде одинаковый. Но когда дело доходит до первого пет-проекта, портфолио или стартапа на троих, выбор платформы решает всё: от скорости сборки до шансов быть замеченным рекрутером.

В этой статье — сравнение лимитов, цен и скрытых фич. Разберём реальные сценарии, таблицу с актуальными данными на апрель 2026.

Сегодня LLM — модный инструмент, завтра — обязательный компонент инфраструктуры. Мы разберём, какие уязвимости у языковых моделей есть уже сейчас, почему вокруг guardrails формируется целый стек технологий и как разработчикам влиться в эту волну, пока она только набирает высоту

Что делать, если синхронные REST-вызовы превращают ваши микросервисы в карточный домик? Пора вспомнить проверенные временем паттерны обмена сообщениями. В этой статье разбираем архитектуру Pipes and Filters, Content-Based Router и Idempotent Receiver — те самые кирпичики, на которых держатся надёжные системы. Схемы, best practices для проектирования устойчивых интеграций для Enterprise-разработки.

Вот уже 18 лет статический анализатор кода PVS-Studio находится на рынке. За это время он обзавёлся поддержкой языков C, C++, C# и Java. Разумеется, останавливаться на этих языках мы не планируем, и в этой статье расскажем про разработку нового JavaScript/TypeScript анализатора, который выйдет уже совсем скоро.