Проектирование распределённых систем

С чего начинается проектирование системы: не с выбора технологий, а с требований и порядков величин. Модуль вводит рамку — функциональные и нефункциональные требования, оценка нагрузки и объёма данных «на салфетке» — и показывает, что дизайн системы это последовательность решений с ценой, а не схема из прямоугольников.

1. Что такое проектирование систем
2. Требования и оценка нагрузки

Четыре вопроса, на которые система обязана отвечать до выбора любой технологии: выдержит ли рост нагрузки, останется ли доступной при отказе, будут ли ответы правильными и как согласовать копии данных. Модуль вводит метрики, которыми это измеряют, и предел, который накладывает распределённость.

1. Масштабируемость и узкое место
2. Доступность, избыточность и переключение на резерв
3. Надёжность: система отвечает правильно
4. Единая точка отказа и радиус поражения
5. Задержка, пропускная способность и полоса
6. Теорема CAP: поведение при разрыве сети
7. Модели согласованности как контракт чтения
8. Согласованное хеширование

Что происходит между вызовом в коде и ответом сервера: слои сети и адресация, выбор между надёжным и быстрым транспортом, семантика HTTP и защищённое соединение, разрешение имени в адрес и посредники на пути запроса. Модуль даёт минимум сети, без которого нельзя объяснить задержку, таймаут и поведение балансировщика.

1. Слои сети и адресация
2. TCP против UDP: гарантии против задержки
3. Семантика HTTP и защищённое соединение
4. Разрешение имён и кэш DNS
5. Прямой и обратный прокси
6. Контрольные суммы и целостность данных

Как запрос находит один из многих одинаковых экземпляров сервиса: балансировщик и проверки здоровья, алгоритмы раскладки нагрузки и распределение трафика ещё до соединения — через DNS и маршрутизацию. Модуль показывает, что балансировщик решает не только «куда», но и «что делать, когда экземпляр нездоров».

1. Балансировщик и проверки здоровья
2. Алгоритмы раскладки нагрузки
3. Распределение трафика до соединения

Интерфейс сервиса — это обещание, которое дорого менять: стиль взаимодействия, формат сообщения, поведение при повторе запроса, защита от перегрузки и общая точка входа для клиентов. Модуль разбирает, как выбирают стиль API под задачу и какие свойства контракта определяют устойчивость системы, а не удобство разработчика.

1. API как контракт
2. Стили взаимодействия и выбор между ними
3. Проектирование ресурсного API
4. Бинарные контракты и схема сообщения
5. Запрос по графу данных
6. Идемпотентность и безопасный повтор
7. Ограничение частоты запросов
8. Шлюз API как точка входа
9. Identity в масштабируемой системе

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

1. Синхронный вызов против асинхронного сообщения
2. Очереди сообщений
3. Публикация с подпиской
4. Гарантии доставки и идемпотентный потребитель
5. Очередь необработанных сообщений
6. Поток изменений из базы данных
7. Обратные вызовы по HTTP
8. Длинный опрос и поток событий от сервера
9. Двусторонние соединения
10. Прямое соединение между клиентами

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

1. Слои кэша: где он стоит
2. Выбор стратегии чтения и записи
3. Политики вытеснения
4. Инвалидация и свежесть данных
5. Лавина запросов при промахе
6. Прогрев и холодный старт
7. Сеть доставки контента
8. Распределённый кэш

Хранилище выбирают не по популярности, а по модели доступа к данным: какие запросы должны быть быстрыми, что можно потерять, как данные растут. Модуль разбирает семейства хранилищ и их профили, гарантии транзакций и сохранности записи, а также две структуры на диске, из которых следует, что быстрее — чтение или запись.

1. Как выбирают хранилище
2. Реляционная модель и её гарантии
3. Хранилища ключ-значение
4. Документные хранилища
5. Хранилища широких колонок
6. Графовые хранилища
7. Хранилища временных рядов
8. Векторные хранилища
9. Полнотекстовый поиск
10. Транзакции и гарантии ACID
11. Как база гарантирует сохранность записи
12. Сбалансированное дерево против дерева слияния

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

1. Реплики на чтение и отставание
2. Пул соединений
3. Денормализация и материализованные представления
4. Шардирование и выбор ключа
5. Горизонтальное и вертикальное разбиение
6. Сжатие данных
7. Индекс как компромисс

Где живут файлы, изображения, видео и резервные копии, когда их слишком много для диска одной машины. Модуль разбирает три модели доступа к хранилищу, устройство объектного хранилища, распределённые файловые системы и способ пережить отказ дисков дешевле, чем полными копиями.

1. Блочное, файловое и объектное хранилище
2. Объектное хранилище
3. Распределённые файловые системы
4. Помехоустойчивое кодирование против репликации

Несколько развилок, которые повторяются в любом проектировании: расти вверх или вширь, хранить состояние в сервисе или вынести его, кто инициирует передачу данных — источник или получатель, и чем конкурентное выполнение отличается от параллельного. Модуль собирает эти решения в явные критерии выбора.

1. Рост вверх против роста вширь
2. Состояние в сервисе или вне его
3. Передача по инициативе источника или получателя
4. Конкурентность против параллелизма

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

1. Клиент-сервер и разделение на уровни
2. Монолит
3. Микросервисы
4. Событийная архитектура
5. Хранение событий вместо состояния
6. Разделение моделей чтения и записи
7. Гексагональная архитектура
8. Бессерверные вычисления
9. Обмен между равными узлами

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

1. Шлюз как единая точка входа
2. Отдельный слой под клиента
3. Обнаружение сервисов
4. Размыкатель цепи
5. Изоляция ресурсов по отсекам
6. Вспомогательный контейнер и сетка сервисов
7. Постепенная замена старой системы

Что принципиально меняется, когда вызов пересекает сеть: сообщение может пропасть, узел может быть жив, но недоступен, а часы на машинах расходятся. Модуль разбирает обнаружение отказов, упорядочивание событий без общего времени, выбор ведущего узла и согласие группы узлов на общее решение.

1. Что меняет распределённость
2. Разрыв сети
3. Обнаружение отказов и сигналы жизни
4. Работа с отказами: таймауты, повторы, деградация
5. Расхождение часов
6. Логические часы и порядок событий
7. Векторные часы и конкурентные изменения
8. Выбор ведущего узла
9. Консенсус: согласие группы узлов
10. Консенсус через реплицируемый журнал
11. Классический протокол консенсуса
12. Разделение на две активные половины
13. Распределённые блокировки
14. Протокол сплетен

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

1. Почему распределённая транзакция это дорого
2. Двухфазная фиксация
3. Трёхфазная фиксация
4. Сага и компенсирующие действия
5. Шаблон исходящих сообщений

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

1. Зачем приближённые структуры
2. Фильтр Блума
3. Кукушкин фильтр
4. Счётный эскиз частоты
5. Оценка числа уникальных значений
6. Оценка схожести наборов
7. Дерево хешей
8. Список с пропусками
9. Пространственные индексы
10. Кодирование координат и разбиение сферы

Как считают то, что не помещается в один запрос к базе: обработка накопленным объёмом или непрерывным потоком, распределённое вычисление по узлам, перенос данных в аналитическое хранилище и архитектуры, которые пытаются совместить точность батча со свежестью потока.

1. Пакетная обработка против потоковой
2. Распределённое вычисление по узлам
3. Потоковые движки: окна и состояние
4. Конвейеры переноса и преобразования
5. Аналитическое хранилище
6. Озеро данных и гибридный подход
7. Совмещение точности и свежести

Выкладка новой версии — штатная операция, которая чаще всего и роняет систему. Модуль разбирает стратегии постепенной замены и параллельной среды, выкатку на долю трафика, отделение выкладки кода от включения функции, возврат к прошлой версии и конвейер, который делает всё это повторяемым.

1. Стратегии выкладки и критерий выбора
2. Постепенная замена экземпляров
3. Параллельная среда и переключение
4. Выкатка на долю трафика
5. Флаги функций
6. Откат и неизменяемая инфраструктура
7. Конвейер сборки и доставки

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

1. Три вида телеметрии
2. Метрики и разметка кода
3. Логи: структура, уровни, сбор
4. Распределённая трассировка
5. Сквозной идентификатор запроса
6. Оповещения по симптому
7. Панели и инструкции дежурного

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

1. Защищённое соединение в топологии
2. Шифрование данных на хранении
3. Управление секретами
4. Доступ на основе ролей
5. Корпоративный единый вход
6. Хранение паролей