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

В этой статье речь пойдет о добавлении в С++ приложение функционала сохранения данных в формате YAML с использованием библиотеки yaml-cpp. Мы подробно рассмотрим какие возможности для этого предоставляет библиотека и на какие подводные камни можно наткнуться в процессе ее использования.

Особое внимание будет уделено вопросам форматирования(и представления) выходного YAML-текста, поскольку это влияет как на восприятие конечного YAML-документа человеком, так и на совместимость с другими программами, парсеры которых могут хуже поддерживать спецификации YAML.

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

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

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

Где именно все может сломаться

Предположим, у нас две системы:

Мультиагентные системы часто собирают по привычной схеме «оркестратор + набор независимых сервисов-агентов» — и довольно быстро приходят к распределённому монолиту. В статье разберем, почему при интерфейсе на естественном языке нельзя принудительно обеспечивать контракты как в API, из-за чего усложняются маршрутизация, изменения начинают каскадить, а общий контекст превращается в разделяемое состояние. И почему в такой ситуации иногда разумнее признать монолит — и управлять оркестрацией как единым целым.

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

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

Почему большинство корпоративных ИТ-систем устаревают в момент внедрения и как этого избежать

Если вы хотя бы раз сталкивались с документооборотом в компании, то знаете, что это огромная и неповоротливая махина, наладить которую сложно, пустить на самотек нельзя, а выстроить идеально практически невозможно. Или все-таки возможно? Какие проблемы возникают при работе с системами электронного документооборота и как их избежать еще на этапе внедрения, попробуем разобраться в этой статье. 

Привет! Меня зовут Любовь Черкасова. Я больше 13 лет работаю в ИТ и занимаюсь цифровизацией бизнес-процессов в крупных компаниях. За это время я руководила командами аналитиков и отделом внедрения, участвовала в проектах по запуску и развитию корпоративных систем, а также выводила на рынок собственный продукт — LDM.КЭДО.

Последние годы я занимаюсь развитием CSP-платформы и регулярно вижу и исправляю последствия архитектурных решений, принятых на этапе внедрения. Поэтому многие из наших проектов - устранение этих последствий и замена существующих систем. Я ни раз наблюдала проекты, в которых система формально внедрялась успешно, но уже в процессе реализации становилась неактуальной для бизнеса: требования менялись быстрее, чем шёл проект. Именно этот опыт и выводы из него легли в основу статьи. Я расскажу о том, как наша команда изменила подход к реализации систем электронного документооборота (СЭД), и что из этого получилось. Надеюсь, наш опыт будет полезен кому-то еще. 

Все кейсы, описанные в статье, реальные, они действительно из жизни наших клиентов. 

В первой части мы разобрали protoc-gen-validate и spec-first подход к валидации. Я обещал рассказать про protovalidateну и вот, держите :)

И самый первый вопрос конечно, а зачем вообще появился protovalidate, если PGV уже есть и работает?

Когда я был разработчиком я задавался вопросами: как разделить код на классы? какие модули выделить?

Когда я стал архитектором я задавался вопросами: зачем же мы наплодили 200 микросервисов? стоит ли выделять новый или пора объединять?

Когда я стал руководителем я задавался вопросами: как разделить людей на команды разработки? стоит ли создавать новый отдел или расширить ответственность старого?

И всё это хотелось сделать оптимальным эффективным образом.

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

Кейс: как использовать frontend-фичи и UX для оптимизации сетевого трафика запросов на примере Дзена и других сервисов

Многие опытные разработчики недооценивают мощь инструментария БД при работе с микросервисами. По каким-то причинам в IT-сообществе приняты эмпирические правила - сервис маленький, значит и база маленькая. Но это не совсем так.

Скорее всего, при проектировании архитектуры у нас в голове чаще всего возникает паттерн database-per-service. И когда мы начинаем рисовать схемы, то возникает соблазн покрутить кирпичики модулей так, чтобы красиво их соединить стрелочками с цилиндриками, обозначающими БД.

С другой стороны, все знают, что много микросервисов, взаимодействующих через одну общую монструозную базу как Oracle, ElasticSearch и другие - это антипаттерн.

Поэтому выбирают маленькие(!) Postgres или MySQL.

«Принципы модернизации программных архитектур»— это действительно полезное руководство по современной архитектуре ПО, ориентированное на реальные случаи миграции монолитных систем в микросервисы и обратно. В одной книге собраны и объяснены все ключевые знания, включая решение архитектурных антипаттернов и советы по повышению качества инженерных решений. Книга подходит как для практикующих архитекторов, так и для разработчиков, стремящихся понять, почему архитектуры ломаются, Что делать? и Кто виноват? (и как это исправить). 

Как работать с Kafka транзакциями из Spring Boot? Когда они нужны, а когда бесполезны или даже вредны?

Простым языком и с примерами кода о Kafka транзакциях.

За последние шесть лет испробовал множество аспектов работы с API-контрактами, не только с точки зрения проектирования, но и остальных этапов жизненного цикла этих артефактов.

Так-то API-контракт может быть не просто набором методов, которые «по-бырику» выставили, пока дальше код пишется, а что-то более зрелое и, соответственно, требующее более зрелого и продуманного подхода.

На что стоит обратить внимание при работе с API-контрактами внутри дружественной корпоративной среды множества разрабатываемых ИТ-систем?

В этой статье я расскажу о том, как добавить в С++/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 платформа.