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

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, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.
 

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

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

Привет, Хабр! Я Юрий Дергач, я возглавляю ЦК 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‑сервис. Читаете статьи, смотрите видео, решаете «делать по‑взрослому». Создаёте структуру: