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

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

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

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

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

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

Подключили к своему ИИ-агенту в VS Code пару десятков MCP-серверов и ужаснулись счетам за API? Знакомая история. В этой статье рассказываю, как я устал платить за замусоренный системный промпт и написали toolc - прокси-шлюз на Go. Он прозрачно сжимает хаос из баз данных, скриптов и OpenAPI-каталогов в один компактный слой. Показываю на реальных бенчмарках (GPT-5.4, Claude 4.6), как правильная маршрутизация снижает затраты на токены на 60% и спасает LLM от галлюцинаций.

Переводим нашу платформу с JSON на Apache Avro и Schema Registry. Заменяем сериализаторы и десериализаторы, генерируем классы из схем и разбираем разницу между GenericRecord и SpecificRecord.

Практика на реальном проекте.

Выбирать стиль интеграции приложений — всё равно что выбирать фундамент для дома. Ошибёшься — и переделывать придётся, когда стены уже стоят.

В этой статье я разбираю четыре основных стиля интеграции: передача файлов, общая база данных, удалённый вызов процедур (RPC) и асинхронный обмен сообщениями (Messaging). Без воды, на реальных примерах — включая историю провала TSB Bank, который стоил сотен миллионов фунтов.

Вы узнаете:

▪️ почему общая база данных — это антипаттерн для микросервисов;
▪️ как асинхронность спасает прод, когда падают соседние сервисы;
▪️ какие best practice используют команды, чтобы не получить распределённый монолит.

Если вы архитектор, тимлид или разработчик, который хочет строить надёжные системы — добро пожаловать под кат.