Software Architecture: The Hard Parts — выпуск 6

Антон, которого позвали в понедельник читать четырёхсотстраничную книгу к четвергу, начинает с главы, от которой «бомбил» больше всего: авторы берут много глубоких тем, каждая тянет на отдельную книгу, и получается своеобразно. Контракт — формат взаимодействия частей системы, и глава ходит между двумя крайностями: строгие контракты с именами, типами и порядком полей — обмен конкретными объектами и RPC — и мягкие, где по пришедшим данным понимаешь, что тебе передали: JSON, YAML, map. GraphQL авторы кладут посередине, хотя Антон отнёс бы его к строгим; классификация из двух крайних точек и «чего-то промежуточного» — черта всей книги, замечает Вова. Антон отсылает к классике — Enterprise Integration Patterns Хопа: четыре способа интеграции и идея, что контракт — грамматика общения сервисов, где важно, что является существительным; Вова напоминает выпуск про кодирование по Клеппману с JSON, XML, Protobuf и Avro.

Полезное в главе — антипаттерны. Архитекторы любят строгие контракты, потому что они снижают число ошибок, — критично для сервисов передачи денег или персональных данных в банке; цена — сложность изменений, когда добавить обязательное поле означает править всю систему. Мягкие контракты кажутся гибкими, но схема проверит наличие обязательных полей и не проверит, что компоненты понимают данные одинаково: Антон приводит пример, где имя пользователя в личном кабинете — просто лейбл, а в пристроенном сервисе билетов — идентификатор, и после смены имени человек в кинотеатре билет не получает. Ответ авторов — consumer-driven contracts: потребители заранее описывают, какие данные им нужны, поставщик встраивает эти контракты в автотесты и выкладывает версию, только если все зелёные. Александр видит здесь компромисс: жёсткость добавляется к мягкому формату, но проверяется не в runtime, а на выкладке, и ответственность переезжает на команды потребителей — если они не молодцы, получится мешанина. Антон подчёркивает минимально необходимый набор данных: лишние поля «про запас» рождают нечёткую логику.

Антон вспоминает спецпроекты, где пара дополнительных полей, запрошенных фасадом, подняла время обработки до таймаутов с ошибкой 504. Stamp coupling Вова объясняет из опыта в travel-индустрии: схема Open Travel Alliance — сотни XML-схем, по которым работает почти вся отрасль; большой общий документ, в котором каждый сервис обогащает свой кусочек, может заменить оркестратора при хореографии множества вендоров с разным лицензированием, но требует другой архитектуры сервисов и бьёт по пропускной способности — они писали кастомный кэш в MongoDB, чтобы не гонять по сети большие файлы. Александр делится студенческой травмой: климатическая модель на Fortran с двумя экранами трёхбуквенных глобальных переменных в начале каждого файла, из-за которой он сменил тему диплома, — глобальные переменные-штампы выглядят так же. Антон добавляет, чего авторы не упомянули: жизненный цикл документа редко линеен, он ветвится и требует штампов от параллельных структур, и посчитать нормальный статус документа становится категорически сложно.

Глава про аналитику — третий заход клуба на тему за три книги. Вова проходит основы: DWH — отдельное хранилище, куда экстрактят данные из множества источников, трансформируют в схему звезды или снежинки и загружают; потребители — аналитики со своими запросами, BI и отчётами; движки — реляционные MPP-базы вроде Greenplum, по замечанию Александра. Плюсы — централизация и изолированный инструмент для аналитиков; минусы — экстремальные доменные знания, хрупкость интеграции при постоянно меняющихся схемах сотен источников, сложность и плохая масштабируемость: целые команды чистят и каталогизируют данные, чтобы отчёты хотя бы не стали хуже. Data lake — следующий по истории подход: меньше структурирования, сырые данные выгружают с минимальными преобразованиями, а трансформируют под витрину — schema on read вместо schema on write; но взаимоотношения данных приходится придумывать после загрузки, и ad-hoc трансформации становятся нормой. Александр напоминает разбор Влада: модели аналитические и транзакционные разные, и деление по технике — «здесь такие базы, там такие» — в сложном мире работает плохо, потому что бизнес-линии не хотят терять знание домена при выгрузке.

Data mesh Вова описывает как «мы все в одной доменной лодке»: данные — самое ценное и долгоживущее, они привязаны к домену и мало стоят без него, а старые подходы были технологической историей двух команд, одна из которых не знала домена. Александр перечисляет четыре принципа Дехгани — декомпозиция вокруг доменов, данные как продукт, автономные команды с дата-инженерами внутри и платформа как экосистема — и отмечает добавку авторов: data product quantum, DPQ, компонент рядом с транзакционным сервисом, отвечающий за аналитический интерфейс, с отсылкой к service mesh и сайдкарам. Три варианта: нативный, кооперативный и агрегирующий — метрики, рассчитанные по событиям продукта, что Антон сравнивает с фитнес-функциями для продукта. Александр признаёт, что таких квантов не делал, и советует книгу Дехгани: её статья трёхлетней давности была глубокой и по делу, а здесь каждой главе тесно.

Последняя глава про анализ трейд-оффов Александра разочаровала: вместо чёткого алгоритма — ещё несколько способов оценивать, тогда как у Влада было дерево решений. Поэтому он пересказывает другую книгу: систему оценивают по функциональным требованиям и по надёжности с пригодностью, а компромиссы — в привязке к атрибутам качества. Инструменты: точки чувствительности, где решение влияет на один атрибут; точки компромисса, где security бьёт по производительности, а три ноды с синхронизацией работают хуже одной, зато переживают отказ; риски с вероятностью и стоимостью — каждая следующая девятка на порядок дороже, и если вы не Google, пять девяток вам не нужны; и возможности на будущее. Атрибуты — RTO и RPO, time to market, совокупная стоимость; сценарии и дерево полезности по атрибутам. Вова запомнил из главы сборник советов: искать точки, строить матрицы, держаться контекста и не быть евангелистом, потому что евангелист преувеличивает плюсы и не видит минусов; Александр уточняет — можно быть евангелистом всех четырёх вариантов, вопрос в узости взгляда. Антон добавляет Uncle Bob: окончательные решения принимаются в последний момент, когда собраны все ограничения. Книга закрыта; дальше клуб выбирает формат — white papers, ответы на вопросы, голосование в Telegram.