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

Привет, Хабр. Я Витя Михайлов, Backend Lead в Garage Eight, и больше 6 лет у меня RabbitMQ в продакшене. За это время мы с командой узнали много интересных вещей. О них я рассказывал этим летом, выступая на Saint Highload++ с докладом про рецепт правильного приготовления RabbitMQ. Там же я поделился 8 практическими кейсами. Сегодня в статье разберу один из них — Publish without Confirmation. Расскажу, почему из коробки Publish не имеет гарантий доставки в RabbitMQ, и что с этим делать. 

Большие старые проекты обычно живут по своим законам.

Ты уже не спрашиваешь, почему именно так, — просто делаешь свою часть работы и стараешься ничего не сломать.

Наш проект был именно таким: монорепозиторий, десятки микросервисов, сотни зависимостей и общие библиотеки для всего подряд. В кодовой базе было около 220 Python-пакетов и примерно 70 Docker-контейнеров, которые собирались из них. Всё хранилось в одном репозитории, а полный пайплайн для pull request’ов проходил в Azure TFS до 4-х часов.

Именно это пришлось оптимизировать...

Микросервисы тут, микросервисы там… Из каждого утюга доносится дивный сказ про прекрасный мир микросервисов. А ведь это всего лишь один вид из десятка архитектурных стилей, который имеет свои достоинства и недостатки.

В этом эксперименте мы внедрим микросервисы в личный сайт, нарушив ключевые принципы DDD. Я создам антипаттерн «бедных сервисов» (Anemic Domain Model) и покажу, чем опасен прямой доступ к данным между микросервисами.

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

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

Контейнеры - следующий шаг эволюции. Зачем виртуализировать целое железо и запускать полноценную ОС, если можно изолировать только сам процесс, используя встроенные механизмы ядра? Этот подход на порядок легче, быстрее и эффективнее.

Apache Kafka и REST (Representational State Transfer) — два популярных стиля взаимодействия, используемых в архитектуре микросервисов. У каждого из них есть свои сильные стороны и характеристики, которые делают их подходящими для различных сценариев. В этой статье мы рассмотрим технические аспекты использования Kafka и REST для межсервисного взаимодействия, приведем примеры и обобщим их ключевые моменты в сравнительной таблице.

Сегодня поговорим не просто об инструменте, а о фундаменте, на котором строятся современные интеграционные платформы. Речь пойдет об Apache Camel – открытом интеграционном фреймворке, который лежит в основе таких решений, как Red Hat Fuse, Talend и нашей собственной платформы от «Диасофт» – Digital Q.Integration.

Важно подчеркнуть: мы не используем экспериментальные или нишевые стеки. Наша платформа построена на проверенной, зрелой и широко распространенной связке: Apache Camel и Spring Boot. Это дает стабильность, совместимость с корпоративной инфраструктурой и возможность глубоко интегрироваться с экосистемой Spring – от безопасности до мониторинга и распределенной трассировки.

Странно писать про форк open-source проекта для ушедшего в историю Docker Swarm. Но после Millau остался ещё один гештальт - периодические задачи. Посмотрел на Ofelia и Swarm-cronjob, их звезды, обновления, количество незакрытых репортов. Попытался связаться с автором - тишина. Так что с чистой совестью взял код и добавил недостающее. Получилась Cirona - Swarm-cronjob с телеметрией и дашбордами.

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

А четвертая оказалось самой интересной. Где даже с неполадками сети и падениями сервиса был сделан лишь один заказ. И произведена одна оплата. Благодаря чему пришла желаемая теплая пицца. Которую хотел наш дорогой покупатель.

Погрузимся в проблематику оформления заказа, консистентности данных. И схлопнем все реальности в нужную с помощью Outbox Pattern.

Привет, Хаброжители! Сегодня мы делимся с Вами переводом статьи о распределенном монолите.

Аннотация
Привлекательность микросервисов — гибкость, масштабируемость, отказоустойчивость — часто ведет организации по пути, полному непредвиденных опасностей. В этой статье раскрывается обманчивая архитектурная ловушка: распределенный монолит. То, что начинается как, казалось бы, разумный паттерн проектирования для отделения бизнес-логики от технических проблем путем централизации «основного домена», незаметно превращается в антипаттерн, который сводит на нет все преимущества, обещанные микросервисами.

Мы подробно описываем коварные симптомы: кошмары версионирования, паралич развертывания и эрозия автономии команды. На ярком примере из реальной жизни — системе «Drive» и доставки на дом Carrefour — мы раскрываем основную проблему: внутреннюю модель, удерживаемую внешними стандартами. Затем мы раскрываем освобождающие решения: принятие по-настоящему нативных бизнес-моделей и разрыв цепей общих «основных» библиотек кода в пользу явного промежуточного программного обеспечения и надежных API-контрактов. Это путь не только к коду, но и к возвращению обещаний микросервисов.

Здравствуйте, уважаемые читатели. Сегодня мы предлагаем вашему вниманию текст, который приоткрывает некоторые аспекты нашей авторской кухни. Пост получился благодаря тому, что своим авторским опытом с нами поделился уважаемый Владислав Светлаков из Минска, выпустивший у нас книгу "Архитектура бэкенда. API для надёжных корпоративных приложений". Книга отлично продаётся у нас чуть менее трёх месяцев и продолжает разработку большой темы проектирования API. Ранее мы выпустили другие подобные книги, большинство из которых ориентировано на поддержку и доработку бэкенда. Важнейшие из них:

В статье сравним REST, gRPC и GraphQL с точки зрения производительности, гибкости и архитектуры микросервисов. Покажем, как объединить GraphQL и gRPC для фронтенда и бэкенда, чтобы получить мощный API без лишнего трафика и задержек.

Что важно фронтенд-разработчику при создании веб-приложений? Поддержка текущей кодовой базы, удобство внедрения новых фич и возможность повторно использовать компоненты. Создать такие условия помогает популярный подход к проектированию — FSD (Feature Sliced Design). Разбиваем интерфейс на независимые, переиспользуемые модули (виджеты, фичи и т. д.), получаем чёткие правила, единую структуру проекта и ускорение разработки за счёт переиспользования кода и изоляции ответственности.

Подход FSD во многом прекрасен, но всё же нам в нём не хватало некоторых важных аспектов: внятного разделения слоёв бизнес-логики, удобства работы с кастомными хуками (они быстро разрастаются, обрастают связями и становятся сложными для тестирования). Также было неясно, куда выносить сложные общие компоненты из разных частей проекта. И, например, как легко отделять один бизнес-модуль от другого, не ломая всю систему…

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

Добрый день, дорогие читатели!

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

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

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

Добрый день. Сегодня мы поговорим о двух мощных технологиях для асинхронного обмена данными — ActiveMQ Artemis и Apache Kafka. Мы разберемся, что они из себя представляют, как устроены под капотом, и главное — в каких ситуациях стоит выбрать одну, а в каких другую.

Наш план на сегодня довольно насыщенный. Мы начнем с того, почему вообще все пришли к асинхронному общению сервисов. Затем подробно разберем ActiveMQ Artemis — что это и какие задачи решает. Заглянем в его техническую архитектуру, чтобы понять источник его производительности. После этого мы кратко вспомним основы Apache Kafka, чтобы затем перейти к самому интересному — детальному сравнению. Мы составим четкие рекомендации, поговорим о нагрузочных характеристиках и подведем итоги.

Как работать с Kafka на практике, используя Spring Boot?
Разбираем базовые практические моменты на примере интернет-магазина.

Простым языком и с примерами кода о настройке Kafka-кластера, об основных аннотациях и методах Spring Boot для работы с Kafka.

Всем привет! Меня зовут Ирина Загирова, я являюсь системным аналитиком в Банке Уралсиб. Сегодня хочу рассказать о трендовом инструменте, который уже помогает большому количеству людей в повседневной работе. Так же и в работе аналитика этот инструмент уже незаменим. Речь пойдет о нейросетях.

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

Привет, Хабр! На связи Александр Усачёв, системный аналитик в группе облачных продуктов Рунити. В основе нашей облачной платформы Рег.облако лежит микросервисная архитектура: каждый сервис отвечает за свой участок бизнес-логики — от биллинга до управления сетями. Между собой они обмениваются задачами через брокер сообщений. 

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

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

В начале октября на XIV Международной IT-конференции «Стачка» в Санкт-Петербурге — одном из крупнейших профессиональных событий российского IT-комьюнити — мы решили провести эксперимент. Что, если предложить разработчикам публично выбрать сторону в вечных холиварах? Например: Микросервисы или монолиты? Low-code или только ручной код?

Tudum.com — фан-портал Netflix с более чем 20 млн MAU, где скорость публикации и персонализации упирается в архитектуру. В статье — путь от «классического» CQRS с Kafka и read-store к узкому месту предпросмотров, а затем — к RAW Hollow: in-memory состоянию с сжатием и read-after-write на требовательных запросах. Разбираем, как отказ от Page Data/KV и I/O на горячем пути упростил контур чтения и дал прирост производительности, какие компромиссы это привнесло и почему такой подход срабатывает для контента, меняющегося не каждую секунду.