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

Привет, Хабр! Меня зовут Валентин Вертелецкий, я DevOps в СберТехе, занимаюсь развитием Platform V Kintsugi — это графическая консоль для сопровождения Postgres-like СУБД. Наш продукт построен на микросервисной архитектуре и сначала разрабатывался с использованием базовой функциональности Kubernetes — там нет встроенных механизмов аутентификации, авторизации, управления доступом и шифрования трафика. Когда же у нас стало больше сервисов, нам понадобилось повысить защиту и отказоустойчивость, добавить возможности управления доступом.

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

Для управления микросервисами в Kubernetes мы используем Platform V Synapse Service Mesh от СберТеха — это решение на основе платформы Istio. Покажу, как всё работает у нас. Плюс, я подготовил демо-проект для тестирования кейсов (ссылка в конце статьи). Надеюсь, он будет полезен командам, работающим с микросервисами. 

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

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

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

Неважно почему, но иногда может появиться желание заняться рефакторингом ваших скриптов liquibase. В моём случае постоянно возникали конфликты в общем файле журнала изменений, количество скриптов превратилось в ужасно длинный список, а в самих скриптах невозможно было ориентироваться, поскольку они содержали по 1–2 команды, а в названии файла были только дата и действие. Долго это терпел, долго взвешивал плюсы и минусы, и всё время боролся с желанием всё отрефачить. И в какой-то момент дошёл до точки, когда желание взяло верх.

Решение принято: рефакторингу быть! Сразу скажу, приступать было страшно, но сейчас я очень доволен результатом. «Идеальную» структуру мы не получили, пришлось идти на компромиссы и заплатить свою цену, зато в новой структуре удалось вылечить все проблемы. Теперь в ней удобно ориентироваться и читать код, конфликты создаются очень редко, а все скрипты автоматически детектируются liquibase-ом. Но только это конец истории. А вначале было вообще непонятно, как рефакторить журнал изменений, да так, чтобы в существующие базы данных он смог пролиться, и ничего не поломал при этом!

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

Микросервисы обещают решение. Гибкость. Масштабируемость. Независимые команды. Быстрые релизы. Звучит идеально. Но дорога к этой цели усеяна ловушками. Я видел проекты, которые провалились, потратив миллионы. Они просто поменяли один большой клубок проблем на десятки маленьких.

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

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

В 2025 году перед вами открывается широкий выбор инструментов для мониторинга производительности приложений (Application Performance Management — APM). В этой статье мы подробно рассмотрим 20 лучших из них, сравнив их ключевые функции, преимущества и недостатки, чтобы помочь вам сделать осознанный выбор.

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

В этой статье мы подробно рассмотрев 20 лучших APM‑инструментов, их ключевые особенности, а также сильные и слабые стороны.

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

Мой шортенер начинался как простая практика с Go и gRPC после всех ОГЭ:), где должно было быть 3 сервиса: тг бот, API gateway и ядро. Но с каждым днем идей все больше, энтузиазм растёт, я стал делать упор на высокие нагрузки, и постепенно мини‑практика начала становиться боевой event-driven машиной. В этой статье я хотел бы подметить интересную мысль: даже самая простая вещь может быть реализована сложно.

Если вспомнить, что мы проходили в архитектуре за последние десятилетия, вырисовывается любопытная картина. Сначала были монолиты и мэйнфреймы, затем — двух- и трехзвенные архитектуры. Не так давно все активно занимались распиливанием монолита на микросервисы, массово внедряли CQRS. Казалось, нащупан стабильный путь развития. Но что дальше? Как раз об этом сегодняшняя публикация. Мы подготовили ее на основе доклада на True Tech Day от Олега Ивлева — директора по развитию технологий, и Марина Путниковича — руководителя центра практик «Архитектура» в МТС Web Services. Надеемся, получилось интересно!

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

В статье рассматривается применение трассировок стандарта OpenTelemetry для реализации инструментов мониторинга микросервисов на базе продукта Smart Monitor. Решаются задачи инвентаризации сервисов и ресурсов, анализа трассировок и формирования модели здоровья микросервисных архитектур.

Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.

А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.

Привет, Хабр! Я Святослав Волохов, QA-инженер в AGIMA. Тот, кто хоть раз тестировал сложный интеграционный сервис с десятками зависимостей и внешними API, да еще и в финтехе, знает — без грамотно выстроенной системы тестирования не обойтись.

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

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

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

Привет, Хабр!

Сегодня мы рассмотрим, как поднять gRPC-микросервис на tonic и обвязать его аутентификацией плюс метриками через Tower-middleware.

Привет! Меня зовут Сергей Киселёв, я Head of Development Platform в MWS Cloud Platform. В 2023 году я пришёл собирать команду Development Platform (DevP) для разработчиков нового облака. Эта статья написана по следам моего доклада «Как с нуля построить Development Platform в отдельно взятой компании» на DevOops 2024. Далее расскажу о том, почему мы заботимся об общем коде, растим культуру разработки и почему только разработчик может сделать инфраструктуру для другого разработчика.

Apache Kafka — это основа современных распределенных систем, обрабатывающий триллионы событий ежедневно. Но что происходит, если сообщение потерялось, пришло дважды или нарушилась логика бизнес‑процесса? Гарантии доставки в Kafka — это страховка от хаоса в условиях высокой нагрузки и сбоев.

В этой статье мы разберем три вида гарантий доставки сообщений на примерах.

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

В этой статье мы подробно расскажем о пути перехода платформы контейнеризации dBrain.cloud с MaaS на Metal³. Основная задача, которую решают оба этих проекта, состоит в установке операционной системы на серверы платформ. Озвучим причины, по которым мы искали альтернативные решения, и объясним, чем Metal³ превосходит MaaS.

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

Идея была простая: что если можно будет просто отправить ссылку в Telegram и получить готовый к просмотру фильм?

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