9 архитектурных заблуждений о распределённых системах
По сути, каждый, кто впервые создаёт распределённое приложение, делает следующие 8 предположений. Все они в конечном итоге оказываются ложными и все приводят к большим проблемам и болезненному опыту.

Это цитата, а сами заблуждения сформулированы более 30 лет назад (1991-1997) и до сих пор актуальны. Авторство приписывают Peter Deutsch и некоторым инженерам из Sun Microsystems.
-
The network is reliable / Сеть надёжна. Думаем о том, как будет совершаться вызов или доставляться сообщение. Обеспечение надёжности передачи можно возложить на внешние механизмы (инфраструктуру, очереди, оркестраторы, outbox и т.п.); и/или самостоятельную реализацию (retries, dead letter, deadline propagation, circuit breakers и т.п.). На этом же уровне думаем о возможной многократной доставке, порядке и идемпотентности обработки.
-
Latency is zero / Нулевая задержка. Думаем, в какой сети происходит взаимодействие: в локальной или глобальной (через горы-моря-океаны). Задержка более проблематична, чем пропускная способность, ведь есть физические ограничения по скорости передачи. Соответственно, стараемся минимизировать количество сетевых взаимодействий; размер передаваемых данных; оптимизируем маршруты, необходимые для выполнения каждого сценария; вспоминаем про кэширование, пакетную обработку и локальность вычислений.
-
Bandwidth is infinite / Неограниченная пропускная способность. Пропускная способность растет, но растут и наши потребности. Вопрос лишь в том, насколько они адекватны. Насколько адекватно, когда сервис возвращает модель из множества атрибутов, но из всех нужен только один? Умножаем размер одного такого сообщения на их количество в секунду и сравниваем полученный результат с пропускной способностью используемой сети, принимая во внимание возможные сетевые потери. Только на оптимизации трафика можно существенно сэкономить и улучшить показатели. Тут можно вспомнить и про бинарные форматы (Avro, Protobuf, MessagePack).
-
The network is secure / Сеть безопасна. С одной стороны, уровень безопасности должен соответствовать уровню возможных угроз. С другой, для атаки всегда пытаются найти самое слабое звено. Поэтому в идеале защита не только по внешнему периметру, но и внутри. Как минимум, стоит задуматься об аутентификации/авторизации запросов, разделении аккаунтов доступа к используемым ресурсам (БД и т.п.). Для себя я нашел очень хорошую шпаргалку по этой теме — OWASP Cheat Sheet Series.
-
Topology doesn’t change / Топология не меняется. После развертывания приложение уже не под вашим контролем. Считаем, что приложение развертывается в дикой и враждебной среде, где узлы появляются и исчезают в случайные моменты времени. Никогда не полагаемся на конкретные маршруты, узлы и IP-адреса; всё должно быть адаптивно. Изменение топологии не должно заставлять менять приложение.
-
There is one administrator / Администратор всегда один. Проблема проявляется сильней, если есть отдельная операционная команда или даже отдельная организация, которая выполняет эту роль. Налаживаем коммуникации, автоматизируем развертывание, добавляем средства диагностики и инструкции использования. Всё это работает в обе стороны: упрощаете жизнь операционной команде — упрощаете жизнь себе.
-
Transport cost is zero / Передача данных бесплатна. Сериализация/десериализация — это затраты на память и CPU; возможность передачи по сети — это затраты на оборудование и его обслуживание. Здесь архитектор и разработчик должны еще раз вернуться к заблуждениям 2 и 3.
-
The network is homogeneous / Сеть однородна. Даже в локальной сети однородность — редкое достижение. Разные производители и ресурсы, ОС и приложения, разные версии API и т.д. Выжить в этом безумном мире помогает стандартизация и обратная совместимость.
И 9-е бонусное заблуждение лично от меня:
9. Контейнеры бесплатны. Не хватает производительности — докинем еще несколько экземпляров! Выглядит разумно для “тушения пожаров”, но не в долгосрочной перспективе. Оптимизация кода или пересмотр решения — улучшают производительность; масштабирование — позволяет справиться с нагрузкой!
Думаю, что каждый увидел себя в каждом эпизоде! Но кто без греха?! Всем поменьше заблуждений!
Понравилась статья?
Посмею напомнить, что у меня есть Telegram-канал Архитектоника в ИТ, где я публикую материал на похожие темы примерно раз в неделю. Подписчики меня мотивируют, но ещё больше мотивируют живые дискуссии, ведь именно в них рождается истина. Поэтому подписывайтесь на канал и будем оставаться на связи! ;-)
Статьи из той же категории: