Распределённые системы *

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

Тогда я видел в этом проблему. Сейчас я понимаю, что это было диагнозом, а не приговором. Дороговизна DDD — не случайность и не злой умысел коучей. Это объективное следствие того, что 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 «аттестат», подтверждающий, что на устройстве запущено приложение с конкретным хешем бинарника.

«Значит, смотрите. Payment-service ходит в booking-service, но только через API gateway, который дёргает auth-service, а тот валидирует токен в Redis, который шарит с notification-service…» — вы, объясняя архитектуру новому разработчику.

Десять лет мы разматывали нитки между сервисами на доске, как Чарли из «В Филадельфии». 42% компаний уже тихо сворачивают микросервисы обратно. Istio не осилил микросервисную архитектуру собственного control plane. Бывший CTO GitHub называет это «главной архитектурной ошибкой десятилетия».

А потом пришёл AI, которому не нужны ни митинг на 15 человек, ни три года в проекте, чтобы понять, почему бронирование — это цепочка из 12 HTTP-вызовов вместо одного function call.

Разбираю шесть причин дробления монолитов. Спойлер: половину из них AI уже отменил.

Почему современные агентные системы остаются централизованными, даже когда выглядят как «рои» — и зачем для автономных ИИ нужен децентрализованный протокол.

Этот текст основан на спецификации HMP v5.0 (HyperCortex Mesh Protocol) — открытой спецификации протокола для взаимодействия автономных ИИ-агентов в децентрализованной среде.
Статья не описывает готовую систему, а формулирует архитектурные принципы и проектные допущения.

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

При этом по духу HMP ближе к системам работы с артефактами (таким как IPFS) и федеративным протоколам взаимодействия (например, ActivityPub), однако он решает иную задачу — координацию автономных когнитивных агентов без навязывания модели мышления или формата знаний.

Привет, Хабр! Меня зовут Сергей, я работаю в компании InfoWatch разработчиком на продукте ARMA Стена (NGFW). Подробнее о том, что такое ARMA Стена, можно прочитать тут.

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

Сразу оговорюсь, что в статье используется TLA+, без введения в инструмент, чтобы не увеличивать объём статьи. Подробнее про инструмент вы можете почитать на сайте создателя, тут и тут. Необходимые объяснения даются по ходу изложения.

Статья состоит из двух частей:

1) Что такое формальная верификация и где она применятся

2) Решение бизнес-задачи в NGFW