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

Автор: Дмитрий Левин, системный аналитик, отдел системного и бизнес‑анализа, Петрович‑Тех

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

Но за фасадом строительного ретейлера скрывается слой, который клиент никогда не видит, — 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, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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

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

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

Раньше я отвечал в комментариях каждому, потом понял, что проще ответить сразу всем. И заодно признать неприятное: в изрядной части случаев этот комментарий справедлив. Хорошая новость в том, что за годы разговоров с коллегами из других компаний у меня накопилась приличная коллекция возражений против меня самого. Это архитекторы, аналитики, руководители разработки — люди, которые платформу не продают. Часть этих разговоров я тут перескажу, кое‑где даже дословно.

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

Монолит документооборота, менеджмент говорит: «пора пилить на микросервисы». Мы нарезали шесть сервисов, сверху повесили API Gateway, Load Balancer и Circuit Breaker и какое-то время искренне считали, что теперь у нас взрослая распределённая система.

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

Это не туториал «как правильно резать монолит на DDD-bounded-context за 10 шагов» — таких на Хабре хватает. Это разбор конкретных мест, где границы у нас поехали, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой». Если вы сейчас режете свой монолит — читайте как чеклист. Если уже прошли — сверьте, сколько совпало.

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

Что полезного может делать бизнес-процесс, в котором всего одна задача, и та пользовательская? Что можно рассказать про BPMN-схему, которая поместится на экране смартфона? Муки выбора, драма, предательство и обстоятельства непреодолимой силы — вот что! Я расскажу, как на самом деле разрабатываются BPMN, исполняемые в движках вроде Camunda и Flowable, и, может быть, вы перестанете считать их просто «очередной графической нотацией»

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

Недавно мы с коллегой Андреем Даниленко, ведущим разработчиком, провели вебинар, на котором рассказали про коннектор к 1С, и в комментариях попросили выложить более подробный технический разбор, что там происходит «под капотом» с точки зрения OData, и как выглядит этот сценарий на живых примерах. Здесь я делаю детальный текстовый анализ. Приглашаю всех присоединиться и при желании посмотреть запись вебинара: https://rutube.ru/video/9344562315beaaf94430d7c4de16ed74/?r=wd&p=KqHZJOTtxfoFzqSMgPuwYg

redb.Identity получил gRPC-фасад: те же маршруты ядра, тот же реестр клиентов, один токен на оба транспорта. Что внутри, как включить, что померить.

Про redb.Identity мы не раз говорили, что он транспортно-агностичен: вся логика живёт в ядре за адресами direct-vm://identity-*, а HTTP это всего лишь фасад поверх них. Звучало убедительно, но проверить это утверждение было нечем. Фасад был ровно один, и «агностичность» оставалась обещанием архитектуры, а не наблюдаемым фактом.

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

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

Интересно вот что: большинство этих возможностей Kubernetes не нужны. Он опирается лишь на небольшое подмножество YAML. Отсюда возник простой вопрос: если Kubernetes нужна только малая часть YAML, почему бы не стандартизировать именно эту часть, а остальное не использовать? Вместо того чтобы вводить новый язык конфигурации, SIG CLI представила KYAML, более строгий и последовательный способ писать YAML. А мы в VK Cloud перевели об этом статью.

Привет, Хабр! Сегодня рассмотрим тему gRPC и работы с ним в контексте языка программирования Go на примере простейшей реализации аутентификации. Полный пример вы можете найти в архивном репозитории github.gRPC является современным фреймворком, разработанным Google для связи между программными сервисами. RPC — это тип связи, который позволяет приложениям взаимодействовать друг с другом по сети. Он позволяет вызывать процедуры одного приложения из другого, что обеспечивает большую масштабируемость и позволяет реализовывать сложную микросервисную архитектуру. Также благодаря возможности версионирования и указания конкретной структуры API в файле Protobuf, появляется возможность поддерживать единое состояние у всех сервисов системы. Основным смыслом gRPC является то, что работа происходит в виде набора байт, а не JSON и тому подобных форматов, при этом также нужно учитывать, что gRPC — это не только бинарный формат, но и HTTP/2, так как именно HTTP/2 даёт мультиплексирование и стримминг. Это делает общение между сервисами максимально быстрым. Основным краеугольным камнем здесь является Protobuf.