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

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

Привет, Хабр! Меня зовут Евгений Кермас, я главный эксперт по технологиям в Управлении развития технологий модельного риска в Сбере.

В этой статье я попробую ответить на вопрос: «Что делать, если вы, как архитектор, пришли на существующий проблемный проект в качестве кризисного-менеджера?» Расскажу о нескольких подходах и дам советы, которые могут помочь в принятии решений в создании архитектуры и планировании проекта. Для этого разберём один пример с максимальным количеством проблем. На входе у нас есть монолит с запутанным кодом, на legacy-инфраструктуре, с нецелевым техстеком и большим грузом проблем, как технологических, так и организационных.

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

Приложения тормозят. Пользователи уходят. Бизнес недоволен. Знакомая картина? Часто корень зла – медленный доступ к данным. Кеширование может стать спасательным кругом. Но это не серебряная пуля. Неправильно настроенный кеш – источник новых проблем, иногда похуже старых.

Привет, Хабр! Меня зовут Дмитрий Ханин, я работаю в Сбере и участвую в разработке Платформы ЦА — системы на базе блокчейн, занимающейся привлечением средств юридических и физических лиц. Сегодня хотелось бы рассказать про тот путь, который мы прошли за несколько лет, как организовали взаимодействие между разными приложениями и чем нам это помогло.

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

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

Хотя информации о ребалансировке Kafka достаточно, она часто либо слишком разрозненная и техническая, либо наоборот — поверхностная и без акцента на важные детали. Я собрал для вас самое важное и объясню это простым и понятным языком.

Привет, меня зовут Александр. Я более двух лет работаю backend разработчиком над микросервисами компании. Микросервисная архитектура стала очень популярной в больших проектах, ее используют большинство команд на разном стеке технологий. Сегодня разберемся как наша команда создает высоконагруженные сервисы с процентом надежности и устойчивости стремительно приближающимся к 99,99.

Закономерный этап развития Cloud Native — стремление компаний иметь возможность получения быстрого и простого доступа к инструментам и технологиям под разные кейсы и бизнес-сценарии. Поэтому большинство современных облачных платформ строится на концепции предоставления пользователям всех нужных ресурсов и инструментов в формате «единого окна». И основной способ реализации этой концепции — построение каталогов приложений.

В 2023 году мы впервые попытались запустить платформу dBrain.cloud на Astra Linux версии 1.7 Special Edition. Первая попытка оказалась неудачной.

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

Меня зовут Владимир и я senior backend в геораспределенной HighLoad системе. Которая выдерживает пиковые нагрузки в млн RPS. Моя страсть System Design. Я успешно прохожу интервью в BigTech компании, а также готовлю учеников. Выделил ТОП-5 ошибок у новичков и готов поделиться их разбором. Подробности под катом.

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

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

Во второй части мы разобрали, как тестировать микросервисы с кафкой. В этой части – лайфхаки при работе с offset explorer и kafka ui в формате чек-листа для удобства периодического возвращения к статье при необходимости. 

Когда вы впервые подключаетесь к кластеру Kafka или продолжаете работу с ним, могут возникать различные трудности. Перед тем, как обращаться к разработчику, DevOps-у или коллеге-тестировщику, проверьте эти пункты, возможно, проблема на вашей стороне. А даже если не на вашей, вы точнее определите проблему 😊

1. Пропали топики (раньше топики отображались, а теперь нет, хотя параметры подключения не менялись)

Финансы, ритейл, соцсети, облака – везде свои тараканы, но требования схожи: чтобы летало и не падало. Балансировка нагрузки – это как фундамент для небоскреба. Криво зальешь – все рухнет. И вот тут стандартный Round Robin, при всей его простоте, часто оказывается тем самым кривым фундаментом.

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной ACID-транзакцией: либо все операции выполняются успешно, либо при ошибке происходит полный откат. В мире микросервисов такой прямолинейный подход не работает. Каждый сервис автономен, у каждого своя база данных, и общаются они через сеть. Как результат, гарантировать атомарность и целостность процессов, охватывающих несколько сервисов, непросто. Возникает риск частичных обновлений: одна часть системы изменилась, а другая – нет, что приводит к неконсистентным (несогласованным) состояниям данных.

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

Всё началось с того, что в 2024 году мне в руки попал интересный экземпляр мини-ПК ( Характеристики: Процессор Intel N100 / RAM 16 GB / SSD 500 GB.) решив, что раз уж основная рабочая лошадка у меня уже есть, этот мики-ПК предстоит переделать в мини-сервер и приспособить к мои pet-проектам. Заказал себе 1Гбит интернет, белый IP адрес и ушел творить.

Первая моя задумка с треком провалилась, т.к изначально я разместил на нем Gitlab Server, NextCloud и пару своих приложений. «Жужжал» он не по-детски, я взаправду подумал, что в какой-то момент он просто отлетит к своим небесным производителям.

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

В данной статье мы разберем несколько ключевых паттернов, связанных с микросервисами. Речь пойдет о паттернах миграции и интеграции (таких как Strangler Fig – «удушающее дерево» и API Gateway), о сетевых и структурных паттернах (Service Mesh, Sidecar), о шаблонах работы с данными (Database per Service, CQRS) и об особом подходе к хранению состояния (Event Sourcing). Для каждого паттерна мы рассмотрим его суть, назначение, примеры использования, а также плюсы и возможные сложности. К некоторым паттернам приведены упрощенные диаграммы и фрагменты кода, чтобы иллюстративно показать, как они работают на практике.

В этой статье мы сделаем небольшой экскурс в эволюцию архитектурных подходов – от классического шаблона MVC, популярного на начальных стадиях разработки, до более современных решений, таких как SOA, DDD, Modular Monolith и микросервисы.

Наша цель – показать, как переход от одной архитектуры к другой может решить проблемы поддержки, тестирования и масштабируемости. А также дать рекомендации по выбору оптимального решения в зависимости от требований проекта.