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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Описание

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

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

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

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

Привет, Хабр. Меня зовут Алексей Постригайло. Двадцать с лишним лет я занимаюсь системной интеграцией и управлением проектами, сейчас — старший партнер одного крупного ИТ-интегратора. Здесь я рассказываю о технических и организационных подробностях наших проектов. 

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

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

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

Недавно я внедрил blue‑green деплой в проде. Реализация довольно простая и кастомная, но справляется со своей задачей на ура! Также сообщу, что используется обычный докер композ на виртуалке — возможно, кому‑то такой подход будет полезен.

Для фоновых процессов (воркеров)

В приложение добавляется специальный инфрастуктурный singleton класс с флагом is_accepting, и обертка на consumers. В каждом консьюмере перед обработкой проверяем этот флаг: если True — обрабатываем задачу, если False — переносим задачу на повторную обработку (например, в rabbitmq делаем сразу nack(requeue=true))

Альтман выиграл пари. Я строю фабрику, чтобы выиграть следующее

Антон Саркисян, CCO GPTunneL | ex.Yandex | ex.VK |

Интеграционные тесты зелёные, а после деплоя внезапно «пустые списки» и null в критичных полях — типичный сценарий для микросервисов. В этой статье разберём, как контрактное тестирование с Pact на Kotlin позволяет ловить такие расхождения заранее: от написания первого контракта до его проверки в CI/CD. На практике посмотрим, где подход даёт реальную пользу и какие ошибки чаще всего обесценивают тесты.

Привет Хабр! В данной статье хотел бы рассказать о том как я создал свой первый проект на десятки тысяч строк, о том как я горбатился над ним, с какими проблемами я столкнулся и как я их решил.

«— А трактор случайно не в залоге?» — с такого вопроса обычно и начинался рабочий день сотрудников департамента залогового обеспечения в нашем банке. За ним стоит однотипная рутина, на которую раньше уходила большая часть времени: открыть Реестр уведомлений о залоге движимого имущества, ввести данные клиента, подождать результат, проанализировать, принять решение — и так по каждому.

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

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

В этой статье расскажу, как мы подружили банк с ФЦИИТ, с какими трудностями столкнулись и что из этого вышло.

Материал будет полезен системным и бизнес-аналитикам, которые только начинают проектировать интеграции с внешними системами.

Прежде чем погружаться в архитектуру, давайте посмотрим на контекст, в котором всё это происходит.

По данным исследования McKinsey 2022 года, технический долг составляет до 40% всего технологического портфеля компаний. И это не просто цифра в отчёте. Согласно опросу 2024 года среди технических руководителей, у более чем 50% компаний технический долг занимает свыше четверти всего IT-бюджета, блокируя внедрение новых функций. (Источник: vFunction, 2025)

При этом исследование Carnegie Mellon выяснило, что наибольшим источником технического долга являются именно архитектурные проблемы — а не баги и не плохой код на уровне функций.

Теперь о Go. По данным Go Developer Survey 2024, главной проблемой команд, работающих с Go, названо поддержание единых стандартов кода — в том числе из-за разного уровня опыта участников и привнесения не-идиоматических паттернов из других языков. (Источник: go.dev/blog/survey2024-h2-results)

Это напрямую про нашу тему: люди приходят из Java, Python, C# и приносят с собой архитектурные привычки, которые в Go не работают. Clean Architecture и DDD — не исключение. Их часто реализуют "как в Java", а потом жалуются, что Go — многословный и неудобный язык.

Давайте разберёмся, как делать это правильно.

Как мы сюда попали?

Представьте: вы начинаете новый Go‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру:

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами.

Лучше один раз разобраться, чем каждый раз сомневаться в выборе.

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

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

В распределенной системе понять, что именно произошло во время выполнения запроса, бывает сложнее, чем исправить саму ошибку. Логи показывают события по отдельности, метрики — общую динамику, но без связки между ними картина остается фрагментарной. Мы решили выстроить наблюдаемость на базе OpenTelemetry и использовать Sentry для анализа трейсов.

Микросервисная архитектура решает проблему масштабируемости, но почти всегда создает новую — потерю прозрачности. Один пользовательский запрос может пройти через десяток сервисов, очереди, сторонние API и фоновые процессы. Если где-то возникает ошибка, найти ее источник без полноценной трассировки — задача на часы, а иногда и на дни.

Чтобы избежать этого, мы выстраиваем связку OpenTelemetry + Sentry. OpenTelemetry позволяет стандартизировать сбор телеметрии, а Sentry — централизовать ее анализ. В результате появляется целостная картина работы системы.

Введение в OpenTelemetry: traces, metrics, logs

OpenTelemetry объединяет три типа телеметрии — логи, метрики и трейсы — и задает для них спецификации.

Трассировки. Трейс показывает, как выполнялся конкретный пользовательский запрос. Запрос разбивается на шаги, каждый шаг в терминологии трассировки называется span, они фиксируются с указанием времени начала и окончания. В итоге можно увидеть не просто факт ошибки, а последовательность действий, которая к ней привела.

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