В 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 и микросервисы.
Наша цель – показать, как переход от одной архитектуры к другой может решить проблемы поддержки, тестирования и масштабируемости. А также дать рекомендации по выбору оптимального решения в зависимости от требований проекта.
Привет, Хабр! Меня зовут Андрей Бирюков, я СTO Сервисной цифровой платформы в Газпромбанке. За свою карьеру поработал в нескольких компаниях — от стартапов до крупных корпораций — и видел разные архитектурные подходы.
И вот начала копиться усталость от обсуждения, что использовать — монолиты или микросервисы. Этот вопрос стал преследовать меня на конференциях, в офисе, в личных сообщениях. Я потратил столько времени на обсуждение этой темы, что иногда хочется просто распечатать какой-нибудь емкий ответ на футболке и ходить в ней на все митапы.
Шутки шутками, но тема действительно важная. Я прошел путь от классических монолитных приложений до сложных микросервисных, проектировал системы, которые работают под большой нагрузкой, и пришел к выводу, что однозначного ответа здесь не существует. И вообще, «монолит или микросервисы» — это неправильная постановка вопроса.
Недавно сходил c Витей на запись подкаста на эту тему и настолько преисполнился, что решил в текстовом виде формализировать свое отношение к теме (я гнался за вами три дня, чтобы сказать, как вы мне безразличны, ага), обобщить то, о чем говорили, и попытаться дать ответ на вопрос «когда микросервисы действительно помогают и как не сойти с ума, если вы с ними работаете». Порассуждаю о проектировании, поддержке, DevOps-культуре и попробую немного заглянуть в микросервисную архитектуру.
В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.
Исследование принципов Domain-driven Design (DDD) на примере кейса "Аутсорсинг"
Статья демонстрирует эволюцию от простой анемичной доменной модели к сложному решению в стиле DDD, охватывая ключевые концепции, такие как единый язык, ограниченный контекст, агрегаты и доменные события.
Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?
Я опущу длительные рассуждения и представлю свою "поваренную книгу"
Привет, Хабр! Иногда кажется, что если выдернуть кабель, то всё будет безопасно. Но в современном мире даже воздух может быть каналом атаки. Как же тогда правильно изолировать сеть? Разбираемся.
Вас не удивило, что проблема 1970-х — высокая сцепленность кода — дожила до 2010-го и способствовала изобретению микросервисов? Если так, то вы не удивитесь и узнав, что микросервисы тоже её не решили. Сегодня индустрия относится к ним скептически. За последние десять лет мы поняли, что они не стали панацеей. Архитекторы в мире IT — это не учёные, и даже не художники. Это шаманы. Удачно разбить систему на несцепленные части было сложно в 1970-е, сложно и сейчас.
При этом микросервисы привносят проблемы, которых не было в монолитных приложениях.
Всем привет! Сегодня хочется поговорить про механизм распространения контекста трассировки в OpenTelemetry. Разберем, как он работает, и посмотрим простой пример на Go. Всё — коротко и по делу!
Меня зовут Носорев Константин, я backend-разработчик в Яндекс Пей, автор канала "Константин про IT" и просто любознательный инженер.
Привет, Хабр!
Это вторая часть статьи о Kafka (первая тут). Давайте продолжим разбираться.
Итак, часто тестирование сводится к эмуляции работы сервиса и наблюдением за топиками кафки. Для этого необходимо подключиться к кластеру кафки с теми же правами доступа, что и у вашего сервиса либо сервиса, с которым у вас интеграция (креды для кластера обычно подсказывают коллеги-разработчики, девопсы, тестировщики)...
Современные решения, построенные на микросервисной архитектуре, напоминают сложный организм: сотни взаимосвязанных компонентов, распределенные базы данных, облачные сервисы. Без продуманного наблюдения даже мелкая ошибка в одном узле может спровоцировать цепную реакцию — например, падение конверсии из-за «зависшего» платежного шлюза или потерю данных из-за перегруженной очереди сообщений.
Грамотная стратегия мониторинга решает три ключевые проблемы:
В мобильную разработку приходят различными путями. Некоторые рождаются с девайсом в руках, других ведет извилистая дорога вдоль серверов, майнфреймов, дестопных приложений. Но каждый кто в нее попадает ощущает свою незащищенность с тыла, если нет надежного партнера в лице бэкенд ‑разработчика. И, буквально, каждый мобильщик ожидает, что необходимый API будет готов хотя бы за один спринт, до того, как в нем возникнет необходимость. Конечно же, мир IT разработки редко допускает такую роскошь — за нее требуется бороться с ПМ и бизнес‑аналитиком. К тому же не редки ситуации, когда то, что должно быть сделано «на вчера», будет готово «на послезавтра». Те кто имеют достаточно опыта как в наземном, так и подземном мире — берут инициативу с свои руки, и сами предлагают клиент‑серверный интерфейс.
Для мобильного мира C# и Java — падения из рая в ад — это довольно естественный процесс, поскольку присущие им платформы изначально целились на поддержку темных сил бэкенда. То ли дело Swift — познавшему небо — не легко дается жизнь на льдине, вместе с ластоногими.
Получить лучшее из обоих миров, и не потерять темп позволяют некоторые экзотические решения, наподобие Perfect и Vapor. Однако, они в большей степени отвечают на вопрос «Как?» вместо того, чтоб предложить какое‑нибудь удовлетворительное минимальное решение. С другой стороны, как правило, исходные требования мобильной команды довольно умерены и стереотипны от одного приложения к другому. Обычно требуется поддержка и управления такими сущностями как аккаунт пользователя, профиль, продукт и изображения.
