Этап 0Б. Мост к архитектуре: для системного аналитика уровня middle

Для кого. Для системного аналитика уровня middle: пишет постановки, описывает API и интеграции, знает SQL. Но сеть, криптография, транзакции, брокеры и устройство распределённых систем пока известны «снаружи», по названиям. Этап 0А для такого читателя можно пропустить или пройти выборочно по входному тесту.

Этап закрывает пробелы между «умею описать интеграцию» и «понимаю, как она работает и почему ломается». Каждый модуль даёт каркас, на который потом ложатся блоки 1–3 основной программы: сеть — под HTTP и балансировщики, криптография — под TLS и OAuth, транзакции — под PostgreSQL изнутри, брокеры и распределённые системы — под микросервисы. Уроки короче по охвату, чем в основной программе, но уже про механизмы, а не про определения.

# Модуль Неделя этапа
Б.1 Сеть для интеграций: IP, порты, DNS, TCP, прокси 1
Б.2 Основы безопасности: криптография, аутентификация, авторизация 2
Б.3 Проектирование контракта API: ресурсы, OpenAPI, ошибки, совместимость 3
Б.4 SQL глубже и транзакции: оконные функции, индексы, EXPLAIN, конкурентность 4–5
Б.5 Асинхронный обмен: очереди, брокеры, гарантии доставки 6
Б.6 Архитектура приложения: слои, монолит и сервисы, инфраструктура 7
Б.7 Описание решения: спецификация интеграции, диаграммы, нефункциональные требования 8
Б.8 Распределённые системы: базовые понятия 9

Входной тест

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

  1. Что происходит на уровне сети между вызовом https://api.partner.example и первым байтом ответа?
  2. Чем подпись отличается от шифрования, а аутентификация — от авторизации?
  3. Как спроектировать пагинацию и формат ошибок REST API и как менять контракт, не ломая клиентов?
  4. Что такое транзакция, какие проблемы возникают при одновременных изменениях и что показывает EXPLAIN?
  5. Что значит «доставка хотя бы один раз» и что должен делать получатель сообщения?
  6. Чем модульный монолит отличается от микросервисов и где в системе стоят балансировщик, кэш и API Gateway?
  7. Как описать интеграцию так, чтобы разработчик и тестировщик поняли и основной, и аварийные сценарии?
  8. Почему в распределённой системе нельзя отличить медленный сервис от упавшего?

Главные источники

  • Мартин Клеппман, «Высоконагруженные приложения» (Designing Data-Intensive Applications) — главы 1–3, 5, 7, 8, 11 как фон ко всему этапу.
  • Джеймс Куроуз, Кит Росс, «Компьютерные сети. Нисходящий подход» — главы о прикладном и транспортном уровнях.
  • David Wong, Real-World Cryptography (2021) — прикладная криптография без математики.
  • Арно Лоре, «Проектирование веб-API» (The Design of Web APIs).
  • Сэм Ньюмен, «Создание микросервисов» (2-е изд.) — главы 1–5.

Критерий завершения этапа

Взять одну интеграцию из своей практики (обезличенно) и подготовить её разбор: схема сетевого пути от клиента до базы данных с указанием, где терминируется TLS и где стоят балансировщики; способ аутентификации; контракт в OpenAPI; обработка сбоев и повторов; транзакционные границы; диаграмма последовательности для основного и одного аварийного сценария. Разбор должен отвечать на вопрос «что произойдёт, если каждый из участников станет недоступен или медленным».

Table of contents