97 этюдов для архитекторов программных систем

Приготовьтесь выбрать два из трех Билл де Ора

Иногда ввод некоторого ограничения или отказ от какого-либо свойства улучшает архитектуру, делает ее более простой и экономичной. Желательные свойства обычно группируются по три, но попытки описать и построить систему, обладающую всеми тремя свойствами, как правило, дают результат, посредственный во всех трех отношениях.

Знаменитый пример такого рода — теорема Брюэра, которая гласит, что для распределенной системы желательными являются три свойства — целостность (Consistency), доступность (Availability) и устойчивость к разделению (Partitioning tolerance) — и что достичь всех трех целей сразу невозможно. Попытки получить «все сразу» кардинально повышают затраты на разработку и, как правило, влекут за собой рост сложности, не приводя при этом к желаемому эффекту и реальному достижению бизнес-цели. Если данные должны быть распределенными и постоянно доступными, обеспечение целостности обходится все дороже и в конечном счете становится нереальным. Аналогичным образом, если система должна быть распределенной и целостной, обеспечение целостности ведет сначала к задержкам и проблемам с производительностью и в конце концов — к недоступности в то время, когда система занята проверкой данных.

Нередко встречаются ситуации, когда одно или несколько свойств считаются неприкосновенными: данные не должны дублироваться, все операции записи должны быть транзакционными, система должна поддерживать 100-процентную доступность, вызовы должны быть асинхронными, в системе не должно быть единых точек отказа, все составные части должны быть расширяемыми и так далее. Такое фанатичное отношение к свойствам не только наивно, но и мешает нам думать о тех реальных задачах, которые стоят перед нами. От обсуждения главных принципов проектирования мы уходим в обсуждение отклонений архитектуры от идеала и начинаем путать догматизм с качественным управлением. Вместо этого следует задать вопросы: Почему эти свойства так необходимы? Какие преимущества они приносят? Когда они желательны? Как разбить систему на части для достижения лучшего результата? В таких случаях всегда проявляйте здоровый скепсис, потому что архитектурные догмы способны сделать поставку продукта проблематичной. Принять неизбежность таких компромиссов — одна из самых трудных задач в разработке программного обеспечения, причем не только для архитекторов, но также для разработчиков и других заинтересованных лиц. И все же это гораздо лучше, чем иметь безграничную свободу выбора, — неизбежные компромиссы часто ведут к творческим, нестандартным результатам.

Билл де Ора (Bill de hÓra) — ведущий архитектор в компании NewBay Software, где он работает над крупномасштабными веб-системами и системами для мобильных устройств. Является соредактором Atom Publishing Protocol, ранее участвовал в работе группы W3C RDF Working Group. Признанный эксперт в области REST и архитектур на основе передачи сообщений, а также проектирования протоколов.