Mind Map

System Design. Подготовка к сложному интервью - Глава 5 - Консистентное хэширование

System Design. Подготовка к сложному интервью - Глава 5 - Консистентное хэширование

Переводы: EN
Консистентное хеширование является краеугольной технологией для распределенных систем. Многие разработчики программного обеспечения этого не осознают, но консистентное хеширование необходимо во многих местах: балансировщики нагрузки, кэши, CDN, генераторы id, базы данных, чаты/социальные сети и многие другие системы. Эта тема состоит из: Проблема с перехешированием и почему нам нужно, чтобы хеширование было ПОСЛЕДОВАТЕЛЬНЫМ Хэш-пространство и хэш-кольцо БАЗОВЫЙ подход (введенный Каргером и др. в MIT) Расширенный подход с ВИРТУАЛЬНЫМИ УЗЛАМИ Эти моменты раскрыты в очень интересной главе 5 книги:
System Design. Подготовка к сложному интервью - Глава 4 - Проектирование ограничителя трафика

System Design. Подготовка к сложному интервью - Глава 4 - Проектирование ограничителя трафика

Переводы: EN
Каждое популярное программное обеспечение должно иметь ограничитель трафика. Это предотвращает DDOS-атаку, снижает затраты и предотвращает перегрузку серверов. Есть несколько каверзных вопросов, которые необходимо учитывать при внедрении ограничителя трафика: Где поставить ограничитель трафика: на стороне клиента, на стороне сервера, на шлюзе? Алгоритмы ограничения скорости. Есть много алгоритмов со своими плюсами и минусами: Token Bucket, Leaking Bucket, Fixed window counter, Sliding window log, Sliding window counter. Особенности вашего бизнеса определят правильный алгоритм.
System Design. Подготовка к сложному интервью - Глава 3 - Общие принципы прохождения интервью по проектированию ИТ-систем

System Design. Подготовка к сложному интервью - Глава 3 - Общие принципы прохождения интервью по проектированию ИТ-систем

Переводы: EN
Четыре стандартных этапа собеседования по проектированию ИТ-систем. Однако я бы думал о них шире: как о четырех начальных шагах проектирования любого ПО. Шаг 1. Понимание проблемы и определение скоупа проектирования Шаг 2. Предложите дизайн высокого уровня и получите одобрение Шаг 3. Спроектируйте глубокое погружение Шаг 4. Завершение Глава 3 книги раскрывает подробности о каждом шаге, хорошие вопросы, которые нужно задать (над которыми следует подумать), а также то, что НУЖНО и НЕЛЬЗЯ делать.
System Design. Подготовка к сложному интервью - Глава 2 - Приблизительные оценки

System Design. Подготовка к сложному интервью - Глава 2 - Приблизительные оценки

Переводы: EN
Очень короткая глава 2 посвящена тому, как делать приблизительные оценки, чтобы начать с самых важных моментов при разработке программного обеспечения. Концепции, которые должен знать КАЖДЫЙ разработчик программного обеспечения: “Сила двух” Стандартные цифры задержки! Насколько быстрой является память, насколько медленным является диск и т.д. Показатели доступности Про какие ключевые метрики стоит думать Эти понятия и числа раскрыты во второй главе книги: “System Design. Подготовка к сложному интервью” Алекса Сюй.
System Design. Подготовка к сложному интервью - Глава 1 - Масштабирование от нуля до миллионов пользователей

System Design. Подготовка к сложному интервью - Глава 1 - Масштабирование от нуля до миллионов пользователей

Переводы: EN
Отличный общий план для масштабирования любого приложения с нуля до миллионов пользователей. Настройка одного сервера Выбор и использование базы данных Вертикальное масштабирование против горизонтального масштабирования подходов. И почему вы должны предпочесть горизонтальный Добавлен балансировщик нагрузки для горизонтального масштабирования Добавление репликации базы данных для горизонтального масштабирования Добавление кеша Добавление CDN Архитектура без сохранения состояния и с сохранением состояния и использование внешнего хранилища состояния Добавление дополнительных центров обработки данных Добавление очереди сообщений Добавление ведения журнала, метрик и автоматизации Масштабирование базы данных и дальнейшие шаги… Все это тщательно, но кратко раскрыто в Главе 1 книги:
Создание событийно-управляемых микросервисов - Глава 16 - Развертывание событийно-управляемых микросервисов

Создание событийно-управляемых микросервисов - Глава 16 - Развертывание событийно-управляемых микросервисов

Переводы: EN
Принципы развертывания микросервисов Различия между непрерывной интеграцией (CI), непрерывной доставкой и непрерывным развертыванием. Шаблоны развертывания: Базовый шаблон полного развертывания Шаблон непрерывного обновления Паттерн изменения схемы прерывания: здесь два варианта - окончательная миграция и синхронизированная миграция. Сине-зеленый шаблон развертывания Все это раскрыто в главе 16 книги: “Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare Делюсь своей ментальной картой со всеми подробностями, как обычно:
Создание событийно-управляемых микросервисов - Глава 15 - Тестирование событийно-управляемых микросервисов

Создание событийно-управляемых микросервисов - Глава 15 - Тестирование событийно-управляемых микросервисов

Переводы: EN
Тестирование событийно-ориентированных решений — сложная задача. Это включает в себя: Общие принципы Модульное тестирование: без сохранения состояния и с сохранением состояния Тестирование топологии (держу пари, вы этого не делали! ;) Тестирование эволюции схемы и совместимости Интеграционное тестирование: локальное, удаленное и гибридное - набор соображений здравого смысла, о которых нельзя забывать. Выбор стратегии тестирования Все это раскрыто в главе 15 книги: “Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare
Создание событийно-управляемых микросервисов - Глава 14 - Вспомогательные инструменты

Создание событийно-управляемых микросервисов - Глава 14 - Вспомогательные инструменты

Переводы: EN
Довольно часто инструменты забывают в начале разработки. В этой главе не рассматриваются инструменты, помогающие создавать и поддерживать управляемые событиями микросервисы. Полезный чек-лист! Эта тема включает в себя: Правила организации Документация, маркировка Квоты Схема реестра Управление смещением список контроля доступа Управление состоянием и сброс приложения Мониторинг задержки смещения потребителя Элементы управления контейнером Создание кластера и управление им Отслеживание зависимостей Все это раскрыто в главе 14 книги: “Создание событийно-управляемых микросервисов” Адама Беллемара.
Создание событийно-управляемых микросервисов - Глава 13 - Интегрирование событийно-управляемых микросервисов с микросервисами типа «запрос-ответ»

Создание событийно-управляемых микросервисов - Глава 13 - Интегрирование событийно-управляемых микросервисов с микросервисами типа «запрос-ответ»

Переводы: EN
Как интегрировать микросервисы, управляемые событиями, с API-интерфейсами типа «запрос-ответ»? Существует два типа внешних событий: Автономно генерируемые события (аналитические события) Реактивно генерируемые события (события от запроса-ответа) Существует два подхода к обработке и обслуживанию запросов с использованием сервисов с отслеживанием состояния: использование внутренних хранилищ состояний (с глупой или умной маршрутизацией) использование внешних хранилищ состояний (с обычным или с составным микросервисом) Способы обработки запросов в рамках управляемого событиями рабочего процесса:
Создание событийно-управляемых микросервисов - Глава 12 - Легковесные фреймворки потоковой обработки

Создание событийно-управляемых микросервисов - Глава 12 - Легковесные фреймворки потоковой обработки

Переводы: EN
Четвертый шаблон для создания микросервисов — использование легковесных фреймворков. Легковесные фреймворки предоставляют функциональность, аналогичную тяжеловесным фреймворкам, но они в значительной степени зависят от: брокера событий системы управления контейнерами (CMS) Во многих случаях они превосходят тяжеловесные фреймворки. Различные приложения могут использовать любые/разные ресурсы из кластера, которые лучше соответствуют их потребностям. При этом по-прежнему обеспечивают масштабирование и восстановление после сбоев (опять же, сильно полагаясь на брокера событий и CMS). К сожалению, на данный момент есть только два полнофункциональных варианта: