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

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

В этом интервью я, Александр Шулепов (телеграм-канал 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 превращается из простой очереди в проверку на прочность всей архитектуры. За обещанием «строгой последовательности» стоят сетевые задержки, алгоритмы консенсуса и суровые ограничения распределенных систем.

Один разработчик, один AI-напарник (Claude), ноль инвесторов. Рассказываю, как за 4 месяца я построил платформу автоматизации контент-маркетинга с 14 микросервисами, собственной очередью задач на SQLite вместо Redis, мультимодельным AI (MiniMax, YandexGPT, Replicate) и circuit breaker для автоматического fallback между провайдерами. Всё на одном сервере, всё через npm install.

Почему использование JSON как формата сообщений может стать узким местом в высоконагруженных системах? Что такое Apache Avro и Schema Registry?

Простым языком об этих технологиях, их работе и причинах их возникновения.

Для российских компаний выбор между серверами приложений на базе Apache Tomcat и WildFly давно перестал быть спором о «любимом стеке разработчиков». Это стратегическое решение, влияющее на устойчивость бизнес‑сервисов, стоимость владения ИТ‑ландшафтом и способность пройти путь импортозамещения без рисков для критичных систем.

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

Гораздо продуктивнее смотреть на сервер приложений на базе Apache Tomcat и сервер приложений на базе WildFly как на два разных типа решений под разные задачи – и выстраивать платформу, которая позволяет использовать оба подхода в едином управляемом контуре.

«Значит, смотрите. Payment-service ходит в booking-service, но только через API gateway, который дёргает auth-service, а тот валидирует токен в Redis, который шарит с notification-service…» — вы, объясняя архитектуру новому разработчику.

Десять лет мы разматывали нитки между сервисами на доске, как Чарли из «В Филадельфии». 42% компаний уже тихо сворачивают микросервисы обратно. Istio не осилил микросервисную архитектуру собственного control plane. Бывший CTO GitHub называет это «главной архитектурной ошибкой десятилетия».

А потом пришёл AI, которому не нужны ни митинг на 15 человек, ни три года в проекте, чтобы понять, почему бронирование — это цепочка из 12 HTTP-вызовов вместо одного function call.

Разбираю шесть причин дробления монолитов. Спойлер: половину из них AI уже отменил.