Как построить микросервисы на RabbitMQ так, чтобы система не падала каскадом, а деградировала предсказуемо: outbox, mandatory, AE, идемпотентность, DLQ, приоритеты и реальные грабли из продакшена
Асинхронность в Python кажется простой — добавил async/await, и всё летает. Но на практике синхронные вызовы внутри асинхронного кода превращаются в «бутылочное горлышко», блокируя event loop и приводя к непредсказуемым последствиям: от подвисших запросов до деградации производительности. Как разбираться в таком случае и почему важно знать особенности фреймворков в подкате...
Magento — дорого, Ensi — сложно, Bitrix — просто. Или не так?
Всем привет! Я Роман, тимлид e-commerce агентства KISLOROD.
Платформа для интернет-магазина — стратегическое решение. Выбор между Bitrix, Magento и Ensi определит, насколько быстро вы запуститесь, сколько потратите на поддержку и сможете ли масштабироваться без боли. Разбираемся, что подойдет малому бизнесу, а что потянет высоконагруженный проект.
Сегодня API — это клей, который скрепляет весь цифровой мир. Они связывают сервисы, мобильные приложения и системы партнеров. Но именно поэтому они стали главной целью для атак. Дыра в API — это не просто техническая ошибка, это широко открытая дверь к вашим данным.
Латать дыры по мере их обнаружения — это путь в никуда. Профессиональный подход требует другого мышления. Нужно не тушить пожары, а строить систему так, чтобы она не загоралась. Безопасность должна закладываться в архитектуру и становиться частью процесса разработки. Давайте разберем проблемы, с которыми мы возимся каждый день, и посмотрим на стратегические ходы, которые отличают по-настоящему надежные системы.
Привет, Хабр! Я Владислав Кислый, разработчик отказоустойчивых нагруженных сервисов в Т-Банке. Расскажу страшную сказку о том, как в одной компании взялись разрабатывать сервис.
В качестве протокола взаимодействия выбрали gRPC. Что из этого вышло, с какими сетевыми проблемами пришлось столкнуться и как мы их решили — читайте в статье. Описанные проблемы можно потрогать руками с помощью тестового проекта, докера и темной магии Toxiproxy, который будет портить нам жизнь.
Одна из самых основных проблем в работе с gRPC - необходимость наружу вытаскивать отдельно REST API для web клиента, но, надо ли отдельно его писать, или можно как-то унифицировать и эту историю?
И вот начал я копать эту тему, и чем глубже копал, тем больше удивлялся. Оказывается, за последние почти 10 лет было целых ТРИ ЧЕТЫРЕ серьезных попытки затащить gRPC в веб. И знаете что самое смешное? Самая первая попытка, сделанная в 2015 году японкой-одиночкой (в команде с коллегами), до сих пор остается самым адекватным решением. А Google со всеми своими миллиардами и армией разработчиков так и не смог ничего нормального придумать. Но обо всем по порядку.
Ах, да, меня зовут Эдгар Сипки, я все также евангелист gRPC && OpenSource :) Кстати, мой канал, там я гораздо чаще пишу (а скоро еще и начну снимать очень много крутого контента про gRPC и Go), ну и конечно один из основателей инструмента EasyP
Ссылка на полный доклад, если хочется посмотреть - YouTube
Привет, Хабр!
Поскольку первая встреча прошла очень полезно и интересно, мы решили повторить и снова в эфире телеграм-канала Dev Q&A продолжили дискуссию о микросервисах и скорости разработки. Собрались технические эксперты из BPMSoft, DevTale, Revizto и Диасофт (в лице меня). Обменялись практическими примерами на тему как же упростить жизнь разработчикам и получать результат быстрее, дешевле и качественнее.
Привет, Хабр!
Недавно принял участие в панельной дискуссии про микросервисы. Планировался холивар «монолит vs микросервисы», но получился, на мой взгдяд, интересный разговор с реальными кейсами. Собрались специалисты с интересным практическим опытом: Павел Куликовский (Цифра банк),Антон Мартынов (SimbirSoft), Алексей Захаров (Axiom JDK), Андрей Почтов (АЭРО) и Александр Тырышкин (DEVTALE).
Привет, Хабр! Меня зовут Валентин Вертелецкий, я 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. Решаются задачи инвентаризации сервисов и ресурсов, анализа трассировок и формирования модели здоровья микросервисных архитектур.
Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.
А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.
