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

Представим обычную обработку заказа. Сервис заказов публикует событие order.created. Сервис склада получает его и резервирует товар в PostgreSQL. После успешной транзакции обработчик должен отправить RabbitMQ подтверждение (Ack), чтобы broker удалил сообщение из queue.

Но процесс может остановиться после записи в PostgreSQL и до отправки Ack. RabbitMQ не знает, успел ли сервис зарезервировать товар. Broker видит только неподтверждённое сообщение, поэтому доставляет его ещё раз. С точки зрения доставки это правильное поведение. С точки зрения бизнеса один заказ теперь может зарезервировать товар дважды.

Другой сбой возникает раньше: PostgreSQL временно недоступен, и обработчик не может начать работу. Если сразу вернуть сообщение в queue через отрицательное подтверждение Nack(requeue=true), RabbitMQ почти немедленно доставит его снова. Пока база не восстановилась, все попытки будут бесполезными. Нужны задержка и ограничение числа повторов. При этом отложенное сообщение может пропустить вперёд более новые события, поэтому отдельно придётся решить вопрос порядка.

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

В статье разберём эти моменты по всему пути сообщения. Затем построим практическую схему для RabbitMQ и Go: добавим ограниченные повторы через retry queues, время жизни сообщения (TTL) и dead letter exchange, сделаем обработчик идемпотентным и определим, куда отправлять сообщения, которые не удалось обработать автоматически. В конце сравним этот подход с Kafka, NATS JetStream и Amazon SQS.

Привет, Хабр! Сегодня System Design интервью стало неотъемлемой и, пожалуй, самой трудной частью найма разработчиков. От кандидатов требуют за короткое время спроектировать условный YouTube, Google Drive или Telegram, способный выдерживать миллионные нагрузки, не падать при отказе дата-центров и отвечать пользователю за считанные миллисекунды. И здесь большинство разработчиков сталкивается с суровой реальностью. Сложность в том, что на собеседованиях дают задачи на проектирование масштабных распределенных систем, но реальным опытом их создания создания обладают немногие. Задача проектирования может быть решена несколькими способами и не имеет единственного правильного ответа: Одно и то же требование можно реализовать многими способами, и каждый будет иметь плюсы и минусы. Нужно уметь проектировать высоконагруженные системы, учитывая проблемы сети: задержки, сбои серверов, обеспечение согласованности данных и балансировку нагрузки. Также требуется разбираться во множестве технологий и понимать, когда и как их применять.

Поэтому на интервью кандидат часто совершает критические ошибки: не умеет собирать требования и путает функциональные рамки проекта с нефункциональными (SLA, RPS, масштабируемость). Не видит нюансов и узких мест, из-за чего архитектура рушится при первой же пиковой нагрузке. Пытается строить отказоустойчивость «на бумаге», не понимая, как выбранные базы данных или очереди сообщений будут вести себя в реальном облаке. Лучший способ разобраться в тонкостях проектирования распределенных систем и увереннее чувствовать себя на архитектурных секциях — это создать такую систему с нуля в виде пет-проекта. Этой публикацией я начинаю серию статей, целью которой является желание поделиться опытом создания такой системы с нуля. Начнем с проектирования архитектуры, далее шаг за шагом реализуем ее на языке Go, развернем в облаке и оценим производительность. Будем проектировать систему сокращения ссылок из классической книги по системному дизайну.

series redb ecosystem

Про Kafka и RabbitMQ в этой серии уже было. Теперь — Amazon SQS, и вместе с ним в одном пакете SNS: два транспорта, потому что в мире AWS они ходят парой. Коннектор redb.Route.Sqs — поверх нативного AWS SDK for .NET v4 (AWSSDK.SQS, AWSSDK.SimpleNotificationService), но писать вам придётся не «клиент», а маршруты, где вся очередь задаётся одной строкой-URI:

Эта история началась не с продуктовой сессии, не с исследования рынка и даже не с запроса заказчиков. Отправной точкой стала встреча с коммерческой командой.

Коллеги из отдела продаж искали способ быстрее оценивать внешний периметр потенциальных заказчиков перед демонстрацией MULTISTATUS — сервиса геораспределённого мониторинга доступности веб-ресурсов.

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

Про Kafka в этой серии уже было. Теперь — RabbitMQ, и с упором на то, как им пользоваться. Коннектор redb.Route.RabbitMQ — поверх официального RabbitMQ.Client 7.x, но писать вам придётся не «клиент», а маршруты, где весь брокер задаётся одной строкой-URI:

Когда компания растёт из одного продуктового направления в несколько, технический долг начинает выглядеть иначе. Проблема уже не в «старом коде», устаревших зависимостях или сложной поддержке legacy-системы. Долг начинает накапливаться в расхождении инженерных решений между сервисами.

Для нас в QIC digital hub это особенно заметно на фоне миграции на новый Go-бэкенд. Исторически платформа развивалась на разнородном стеке: разные части системы были написаны на разных технологиях. Сейчас мы постепенно переезжаем на Go. Часть сервисов уже в проде, часть ещё на пути. Именно в такой момент легко создать новый слой техдолга поверх старого: переписать поведение на новом языке, но оставить команды один на один с десятками одинаковых инфраструктурных задач, которые каждая решает по-своему.

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

- go-kit — общая библиотека с переиспользуемыми инженерными решениями;

- go-service-template — шаблон, который делает эти решения стандартным способом запуска нового сервиса;

- shared-renovate-config — общий Renovate-конфиг с единой политикой обновления зависимостей для всех репозиториев.

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

Переход к микросервисной архитектуре неизбежно поднимает вопрос эффективности межсервисного взаимодействия. В PHP традиционный стек на базе PHP-FPM и REST API создает дополнительные накладные расходы: каждый запрос обрабатывается в отдельном процессе, что требует повторной инициализации контейнера зависимостей, загрузки конфигурации и всего контекста приложения. В результате увеличивается latency и снижается пропускная способность сервиса.

В этой статье мы шаг за шагом разработаем высокопроизводительный микросервис на Symfony 7, используя RoadRunner в качестве постоянного приложения-сервера, gRPC для межсервисного взаимодействия и Protocol Buffers для сериализации данных. По итогам вы получите полностью рабочий сервис и поймете, как построить производительную альтернативу классическому стеку PHP-FPM + REST.

Серия: redb ecosystem / redb.Route redb.Tsak

Есть у интеграционного кода одна неприятная особенность. Написать пару маршрутов — «принял HTTP, положил в базу, отдал обратно» — дело на полчаса. А вот довести это до состояния, когда оно крутится в проде, само поднимается, показывает метрики, умеет останавливать/запускать отдельные куски руками и разворачивается без пересборки — это обычно совсем другая история и совсем другой стек.

В этой статье я покажу, что в связке redb.Route + redb.Tsak это буквально один и тот же код. Мы:

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

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

Привет, Хабр. Меня зовут Виктор Овчинников, я руковожу разработкой интеграционной платформы Digital Q.Integration в компании Диасофт.

Про то, как интеграционный слой убивает ИИ-проекты, я уже писал здесь и здесь. Про историю появления платформы — тридцать лет проектной боли и зоопарк западных ESB написал Дмитрий Гаврин в отдельной статье. Рекомендую прочитать, если не читали.

Сегодня разберу технику. Что именно сидит под капотом платформы, какие инструменты мы выбрали и почему, где это работает хорошо, а где ломается.

Почему не классический ESB

Коротко, потому что Дмитрий уже написал развёрнуто.

Классическая ESB — это монолитное ядро. Масштабирование только вертикальное. И при падении падает всё. Но самое болезненное для эксплуатации это то, что со временем шина становится местом, куда стекается вся прикладная логика. Через несколько лет она знает о бизнесе компании больше, чем любая из систем, которые к ней подключены. Разобраться в этом — отдельная задача. Это то нас и подтолкнуло к собственному подходу.

Мы сформулировали для себя так: возьмём лучшее из point-to-point и из ESB. Независимые сервисы — без централизованной бизнес-логики. Общий транспорт, общий мониторинг, общий инструментарий — как в ESB.

Концепция называется «умные сервисы и надёжные каналы».

Архитектура: каждая система — отдельный микросервис

Предлагаю посмотреть, как это работает. Для каждой интегрируемой системы создаётся независимый микросервис-коннектор. Он содержит ровно ту логику, которая нужна для взаимодействия с этой системой — и ничего лишнего. Адаптеры общаются через транспортный уровень, который отвечает за доставку и надежность.

Здравствуйте, уважаемые читатели. Вот и настал тот день, когда мы поняли, что наш замечательный проект стал сложным. Спустя три года разработки его поддержка начала требовать значительных ресурсов, внедрение новых фич бизнеса замедлилось, а команда уже давно растеряла прежний интерес. Большинство из разработчиков неоднократно проходили эту стадию. Если посмотреть на ситуацию с другого ракурса, то всё далеко не так уж плохо: проект стал «взрослым», приносит деньги, что позволяет его развивать. Но всё-таки сложность только нарастает, проблемы напоминают снежный ком, и что-то с этим нужно делать.

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

А что если я скажу вам, что при таком подходе мы, скорее всего, получим с десяток микросервисов, которые по цепочке синхронно вызывают друг друга, знают подробности внутреннего устройства каждого, ходят в общие таблицы (крайне запущенный случай), и отказ одного из них вызовет крах всей системы? Прямо как с костяшками домино. Встречайте, Его Величество Распределённый Монолит!

Если вы продаёте на двух и более маркетплейсах, вы почти наверняка с этим сталкивались: товар продан на Ozon, но на Wildberries он ещё висит в наличии. Приходит заказ на то, чего на складе уже нет. Дальше по сценарию: отмена, штраф, падение рейтинга карточки, в худшем случае - блокировка.

В этой статье я разберу проблему по слоям: откуда физически берётся расхождение, какие есть уровни решений (от коробки до event-driven на Go), и почему модный ответ «поставьте Kafka» для одного селлера почти всегда оверкилл. Будет код и будут цифры.

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

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

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

Для клиента это обычный экран в приложении или личном кабинете. Открыл, посмотрел, что происходит с деньгами, принял какое‑то решение.

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

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

AutoML обычно отвечает на вопрос «что победило», а хотелось бы ещё знать «почему». Поэтому я собрал платформу, где обучение нейросетей ведут LLM-агенты. Они спорят об архитектуре, собирают конфиг и запускают обучение, и каждый их шаг виден прямо в интерфейсе.

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

От CRUD на FastAPI до видеоплатформы: история одного pet-проекта

История о том, как учебный CRUD-проект на FastAPI постепенно превратился в стенд с микросервисами, мониторингом, Kubernetes.

AI‑агенту не нужен прямой доступ к базе, чтобы отвечать на вопросы оператора или вызывать действия в системе. Достаточно дать ему набор управляемых инструментов через MCP.

В статье разбираем, как это выглядит в Spring Boot, где заканчивается простая демка и почему перед продакшеном придётся думать не о магии LLM, а о правах, логах, таймаутах и человеке в контуре.

В статье описан практический опыт интеграции ERP‑системы с 1С. В материале я рассказываю:
• почему мы выбрали микросервисную архитектуру
• зачем в одной интеграции использовали и GraphQL, и REST API
• как строили маппинг данных для разных конфигураций 1С
• как работает формат EnterpriseData и почему он сложный, но универсальный
• и на какие грабли мы наступали — чтобы вы на них не наступали.

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

Всем привет! Это Денис Сметнев. Последние пару месяцев я плотно сижу на вайбкодинге. Поднял свой сервер, запилил базу лидов из Телеграма и карту знаний, хотя последний раз кодил в 9 классе на Pascal. Вижу, что у многих появилась мысль: если я могу сам сделать себе любой софт под задачу, зачем тогда вообще нужны SaaS-продукты? Неужели они умрут? В этой статье хочу порассуждать, как на самом деле изменится рынок и почему хоронить софт пока рано.