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

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

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

Привет! Меня зовут Геннадий, я руковожу командой разработки системы учета товаров в 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. Пропали топики (раньше топики отображались, а теперь нет, хотя параметры подключения не менялись)

Переход от монолита к микросервисной архитектуре приносит гибкость и масштабируемость, но и создает новые сложности. Одна из ключевых проблем –согласованность данных и транзакции. В монолите обычно можно обернуть несколько операций одной 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 и микросервисы.

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

Привет, Хабр! Меня зовут Андрей Бирюков, я СTO Сервисной цифровой платформы в Газпромбанке. За свою карьеру поработал в нескольких компаниях — от стартапов до крупных корпораций — и видел разные архитектурные подходы.

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

Шутки шутками, но тема действительно важная. Я прошел путь от классических монолитных приложений до сложных микросервисных, проектировал системы, которые работают под большой нагрузкой, и пришел к выводу, что однозначного ответа здесь не существует. И вообще, «монолит или микросервисы» — это неправильная постановка вопроса. 

Недавно сходил c Витей на запись подкаста на эту тему и настолько преисполнился, что  решил в текстовом виде формализировать свое отношение к теме (я гнался за вами три дня, чтобы сказать, как вы мне безразличны, ага), обобщить то, о чем говорили, и попытаться дать ответ на вопрос «когда микросервисы действительно помогают и как не сойти с ума, если вы с ними работаете». Порассуждаю о проектировании, поддержке, DevOps-культуре и попробую немного заглянуть в микросервисную архитектуру.

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

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

Исследование принципов Domain-driven Design (DDD) на примере кейса "Аутсорсинг"

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

Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?

Я опущу длительные рассуждения и представлю свою "поваренную книгу"

Привет, Хабр! Иногда кажется, что если выдернуть кабель, то всё будет безопасно. Но в современном мире даже воздух может быть каналом атаки. Как же тогда правильно изолировать сеть? Разбираемся.