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

Когда бизнес-логика становится сложной, микросервисы из удобного инструмента превращаются в источник боли. Классические «сценарии транзакций» приводят к монструозным классам и распределённым транзакциям, которые невозможно поддерживать.

В этой статье разберу, как DDD и агрегаты помогают проектировать бизнес-логику так, чтобы она не разваливалась под нагрузкой. Покажу на реальном примере HR-сервиса:

▫️ почему объектные ссылки между сервисами — зло;
▫️ как одно правило «транзакция = один агрегат» меняет архитектуру.

Когда мне пришла идея написать эту статью, я предполагала, что это будет хроника ошибок, от которых мы бы хотели предостеречь техническое сообщество: как мы наивно полагались на «синтетику», а «видовое многообразие» сервисов раскрыло нам глаза.

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

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

В этой статье мы расскажем о библиотеке оркестрации обработки данных, которая использует RabbitMQ как децентрализованный механизм передачи объектов между микросервисами. Ее задача — создание единого автоматизированного рабочего бизнес‑процесса.

Описание архитектуры

Речь пойдет о системе, которая ежедневно обрабатывает большой объем данных, получаемых как единовременно в виде файлов скачиваемых с различных FTP обменников в установленные регламентом промежутки времени, так и данных, получаемых в онлайн режиме в виде асинхронного стриминга информации посредством Kafka\RabbitMQ.

Привет, Хабр! Мы — команда dBrain.cloud, и сегодня хотим поделиться нашим путем по внедрению ИИ-сервисов на платформе контейнеризации.

Архитектура в ИТ — это не «нарисовать диаграмму» и не «выбрать стек». Это работа со сложностью: там, где одной команде уже тесно, где требования конфликтуют, а решения нужно держать в голове годами.

В этом интервью я, Александр Шулепов (телеграм-канал Shulepov Code), поговорил с Филиппом Дельгядо — архитектором финтех-продуктов и создателем сайта lekton.io — о том, с чего начинается архитектура, почему «монолит vs микросервисы» не решается одной фразой и какие навыки действительно определяют уровень специалиста.

Язык проектировался простым, лёгким в освоении, готовым для написания сервисов с первого дня. Он мог бы таким и остаться, если бы не одна проблема. Проблема отбора.

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

Явно ставилась задача — сделать язык достаточно простым, но не настолько, чтобы собеседование мог пройти любой новичок.

Выкатили приложение, а через час — таймауты? Redis отключился, а вы узнали об этом от клиентов?

В этой статье на реальном примере покажу, как Spring Boot Actuator превращает ваше приложение из «чёрного ящика» в прозрачную систему. Разберём:

➡ Что такое Actuator и зачем он нужен.
➡ Как настроить эндпоинты, чтобы не открыть дыру в безопасности.
➡ Какие метрики реально помогают найти узкие места (история, как мы ускорили приложение на 40%).
➡ Кастомные метрики для бизнес-показателей.
➡ Лучшие практики продакшена: liveness/readiness probes, изоляция портов, кастомные HealthIndicator.

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

С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками 20+ разных решений. Для всех, кто интересуется шинами данных, я также создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина. 

В современном мире enterprise-разработки часто встречается необходимость реализации распределённых блокировок. Недавно у меня как раз возникла необходимость реализации распределённой блокировки, и я применил пакет RedLock.NET, о чём и хочу рассказать.

Однако когда я писал статью, как-то «слово за слово», она вылилась в сравнительный анализ RedLock.NET и других решений, которые я тоже рассматривал. Мне кажется, все описанные ниже очевидные и не очень решения будет вспомнить вполне уместно. Надеюсь, получится не так уж длинно и будет полезно для читателей.

Под катом вы не найдете откровений, но найдете размышления (для кого-то, возможно, очевидные) разработчика над задачей, которую все вроде знают, как реализовывать, но когда нужно реализовать, то все опять «подзабыли».

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

В статье вы найдёте:

▫️ живые примеры из реальных аварий (включая историю с бесконечными ретраями в очереди),
▫️ три готовые диаграммы в формате Mermaid, которые можно сразу использовать в документации,
▫️ чёткий алгоритм выбора стиля под вашу задачу.

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

Kafka часто воспринимается как система, гарантирующая доставку сообщений и Exactly Once Semantics. Однако в реальных распределённых системах эти гарантии заканчиваются на границе брокера.

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

В этой статье разберём:

Привет, Хаброжители! API и сервисы, основанные на событиях, часто одновременно используются множеством приложений через сложную сеть интеграций, поэтому их сложно тестировать. Контрактные тесты предлагают простое решение этой проблемы. Совместимость API или сервиса проверяется с помощью согласованных контрактов. Контракты понимают и соблюдают все компоненты системы (а также разработчики, которые их создали). Этот инновационный метод помогает обнаружить проблемы интеграции на раннем этапе разработки и повышает жизненно важную для любой системы прозрачность.

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

Предполагается, что читатель имеет базовое представление о Kafka (раздел "Общие термины" поможет освежить информацию) и функционале библиотеки KafkaJS.

В первой части разбираются аспекты, связанные с публикацией сообщений.

Приветствуем, Хабр.

Сегодня мы хотим напомнить вам об одной важной книге, которую в очередной раз допечатали в январе текущего года: «Создание событийно‑управляемых микросервисов». Мы пытаемся развить эту тему в разрезе «для начинающих архитекторов», рады были бы пообщаться с потенциальным автором, который также разделяет наш интерес. Чтобы был более понятен интересующий нас уровень сложности и круг тем, предлагаем ознакомиться с переводным обзором этой темы; статья сентябрьская, найдена в блоге «The Scalable Thread».

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

Поэтому пора исправлять эту проблему в MireaPay и наконец-то добавить работу с крупными юр. лицами, которые будут называться корпоративными пользователями!

Всем привет! Меня зовут Наташа, и я системный аналитик. Сейчас я в поиске работы, сходила на пару собеседований, и хочу описать ответы на некоторые вопросы, которые там встречались - некая рефлексия для меня, и надеюсь, эти короткие статьи будут полезны и еще кому-то.

В этой статье я делюсь реальным кейсом построения системы рекомендаций для картин. Сначала мы реализовали простой поиск по тегам, а затем перешли к эмбеддингам изображений с помощью CLIP и хранению в Elasticsearch. Также я показываю, как строим персонализированные рекомендации на основе лайков и просмотров пользователя. Статья будет полезна тем, кто хочет понять, как создать рабочую систему рекомендаций на Python и постепенно улучшать её точность.

В микросервисной архитектуре один падающий эндпоинт может скрывать проблему в совершенно другом сервисе. В этой статье я покажу пошаговый процесс расследования реального инцидента: от обнаружения 100% error rate до точной причины сбоя — и всё это менее чем за минуту.

Мы будем использовать Uptrace - OpenTelemetry-native платформу для трейсинга и мониторинга. Все примеры основаны на реальном demo-приложении с микросервисами.

Раньше наш способ собрать данные из всех микросервисов в одно место (в витрину) напоминал копролит (только не древний, а наш собственный ИТ-артефакт). Он был сложный, медленный, постоянно ломался и требовал много ручной работы. Данные размазывались по куче баз данных. Чтобы сделать отчёт или отправить данные во внешнюю систему, надо было собирать их вместе. 

Высока вероятность, что у вас такой же или похожий. Если нет — приходите рассказать «а я же говорил» в комментариях.

Мы тратили время на латание дыр, а не на разработку. В какой-то момент решили, что пора выкинуть этот велосипед и внедрить нормальный, промышленный подход к работе с данными — Data Lakehouse с медальонной архитектурой.

«Сделайте нам строго по порядку» — эта фраза из бизнес‑требований часто становится началом долгого и дорогого инженерного триллера. В мире микросервисов и event‑driven систем классический FIFO превращается из простой очереди в проверку на прочность всей архитектуры. За обещанием «строгой последовательности» стоят сетевые задержки, алгоритмы консенсуса и суровые ограничения распределенных систем.