Микросервисы *

Почему добавление второго consumer«а в очередь может привести к двойным списаниям? Разбираем на реальном кейсе: как один Topic стоил компании 312 дублей за час. »

Сравниваем поведение JMS, Kafka и RabbitMQ, показываем, почему ни одна очередь не даёт exactly‑once из коробки, и как идемпотентность, Dead Letter Queue и правильный выбор канала (команды vs события) делают интеграции надёжными.“

Готовые схемы, продакшен‑код на Java и чек‑лист, который стоит применить прямо сейчас!

В рамках задачи по обработке XBRL-таксономий возникло требование: если таксономия удалена до обработки событий расчёта кэша, эти события не должны приводить к созданию данных для уже неактуальной сущности.

На первый взгляд кажется, что достаточно найти соответствующие сообщения и удалить их из Kafka topic. Но Kafka хранит данные как commit log, поэтому точечное удаление сообщений по версии таксономии или другому бизнес-признаку оказывается небезопасным.

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

Эта статья совсем не технический анализ, а увлекательный рассказ о том, как маленький, но очень перспективный стартап стал топовым приложением, а также о том, какие сложности встали на пути команды разработки, DevOps и тестирования X5 Tech.

Мы сразу заложили основные принципы нагруженного приложения: микросервисы как основа всего, полное покрытие метриками, асинхронность, кэширование на максималках. Какую-то функциональность разрабатывали сами, где-то задействовали сервисы других техкоманд из X5, а где-то и сторонние решения с рынка.

Весь код писали на Python, использовали FastAPI и другие популярные на тот момент фреймворки и технологии.

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт. 

Больше двадцати лет моя команда занимается обменом данными между корпоративными системами. Все эти годы интеграция оставалась скучной технической прослойкой, которую в бюджетах по привычке записывали в строку «поддержка». В 2026 году ситуация изменилась, и не потому, что шины вдруг стали красивее или модными, а потому, что ИИ‑проекты начали массово застревать именно в интеграционном слое. В этой статье разберу, почему так происходит, какие архитектурные подходы ломаются первыми на ИИ‑нагрузке и что мы в Диасофт выбрали в качестве рабочего варианта. Будет кейс крупного банка, три грани, на которых интеграция включает или выключает всю ИИ‑стратегию, и честный ответ, когда интеграционная платформа вам не нужна.

Главный тормоз корпоративных ИИ‑проектов в 2026 году это не выбор модели, не мощности GPU и не цена за токены. Это банальный обмен данными между корпоративными системами. В апрельском исследовании Integrate.io 95% ИТ‑директоров назвали проблемы интеграции главным барьером внедрения ИИ. Отчет Anthropic State of AI Agents 2026 фиксирует ту же картину с другого угла: среди инженеров, которые уже строят агентные системы на продакшене, 46% называют интеграцию с существующими корпоративными системами главным техническим вызовом — она обошла и вопросы безопасности, и надежность самих моделей.

Микрофреймворк для параллельного обучения AI-агентов в средах Gymnasium с графическим интерфейсом на wxPython. Решает классическую проблему «зависшего GUI» при длительном обучении нейросетей: вычисления вынесены в отдельные процессы-сервисы, а интерфейс остаётся полностью отзывчивым. Поддерживает плагинную систему для добавления новых сред, визуализацию прогресса (графики Matplotlib), генетический алгоритм обучения (нейроэволюцию через DEAP) и сборку в один .exe через PyInstaller с автоматическим CI/CD.

Привет, Хабр! Я Эдуард, в команде РСХБ.Цифра занимаюсь организацией проведения нагрузочного тестирования. В нашей команде инженеры НТ занимаются проверкой производительности как монолитных, так и микросервисных решений. Одно из больших направлений — это мобильное приложение «Свои финансы» от РСХБ. В этой статье расскажу о том, как мы проводим нагрузочное тестирование UI‑микросервисов и поделюсь ценными выводами на тему.

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

Как соединить LLM-агента на AG2 с Dishka в одном DI-контейнере. На рабочем примере: FastAPI + SSE-стрим по AG-UI + Postgres, тулзы с типизированным внедрением сценариев, отдельная транзакция на каждый tool call. Плюс грабли при сборке.

Я работаю в большой продуктовой компании с тысячей микросервисов. В такой системе даже небольшая фича часто проходит через несколько сервисов, событий и внутренних контрактов. Spec-driven development с LLM уже применяется в некоторых командах для планирования и ревью фич, поэтому мне было важно понять, где этот подход помогает, а где начинает ошибаться. Пока задача живёт внутри одного сервиса, всё обычно идёт быстро: спека короткая, описание и реализация помещаются в контекст модели. Но как только фича проходит через несколько сервисов, начинаются проблемы. По отдельности каждый кусок выглядит нормально: разбиение на слои, именование по код стайлу, прохождение тестов и ревью. Но в целом система не работает должным образом. Типичные ошибки: нет идемпотентности, LLM упускает сценарии и edge case-ы, появляются циклические вызовы сервисов. Чем больше делаешь правок, тем больше ошибок она допускает.

Для эксперимента я собрал отдельный стенд: Go-проект - платформа для поиска фрилансеров. Внутри 12 микросервисов, связанных через gRPC и брокер сообщений; в этом проекте брокером выступает NATS. Одни сервисы хранят задачи и профили исполнителей, другие подбирают кандидатов, считают расстояния, проверяют портфолио и отправляют уведомления. Проект специально спроектирован с шестью категориями архитектурных ловушек: они проявляются не внутри одного сервиса, а на границах между сервисами.

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

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

На это можно ответить, что нужен end-to-end тест на весь сценарий, но это не закрывает проблему целиком. End-to-end тесты есть не везде, их дорого поддерживать, и они не покрывают все развилки: особенно редкие edge case-ы, дубликаты событий, гонки и редкие комбинации условий. Главное же в другом: на этапе spec-driven разработки модель должна помочь собрать требования, ограничения и контекст, а именно там она часто ошибается.

Разработчик тоже не всегда заранее знает, где спрятана проблема. Он может помнить про Outbox, дедупликацию уведомлений или особые требования конкретного сервиса к входным данным, но не сформулировать это как ограничение для новой фичи. LLM читает документы по сервисам, задаёт уточняющие вопросы и всё равно может пропустить связь между ними.

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

gRPC кажется простым только до первого реального проекта. В этой статье - практические решения для типичных подводных камней: nullable, decimal, DateTime, наследование, дженерики и enum. Всё на основе реального опыта переноса сотни моделей с REST и WCF на gRPC. Обновлено под protoc v34.1 и dotnet 10.

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

В софте всё обычно иначе. Распределённый пользовательский путь — например, оформление заказа — собирается из десятков микросервисов, баз и очередей. Разработчики добавляют новую зависимость, видят зелёные тесты, проверяют локальные метрики и выкатывают релиз. Считается, что если при сбое что-то пойдёт не так, настроенная система наблюдаемости обязательно это покажет.

Она, конечно, покажет. Но почему при проектировании микросервисов мы так спокойно относимся к тому, что узнаём о хрупкости архитектуры в основном по факту инцидента?

Эта статья о том, как получить грубый расчёт деградации системы ещё до релиза. Без отказа от хаос-инжиниринга или мониторинга, а как шаг перед ними. Я расскажу о двух экспериментах, в которых топологическая модель автоматически извлекалась из распределённых трейсов, после чего на ней просчитывались сценарии отказов методом Монте-Карло. Результаты моделирования я затем сравнивал с реальными инъекциями отказов на стендах DeathStarBench и OpenTelemetry Demo.

Асинхронная клиент-серверная библиотека для обмена сообщениями между микросервисами на базе ZeroMQ. Реализует гарантированную доставку сообщений (At-Least-Once) с персистентной файловой очередью при обрывах связи, автоматический failover сервера переадресации (клиенты могут подхватывать роль сервера на лету) и два уровня защиты: шифрование канала (CurveZMQ) и сквозное шифрование сообщений (HMAC). Лёгкая альтернатива брокерам вроде RabbitMQ, не требующая отдельного сервера.

Событийно-ориентированная архитектура часто выглядит как аккуратная схема с брокером, сервисами и красивыми стрелками между ними. В продакшене всё прозаичнее: события теряются, дублируются, приходят не по порядку, а контракты внезапно становятся долгоживущим API, который уже нельзя просто взять и переписать.

В статье разбираем, как EDA ведёт себя в облачном банкинге: где она действительно помогает развязать системы и упростить аудит, а где добавляет новую сложность — от outbox/inbox и идемпотентности до границ доменных и интеграционных событий.

Я Михаил — создатель и главный разработчик системы вэб приложений. Второй участник проекта — Владимир — разработчик мобильных версий и ответственный за SEO оптимизацию.

Наш путь активной работы с очередями RabbitMQ начался с классического Celery. Осознав критичность низкоуровневого контроля системы, принялись работать с aio-pika. Но и этот уровень слишком местами сложный (далее расскажу почему), и нашли отличное решение, на текущий момент, в лице FastStream. Сразу оставлю такую пометку, что каждый инструмент подходит для решения своей задачи. Мы больше хотели сделать акцент на удобство и скорость разработки относительно затрачиваемого времени на миграции решений.

N.B.: Код возможно покажется неоптимальным или старым. Это всё наш дорогой Легаси.

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

В статье рассмотрим, почему эволюционная архитектура и модульный монолит превосходят современные архитектурные подходы. Обсудим, в каких случаях стоит отказаться от микросервисов, как документировать архитектурные решения с помощью ADR и какие методы помогают спасать проекты.

Есть такой опасный момент в инфраструктуре: когда все вроде бы работает, но трогать это лишний раз не хочется. Не потому что идеально. А потому что есть ощущение — если полезешь, станет хуже. В какой-то момент мы поймали себя на этом с MinIO.

Представьте: production, 3 часа ночи, пользователи жалуются на ошибки. Вы открываете логи и видите...

Привет, Хабр! Я — Руслан, а это — моя статья написанная в основном по следам моего доклада про будущее ИТ, ИТ-архитектуры и работы айтишников + часть мыслей дооформилась после участия в подкасте (все ссылки в конце).

Если предыдущие мои доклады и статьи были максимально ориентированы на практику — гранулярность микросервисов, каскадное снижение связанности, проектирование отказоустойчивости, покрытие архитектуры тестами — то здесь я сознательно отхожу в сторону и попробую пофантазировать и порассуждать о дальнем горизонте, а также построить стратегию и дать советы всем нам, что делать в наступающей эпохе ИИ.

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

Но закончим с лирикой. Говоря о будущем ИТ, начнём, пожалуй, с ИТ-архитектуры — как дисциплины, описывающей базовые построения любого ПО.

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

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