Нюансы проектирования распределенных систем
Почему в нашей платформе роль API Gateway по-прежнему выполняет Apache APISIX, хотя альтернатив на рынке хватает?
В этой статье без долгих рассуждений разбираю наш выбор: какие требования были у платформы, как мы проверяли кандидатов, где возникали спорные моменты и почему в итоге остановились на связке APISIX, OIDC, Keycloak и OPA.
Агент «Исследовать» в Алисе AI может работать до 20 минут. За это время он успевает обойти десятки сайтов, запустить модели, вызвать инструменты — и сделать всё это параллельно на нескольких хостах. И если в середине цепочки что-то упадёт (а практика показывает, что если может упасть — когда-нибудь упадёт: релизы, сети, «луна не в той фазе»), агент должен уметь продолжить работу с того же места, а не начать всё заново, сжигая часы и LLM-токены. Ещё год назад никакой инфраструктуры для этого у нас не было.
Меня зовут Алексей Логинов, я ведущий разработчик в команде, которая отвечает за инфраструктуру нашего ассистента. В этой статье я покажу, какой путь мы прошли от наивного SDK до полноценной платформы Agent Transport System (ATS) — и как при этом упирались в различные ограничения и преодолевали их.
В ИТ любят слово «отказоустойчивость». Оно звучит инженерно и успокаивающе. Кластеры, зеркала, репликации — всё это создаёт ощущение контролируемости. Но последние десять лет показали неприятную вещь: большинство катастроф происходят не потому, что что-то сломалось, а потому что инфраструктуру целенаправленно уничтожили. Бла-бла-бла.
В данной статье, я расскажу о том, как возможно DDD сейчас обретает своё третье перерождение. Первое в 2003 году, по выходу книги, второе с выходом микросервисов и пониманием гранулярности, и последний - с развитием ИИ.
В этой статье я расскажу о том, как не заниматься боллерплейтом вообще, сконцентрировавшись больше на дискаверинге, как получить дюжину готовых микросервисов за считанные часы. Вас ждёт генезис, фактура и исходники, рассказ как это можно применять. И возможно, DDD больше не будет элитарным, а кризис мы сможем считать преодолённым.
То, что найм в IT сломался - понятно всем. А что же на самом деле происходит? И что делать? Можно пытаться играть в эту игру - кто кого удачнее обманет. Давайте подумаем куда это может завести. И может есть другой путь?
Docker Swarm предоставляет встроенный механизм управления секретами: пароли, ключи API и сертификаты передаются в контейнеры через зашифрованный канал и монтируются в /run/secrets/. Звучит безопасно — пока вы не осознаете, что любой пользователь с доступом к docker exec может прочитать эти секреты в любой момент жизни контейнера.
В этой статье я разберу, почему стандартные способы защиты не работают, и покажу решение на основе именованных каналов (FIFO), которое позволяет секрету быть прочитанным ровно один раз — при старте приложения.
В билетном сервисе сразу несколько сложных задач: нужно исключить double booking, обновлять карту мест в реальном времени и выдерживать read-heavy нагрузку на каталог событий. Разберём архитектуру системы и ключевые технические компромиссы.
Всем привет, меня зовут Кирилл Вересников, я бэкенд-разработчик в iSpring.
Мы делаем iSpring LMS — платформу для корпоративного онлайн-обучения. Исторически это был модульный монолит на PHP, а затем система начала постепенно дополняться микросервисами. Самые нагруженные и часто меняющиеся части мы выносили из монолита, а новый функционал всё чаще сразу делали в микросервисах.
Эта статья будет полезна тем, кто:
- постепенно выносит части монолита в сервисы;
- устал от старых nginx-конфигов, которые годами копились ради обратной совместимости;
- ищет способ стандартизировать входной трафик и убрать бизнес-логику из прокси;
- выбирает между nginx и envoy.
Недавно ходил в кино и, пока стоял в очереди на вход, поймал себя на мысли, что проектирую систему, которой пользуется контролер. На первый взгляд задача примитивная: есть база билетов, контролер сканирует QR, система должна проверить билет и пустить человека. Главное условие - один билет используется ровно один раз.
Я прикинул, и понял, что проблем там гораздо больше, чем кажется ..
Чем покупка букета на 8 Марта через Яндекс Еду отличается от покупки, собственно, еды? С точки зрения пользователя — ничем. Выбрал, оплатил, доставили. А вот с точки зрения разработчика бэкенда заказ уникальных букетов превращается в нетривиальную инженерную задачу синхронизации складских запасов. Задержка синхронизации хотя бы в 10 минут трансформируется в звонок и сборщиков заказов, сообщающих о том, что именно такого букета на складе больше нет.
Меня зовут Виталий Московкин, я занимаюсь ритейлом в Яндекс Еде. В статье я расскажу, как мы синхронизировали состояние складов с 18 миллионами уникальных товаров: сначала с помощью PostgreSQL, а затем с помощью YDB. Такое количество товаров превращается на бэкенде в 4 миллиарда записей о ценах и стоках, которые нельзя просто так кешировать. Но и замена монолитной СУБД на распределённую тоже задача не на десять минут. Подробности — под катом.
Синхронные вызовы кажутся простыми и знакомыми, пока не превращаются в цепочки, которые рушат всю систему. Событийная архитектура выглядит элегантно, но таит подводные камни: что класть в событие? как быть с долгими операциями?
В статье вы найдёте:
▫️ живые примеры из реальных аварий (включая историю с бесконечными ретраями в очереди),
▫️ три готовые диаграммы в формате Mermaid, которые можно сразу использовать в документации,
▫️ чёткий алгоритм выбора стиля под вашу задачу.
Материал будет полезен архитекторам, ведущим разработчикам и всем, кто проектирует распределённые системы. Покажу, как не повторять ошибок, которые стоили компаниям миллионов.
За свой многолетний опыт я не встречал основательного подхода к логам приложений.
Часто я слышал фразы: "что нужны логи", "логи плохие" и т.д.
Но они слишком общие и могут означать все и ничего одновременно.
Предлагаю детально разобраться, как именно можно писать логи в этой статье.
Привет! Меня зовут Дмитрий Ивахненко из команды Автономного транспорта Яндекса. В этой статье я подробно разберу, как устроены сервисы удалённого управления автономными юнитами — роботакси, роботами‑доставщиками и грузовиками.
Реальный мир полон нестандартных ситуаций, в которых даже самые совершенные алгоритмы могут встретить сложности: внезапно появившееся препятствие, сбой датчиков, сложные погодные условия. В этих случаях важно обеспечить безопасность, бесперебойную работу и предсказуемое поведение техники. Для этого и нужны операторы и системы удалённого управления — они «подстраховывают» автономные устройства.
Под катом — архитектурные решения и инструменты, которые позволили сделать весь процесс удалённой помощи масштабируемым, надёжным и эффективным.
Всем привет! Подытоживаю поиски решения, которые команда стартапа MyBox из Мастерской IT.ru вела с участием Хабра и независимых сообществ.
Задача от лидера продукта Вовы была такая: нужно заставить macOS предоставить удалённому узлу (через сеть, внутри одной машины проблем нет) подписанный Apple «аттестат», подтверждающий, что на устройстве запущено приложение с конкретным хешем бинарника. При этом macOS должна работать в режиме полной безопасности (SIP включён, приватные API не используются, понижение защиты не допускается). Детальнее в прошлой статье: https://habr.com/ru/articles/1006814/.
Накопили мешок не сработавших идей, собрали аргументацию от профи, почему рабочего решения не существует, и главное - пришли к гипотезе альтернативного архитектурного решения для продукта.
Когда у компании много сервисов и данных, то лучше всего иметь план Б на любую ситуацию, например когда нужно быстро оптимизировать ресурсы и работать в режиме «минус один дата‑центр» без просадок, в то время как утилизация серверов при этом стремится к 100%. Смертельный номер? Вполне посильная задача, с которой справилась команда Яндекс Go.
Мы провели аудит и поняли, что у нас очень много синхронных походов из критичных сервисов в некритичные, а ещё и поллинг. И это требовало внедрения событийной модели. Тысяча микросервисов, 150 команд разработки, несколько языков программирования, и у каждого разработчика своё представление о том, как правильно читать сообщения из Kafka. Библиотека, которую мы раздали командам, быстро бы обросла форками, заплатками и костылями.
За шесть месяцев командой из шести человек мы превратили эту библиотеку в централизованную платформу Немезида. Сейчас на ней крутится больше 500 интеграций, а новую можно запустить меньше чем за четыре часа.
Меня зовут Алексей Терентьев, я руководитель одной из служб отдела эффективности Яндекс Go. В этой статье я расскажу, как мы прошли путь от простого «прочитал — обработал — закоммитил» к по‑настоящему масштабной архитектуре: со всеми граблями, факапами и конкретными решениями.
Привет, Хабр! Я — Сева, разработчик в Yandex Infrastructure. Уже больше десяти лет я занимаюсь разработкой внутреннего облака Яндекса, которое охватывает около 150 000 физических хостов и поддерживает все сервисы платформы.
Сегодня я представлю вам практический кейс по обеспечению очень высокой надёжности комплексной системы на примере собственного облака Яндекса. Принципы обеспечения надёжности будут продемонстрированы на всех уровнях архитектуры системы, чтобы в итоге сложилась картина, как достичь наивысшей отказоустойчивости. Статья написана по мотивам моего доклада для HighLoad++.
В последнее время из общего ИИ-пузыря выделилось несколько хайповых тем:
• автономные ИИ-агенты и другие инструменты, которые якобы помогают человеку выполнять рутинные задачи и экономить время (это обман, на самом деле всё наоборот: загруженность человека с ИИ сильно возрастает — увеличивается интенсивность труда, усталость, риски выгорания и требования к производительности),
• частные облака для «локального» инференса,
• децентрализованный ИИ, который будет работать на компьютерах пользователей.
С агентами всё понятно, а вот частные облака и P2P-суперинтеллект можно рассмотреть внимательнее.
Допустим, вы — типичный обитатель этого ресурса. Сидите по 10 часов перед экраном, компенсируете магнием и омегой-3, мониторите HRV через Oura или Apple Watch, слушаете Хабермана, ходите в зал три раза в неделю, спите по трекеру. Вы, возможно, даже знаете, что такое глимфатическая система и зачем нужен глубокий сон. И всё равно — что-то не складывается. Может энергии не хватает, или шея хронически зажата, сон нестабилен, тревога фоновая, а последний ОРВИ длился три недели вместо пяти дней.
Знакомо? Тогда у меня для вас новость: вы дебажите симптомы, а не архитектуру.
Современный биохакинг — это попытка чинить систему перебором драйверов. Для обычного пользователя — нормальная стратегия. Но вы же не обычные пользователи. Вы — люди, которые умеют читать логи, понимают, что такое архитектура, и знают, что перебор драйверов без понимания, какая подсистема сбоит, — это не дебаг, а карго-культ. Так вот: у организма есть архитектура. И её можно описать.
Я потратил изрядное количество времени на то, чтобы собрать воедино результаты шести независимых областей нейронауки, которые последние 30 лет, каждая по-своему, приходят к одному и тому же выводу: информационные состояния высшего порядка реально, измеримо, через конкретные биохимические каскады влияют на физиологию. И написал научную статью (PDF на английском), в которой эти разрозненные наблюдения собраны в единый фреймворк.
Эта статья на Хабре — попытка рассказать о том же самом человеческим языком, с IT-аналогиями, практическими выводами и без единой мантры.
«Сделайте нам строго по порядку» — эта фраза из бизнес‑требований часто становится началом долгого и дорогого инженерного триллера. В мире микросервисов и event‑driven систем классический FIFO превращается из простой очереди в проверку на прочность всей архитектуры. За обещанием «строгой последовательности» стоят сетевые задержки, алгоритмы консенсуса и суровые ограничения распределенных систем.
Привет, Хабр! Пишу от лица Мастерской IT.ru по запросу команды MyBox и ее лидера Вовы. Ребята столкнулись с задачей, которая тяжко решается - так что предлагаем ее спецам с Хабра за, естественно, награду. Подарим Mac Mini на 1 ТБ SSD за успешное решение.
Что за задача?
Есть проект MyBox - защищенное персональное облако на базе Apple Mac mini. Устройство должно уметь предоставить удалённому узлу подписанный Apple «аттестат», подтверждающий, что на устройстве запущено приложение с конкретным хешем бинарника.