В этой статье я расскажу о том, как добавить в С++/CMake проект возможность чтения YAML-конфигов с помощью библиотеки yaml-cpp.
Начнем с краткого обзора интерфейса yaml-cpp, а потом разработаем небольшой проект, состоящий из библиотеки с функционалом чтения конфига и приложения, использующего эту библиотеку для получения настроек из YAML-файла.
Изначально микросервисная архитектура решила реальную проблему - изолировала очереди и убрала “head-of-line blocking”, когда один упавший адресат тормозит всех.
Но дальше начался рост репозиториев, расхождение версий общих библиотек, рискованные обновления и операционная нагрузка. К тому же каждый сервис обладал своим профилем ресурсов и ручной настройки автоскейла.
В итоге команда объединила 140 сервисов в один монолит, собрала монорепо и стабилизировала тесты через запись/воспроизведение HTTP-трафика.
Ограниченные строгими регуляциями и перегруженные высокими объемами транзакций, требующих быстрой обработки, банки должны обеспечивать надежность и безопасность финансовых операций, какие бы проблемы ни возникали на их пути. Хотя в сложных банковских процессах многое может пойти не так, распределенная архитектура систем современных финансовых институтов добавляет сложности в обработку сбоев. Мы собираемся объяснить, как банки могут эффективно автоматизировать откат транзакций через несколько микросервисов и предоставить реальный пример работы компенсационных событий Camunda в банке.
Привет! Хочу рассказать о своем новом небольшом проекте - pg-status. Это очень легкий и производительный микросервис, который помогает определять статус хостов postgresql. В первую очередь его задача - помочь вашему backend найти живого мастера и достаточно синхронную реплику.
Создать Spring-сервис просто: существует масса статей и отличная документация. Однако среди всего этого многообразия материалов зачастую сложно разобраться, какой именно набор технологий лучше выбрать и каким образом эти технологии должным образом интегрировать друг с другом. После перехода на новые версии библиотек многое начинает функционировать иначе, появляются совершенно другие подходы. В данной статье я хочу продемонстрировать один из возможных способов разработки микросервиса в 2026 году, а также рассмотреть несколько инструментов автоматической генерации кода: OpenApiGenerator, JooqCodegen, GigaChat, Liquibase — и объяснить, как они работают вместе в рамках единого проекта.
Точкой отсчета для построения микросервиса сделаем описание REST API. Допустим, в нашем фантастическом мире аналитик заранее подготовил спецификацию API с помощью формата OpenAPI, хотя подобное встречается и в реальной практике.
Если вы работаете Enterprise-архитектором, вы наверняка слышали о микросервисной архитектуре и работали с ней. И хотя в прошлом вы, возможно, использовали REST в качестве слоя взаимодействия сервисов, всё больше и больше проектов переходят на событийно-ориентированную архитектуру (Event-Driven Architecture, EDA). Давайте разберем плюсы и минусы этого популярного подхода, ключевые проектные решения, которые он влечет за собой, и распространенные антипаттерны.
Микросервисный подход казался выбором по умолчанию в последнее десятилетие. «Делай микросервисы – и будет хорошо», – намекал опыт построения огромных программных систем. Вместе с тем в последнее время в сети всё чаще встречаются мнения, что «не нужны нам эти микросервисы», и тому есть причины.
Статья инспирирована переводом Распределенный монолит: тихий убийца мечты о микросервисах и некоторыми комментариями, отражающими, что тема описана не слишком подробно. Покажу видение данной темы немного с другой стороны.
Я Олег Одинцов, платформенный инженер App.Farm. App.Farm — собственная разработка Россельхозбанка, которая используется для стандартизации процессов разработки программного обеспечения и предоставления высокоуровневого интерфейса пользователям для автоматизации их задач. Можно сказать, что App.Farm — это автоматизация «под ключ». Пользователь получает полный цикл управления разработкой от размещения кода до деплоя приложений. Более «смузийное» название — IDP платформа.
Разработка сервисов с интеграцией в AWS быстро упирается в компромиссы: либо работать с реальным облаком и платить за каждый эксперимент, либо замокать инфраструктуру и надеяться, что в продакшене всё «взлетит». В статье показано, как с помощью .NET Aspire и LocalStack выстроить полноценное локальное AWS-окружение — с S3, CDK и реальной оркестрацией — так, чтобы один и тот же код без условностей работал и локально, и в проде.
Привет, меня зовут Анатолий, я ведущий разработчик в ITFB Group. Наш ключевой микросервис со временем превратился в настоящего монстра. Разросшийся, медленный и перегруженный лишними функциями, он тормозил весь продукт и усложнял жизнь разработчикам. Любая правка превращалась в квест: чтобы внести изменение в одном месте, приходилось разбираться ещё в десятке несвязанных процессов.
Мы решили провести «хирургическую операцию»: за один месяц силами выделенной команды из 10 человек полностью расчистить сервис, вынести из него 40 процессов и вернуть архитектуре прозрачность. В этой статье я расскажу, как мы поставили диагноз, спланировали операцию и справились с самыми болезненными моментами — от войны с конфигами до разрыва общих DTO.
Главный спойлер: результат превзошёл ожидания. Сервис стал быстрее, команды — автономнее, а система наконец-то обрела масштабируемость.
За две недели я собрал бесплатный веб-сервис, который генерирует диаграммы по текстовому описанию — без ручного рисования и без мучений с кривыми картинками от ИИ. Ключевая идея: вместо генерации изображений — генерация PlantUML-кода, затем серверный рендеринг в PNG и выдача пользователю. В статье рассказываю, как я проектировал сущности и сервисы, строил микросервисную архитектуру с очередями, поднимал PlantUML-server и MinIO, настраивал мониторинг и деплой, а также танцы с бубнами вокруг локальной LLM — и как меня спас старый ноутбук с GPU. Отдельно — про боль вайбкодинга: где ИИ-агенты помогают, а где требуют жёсткого микроменеджмента и шаблонов промптов.
От монолита к модулям: строим масштабируемую архитектуру AI-агентов с FastMCP и LangChain
Год бума AI-агентов показал: самая большая проблема — не галлюцинации, а архитектура. Когда инструментов много, а агенты распухают, копипаста и сложность тестирования убивают скорость разработки.
Привет, Хабр!
Продолжаю делиться дискуссиями из нашего телеграм-канала Dev Q&A. На этот раз собрались поговорить о том, почему при всём богатстве инструментов — Kubernetes, CI/CD, low-code, AI-ассистенты — разработка не становится ни быстрее, ни дешевле. Собрал ключевые мысли в статью. Получилось про три столпа эффективности, про хаос который понятнее порядка, и про то, почему скрам по книжке остановил компанию на две недели, а Waterfall принёс миллиард.
Привет, Хабр!
Продолжаю делиться материалами живых дискуссий, которые идут на телеграм-канале Dev Q&A. На этот раз тема — выбор между open source и коммерческими LLM для корпоративных задач. Обсудили главные болевые точки: почему почти все корпоративные заказчики требуют он-прем, как узкоспециализированные модели обходят универсальные решения, насколько реален GPU-дефицит для практических задач.
Привет, Хабр!
Недавно собрались с коллегами в эфире ТГ канала для разработчиков обсудить то, что сейчас волнует, кажется, каждого в индустрии — ИИ-инструменты в разработке. Не абстрактно «что думаете про ChatGPT», а конкретно: что реально работает, что нет, и почему при всём хайпе проекты не стали выходить быстрее. Вообщем, собрал ключевые мысли — дальше от третьего лица, включая свои реплики как участника.
15 декабря в МГТУ им. Н.Э. Баумана (в питчинг-формате) прошел финальный Демо-день акселерационных программ «Умный город» и «Робототехника и беспилотные авиационные системы» (БАС). В течение трех месяцев студенческие команды под руководством опытных наставников последовательно работали над своими проектами. На мероприятии в МГТУ они представляли свои разработки бизнес-сообществу, инвестиционным фондам, институтам развития и другим заинтересованным сторонам, которые способствуют укреплению технологического суверенитета.
Привет, Хаброжители! «Паттерны Kubernetes» — это не очередной справочник по настройке кластеров или описанию API. Это фундаментальный труд, который отвечает на самый главный вопрос: как эффективно проектировать и строить приложения, предназначенные для работы в Kubernetes? Авторы систематизировали лучшие практики, преобразовав их в паттерны. Книга учит не просто использовать Kubernetes, а мыслить категориями платформы, комбинируя примитивы для создания отказоустойчивых, масштабируемых и удобных в эксплуатации систем. Это must-read для любого разработчика, который хочет выйти за рамки простого деплоя контейнеров и овладеть всеми возможностями Kubernetes.
Сегодня потребности бизнеса растут так стремительно, что решения для унифицированных коммуникаций (UC) просто не успевают за ними. Аплайнсы — выделенные «железки» под конкретную задачу — очевидно устарели: масштабировать их сложно, обновлять страшно, а добавление новых функций напоминает скорее тест на выносливость. Я Владимир Сергеев, руководитель практики UC и ПО для совместной работы в К2Тех. Регулярно я сталкиваюсь с тем, как очередной апдейт превращается в персональную головную боль для ИT-отдела.
Решением, которое буквально спасло UC-инфраструктуру, стал Kubernetes. Теперь вместо тяжелых проприетарных коробок — легкие микросервисы. Вместо многочасовых простоев — обновления за минуты. Вместо страха перед будущим — быстрая реакция на любые бизнес-задачи. И никакого даунтайма для всей компании.
Давайте погрузимся в детали этого перехода: от неповоротливых «кирпичей» к динамичным контейнерам. Разберемся, почему страдать от обновлений больше не нужно. И посмотрим, так ли все радужно на самом деле.
Как работать с оффсетами в Kafka на практике, используя Spring Boot?
Разбираем проблемы и их решения на примере интернет-магазина.
Простым языком и с примерами кода о режимах коммитов, проблемах с транзакциями и надёжных паттернах.
Я собрал минимальный набор практик, без которых микросервис очень быстро превращается в «чёрный ящик»: логи, трассировка, метрики, конфигурация, feature flags, тестирование и чуть-чуть документации. Это не теория — это вещи, которые я выстрадал, пока делал Go-шаблон для коллег, переходящих после Ruby/PHP, и пытался сделать так, чтобы сервис было реально удобно запускать, отлаживать и поддерживать.
Внутри — простые объяснения, почему эти штуки окупаются, и примеры на Go: как разделить логи и связать их с trace_id, как руками добавить span, какие метрики имеет смысл считать, как организовать конфиг, зачем OpenFeature, почему testcontainers — это не боль, и почему Makefile иногда экономит больше времени, чем очередной «идеальный рефакторинг».
