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

Можно ли описать архитектуру на Python, а получить работающий каркас сервиса на Go, C++, Rust или TypeScript? Причём так, чтобы схема не становилась отдельной документацией, которую все забывают обновлять.

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

Привет! Меня зовут Серёжа. Я работаю Java‑разработчиком. В этой статье хочу поделиться своим первым опытом реализации паттерна «outbox».

Решил я это сделать по нескольким причинам:

1. Зафиксировать для себя «на бумаге» архитектурное решение и полученный опыт.

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

3. Получить от профессионалов комментарии и замечания по улучшению моего решения.

Итак, давайте начнём!

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

В статье разбираем три таких инцидента из одной системы на transactional outbox, PostgreSQL и Kafka 4.2. Попробуйте сами определить, где сломалось: в источнике, в relay, в продюсере или у потребителя.

Российский рынок систем электронного документооборота сформировался давно и сегодня остается одним из наиболее зрелых сегментов корпоративного ПО. Крупные решения закрывают десятки сценариев — от регистрации и согласования документов до специализированных процессов, которые отличаются в зависимости от отрасли, масштаба бизнеса и внутренних регламентов компании.

Такая функциональная насыщенность стала естественным результатом развития рынка. Однако вместе с возможностями росла и сложность систем: увеличивалось число настроек, интерфейсов и сценариев работы, а внедрение СЭД все чаще превращалось в отдельный ИТ‑проект, требующий настройки, интеграции и обучения пользователей.

Мы в «Диасофт» считаем, что следующий этап развития СЭД может быть связан не с дальнейшим расширением функциональности, а с изменением самого подхода к архитектуре. Вместо еще одной крупной системы, которая существует рядом с ERP, CRM и другими корпоративными платформами, функции работы с документами могут стать частью уже существующих бизнес‑процессов.

Корпоративную GenAI платформу легко начать с выбора LLM, LangChain, vector database или Kubernetes. Но до этого полезнее ответить на другие вопросы: кто имеет доступ к данным, где проходит security boundary, какие компоненты действительно нужно разделять и что должно войти в первую версию.

В статье разберу, как спроектировать корпоративную GenAI платформу до начала реализации: требования и NFR, C4, Modular Monolith, разделение.NET и Python, PostgreSQL + pgvector, RabbitMQ, LLM Gateway, ADR и границы MVP.

Что делать, если произошла ошибка? Житейская мудрость говорит, что можно попробовать еще раз. 

В контексте разработки ПО существует известный и простой паттерн для повышения отказоустойчивости — retry.

Реализация ретраев в Java-приложениях придумана давно. Как вариант — достаточно добавить в код стандартные аннотации. Но внедрить ретраи — это не так просто, как кажется: нужно решить еще много вопросов — например, как сохранить согласованность данных, как подружить ретраи на разных уровнях архитектуры, а еще учесть особенности разных технологий. И наконец, как при этом не навредить проекту.

Привет! Меня зовут Петр Деменев, я Java-разработчик в MTC Web Services. В материале расскажу о нашем горьком, но успешном опыте внедрения политики ретраев в реальный проект и о неочевидных особенностях, с которыми мы столкнулись. В тексте будет акцент не на строгих теоретических канонах, а на реальной жизни, чтобы приземлиться на уровень практического опыта. И попутно расскажу о некоторых способах ретрая.

Привет, Хабр! Продолжаю серию статей по проектированию и разработке отказоустойчивой микросервисной системы сокращения ссылок.

Если вы только присоединились, рекомендую ознакомиться с предыдущими частями:

Привет! Это Дима Левин, я работаю системным аналитиком в «Петрович‑Тех». В прошлой раз я рассказывал о процессе обезличивания персональных данных. В этой статье я попытаюсь рассказать историю роста и развития IT‑ландшафта компании «Петрович».

Это история о том, как IT‑ландшафт «Петровича» вырос из одной системы в десятки специализированных и теперь движется к единой платформе. А заодно разберемся, чем занимается «Петрович‑Тех» и почему его работу можно сравнить со строительством.

Привет! Меня зовут Александр Илларионов, я бэкенд‑разработчик в Altenar. Мы работаем на довольно сложном и при этом очень интересном рынке: собираем данные о спортивных матчах со всего мира — например, время и место их проведения, описания чемпионатов и участников, а также вероятности наступления ключевых событий вроде голов, аутов и пенальти. И всё это в live‑режиме. 

В этой статье рассказываю, как мы переосмыслили роль Heartbeat‑компонента в нашей системе — от обычного сигнала до инструмента, который реально управляет работой всей системы. Наш опыт будет полезен тем, кто работает с .NET, распределёнными системами или строит инфраструктуру под высоконагруженные real‑time потоки данных. 

Я всё меньше пишу первую версию кода сам.

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

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

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

Сервис принимал запрос, писал строку в базу, отвечал 201. Никто не пишет статей про такой код, потому что в нём нечего обсуждать.

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

Значит нужно асинхронно, через брокер. И почти всегда этим брокером оказывается Kafka.

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

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

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

Привет, Хабр. 26 августа 2024 года я получил у BotFather первый токен и написал кривой телеграм‑бот с одной моделью — обычная история «хочу ChatGPT без танцев с бубном, сделаю себе сам». Бот был честно плохой: одна модель, никакого контекста, падал от длинных сообщений. Но он работал, им начали пользоваться дети и знакомые, и я решил «немного доделать».

«Немного доделать» продолжается второй год. Сейчас это платформа с веб‑приложением, шестью каналами доставки (Telegram, VK, MAX, Discord, веб и — для уведомлений и результатов долгих задач — email), биллингом, голосовым агентом и RAG по документам. А под ней — 66 контейнеров на двух нодах, BGP‑маршрутизация, собственный CI, хелпдеск и GPU‑нода с локальными моделями. Всё на железе, которое стоит под столом и потребляло меньше, чем игровая приставка, — до недавнего появления второй ноды с 3090; теперь приставка нервно курит. Эта статья — про то, во что превращается домашняя инфраструктура, когда backend‑разработчик два года не может остановиться.

Пишу это по двум причинам. Во‑первых, когда я начинал, мне отчаянно не хватало такой статьи — целостной картины, как это выглядит, когда селф‑хостишь ВСЁ. Во‑вторых, я почти наверняка делаю что‑то не так, и комментарии Хабра — самый быстрый способ об этом узнать. Не стесняйтесь.

Привет, Хабр! Меня зовут Александр, и я занимаюсь развитием системы расчета налога на дополнительный доход в ИТ‑кластере. В этой статье расскажу, как без боли для себя и для пользователя выгрузить большие таблицы из базы данных и предоставить их пользователю в xls‑формате. Рассмотрю вариант выгрузки всех необходимых данных в одном файле без кэширования и объясню, почему такое подход не будет работать.

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

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

Всё началось с задачи мониторинга сетевой инфраструктуры и скрипта на python.

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

Внутри: Эволюция, Архитектура, Отказоустойчивость, Федерация, Передача сообщений

Перевод по СБП — это не одна стрелка между двумя сервисами, а лимиты, антифрод, идемпотентность, НСПК, Kafka и уведомления. Я попробовал собрать этот сценарий не на вайтборде, а в виде интерактивного потока — и сразу нашел несколько дыр в архитектуре.

Привет, Хабр! Я Артём Борисов, Java-разработчик, в основном занимаюсь развитием микросервисов в команде РСХБ «Свои инвестиции». Представьте ситуацию: вы работаете с инвестиционными сделками, обрабатываете миллионы сделок в день, но все они обрабатываются один раз только ночью. А бизнес требует реального времени. Это была наша рутина, пока мы не внедрили Kafka Streams. В этой статье я расскажу о том, как мы трансформировали систему обработки сделок на фондовом рынке (SOFR) с batch-обработки на полноценную real-time систему, способную обрабатывать миллионы сделок в сутки.

Один и тот же артефакт разворачивается монолитом и кластером микросервисов. Те же модули, один дашборд на все воркеры, горячая замена без рестарта контейнера.

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

Обычно эту плоскость собирают заново: Prometheus, Grafana, самописный health-контроллер, скрипт деплоя, чат-бот для рестартов. Времени уходит столько же, сколько на сам распил.

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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