Мы считаем, что в настоящее время просто незаменимы книги, рассматривающие такие темы, которые пока не автоматизируются средствами искусственного интеллекта. Одна из таких предметных областей – проектирование распределённых систем. В нашем ассортименте давно закрепилась добротная книга Иэна Гортона “Масштабирование систем. Основы и проектирование распределённых архитектур“, которую многие читатели сравнивают с “кабанчиком на минималках“. Теперь же мы уже в начале октября ждём из типографии переведённую нами книгу “Think Distributed Systems”, оригинал которой вышел в издательстве “Manning”. Наш уважаемый автор Владислав Светлаков @svetlakoff, автор книги “Архитектура бэкенда. API для надежных корпоративных приложений“, в своё время охарактеризовал книгу Торнова так: “Я посмотрел, мне эти темы понравились, их ранее не встречал. Я бы такую книгу прочитал, единственное я не знаю, насколько аудитория такое воспримет… она достаточно фундаментальная, она примерно как книга по кафке, где глубоко описываются детали, и тут глубоко описываются детали про согласованность, про гонку, как обмен данными происходит… а по поводу этой книги у меня сложилось ощущение, что там присутствует похожий подход, но к набору технологий про распределенные вычисления”.
Ниже мы перевели для вас обзор английской (аудио)версии книги “Think Distributed Systems”, по которому предлагаем вам составить первое впечатление о ней.
Честно говоря, я сразу открыл главу 11 «Устойчивое выполнение» — и как в стену уткнулся. Пришлось вернуться к главе 1 и читать сначала, попутно усваивая, почему выстроить общую картину в голове гораздо важнее, чем просто запомнить паттерны и фреймворки. В этой статье я расскажу, почему в книге Торнова не обойтись без изучения основ.
Коротко о книге
Суть книги: выстраивание каркаса из ментальных моделей, помогающих понимать и проектировать надёжные распределённые облачные сервисы.
Время на изучение: прослушал аудиоверсию примерно за 3,5 часа на скорости 1,5.
Путь к пониманию
Я решил прочитать эту книгу, чтобы понять, что такое «устойчивое выполнение», поэтому и начал с главы 11. Но эта глава как будто существовала сама по себе. Я чувствовал, что знаю, что такое «устойчивое выполнение», но сам способ его описания в этой книге оставался мне непонятен.
Есть фундаментальная разница между «знать» и «понимать». Эта книга — как раз о том, как лучше понимать распределённые системы, опираясь на самостоятельно выстроенные ментальные модели.
Слепцы и слон
Распределённые системы очень сложны, и в этой книге, равно как и во многих других книгах о системном мышлении используется метафора о слепцах, ощупывающих слона. Семеро слепых трогают слона, но все — за разные части тела: кто за хобот, кто за ноги, кто за уши и т.д. Каждый из них верит, что попавшаяся ему часть слона характеризует это животное в целости. Каждый из слепцов, имеет дело с «частичной истиной», но располагает неполной информацией. Нужно признавать, что наши представления о предмете всегда формируются на базе ограниченного контекста. Нужно целенаправленно искать другие взгляды на тот же концепт, чтобы полнее понимать систему. Существующая система самодостаточна, но, чтобы увидеть всю картину целиком, нужно интегрировать несколько ментальных моделей, описывающих эту систему.
ACID как основа
Я работаю над распределёнными системами так же долго, как и над базами данных, и вижу между ними тесную связь. Транзакции в базах данных гарантируют выполнение по принципу «всё или ничего», и мы опираемся на эти гарантии, также именуемые «двухэтапными коммитами» (2PC). Поскольку мы переходим к распределённым транзакциям, нам необходимо полностью понимать, что такое ACID: атомарность, согласованность, изоляция, устойчивость.
Все составляющие ACID работают в совокупности. Атомарность означает, что каждая операция либо выполняется целиком, либо не выполняется. Согласованность означает, что база данных переходит только из одного допустимого состояния в другое допустимое состояние. Изоляция означает, что транзакции, которые выполняются параллельно (конкурентно) не мешают друг другу. Устойчивость означает, что, как только изменения зафиксированы, то они будут сохраняться даже после отказов. Если не обеспечить совокупного соблюдения этих гарантий, то надёжные системы создавать не удастся.
Выстраивание моделей уровень за уровнем
Эта книга посвящена не только формированию ментальных моделей, но и надстройке их друг над другом. Вначале в ней рассматривается базис: гарантии, состояния, типы отказов (на уровне приложения или на уровне системы/платформы). В ней объяснено, что такое отказ, отказоустойчивость и прозрачность отказов. Каковы различные состояния системы? В чём разница между отказами на уровне приложения и уровне системы? Где следует обрабатывать отказ? Когда нужно компенсировать отказ? Все эти вопросы также применимы к доставке сообщений и соответствующим гарантиям. Затем автор переходит к рассказу о транзакциях, распределённых транзакциях и о координации работы множества систем. Каждая глава переводит вас на новый уровень в понимании распределённых систем.
Что такое устойчивое выполнение
Только по-настоящему разобравшись, что такое отказы, отказоустойчивость, гарантии и согласованность, мы начнём понимать, что такое устойчивое выполнение. 11-я глава начинается со следующего пассажа:
“Устойчивое выполнение — новая концепция в разработке программного обеспече-
ния. Для распределенных систем она представляет собой то же, что транзакции для
баз данных: это абстракция, скрывающая возможность отказа.”
Итак, я читаю эту книгу, чтобы разобраться в устойчивом выполнении. Устойчивое выполнение — это очень важно, так как оно обеспечивает безопасный перезапуск и страхует от завершения с ошибкой. Считайте, что речь о таком потоке задач, где гарантируется выполнение всех этапов, даже если на некоторых из них результат является недетерминированным — например, при работе с временными метками, случайными значениями или обращениями к ИИ. Если обрисовать эту задачу в виде ментальной модели, то становится проще рассуждать о долгосрочных процессах, в которых сохраняется состояние, и эти процессы должны быть устойчивыми к авариям, повторным попыткам и задержкам.
При традиционных отказах, связанных с двухэтапными коммитами (2PC) неоднозначность может приводить к откатам или повторным попыткам, предпринимаемым прямо с нуля. Но при устойчивом выполнении радиус отказа удаётся изолировать. При устойчивом выполнении операции перезапуска детерминированные и идемпотентные, поэтому прогресс не теряется, а согласованность сохраняется.
Но эти гарантии соблюдаются лишь в случае, если мы знаем, откуда проистекает отказ:
-
Случился ли он на уровне приложения (логика, данные, вызов извне)?
-
Может быть, он случился на уровне платформы/системы (инфраструктура, оркестрация, долговременное хранение состояния)?
Это различие — не академического характера. От него зависит, что мы предпримем: повторную попытку, компенсацию или эскалацию. Устойчивое выполнение — это не только о соблюдении гарантий в условиях неопределённости, а о том, что отказ — это нормальное явление в сфере распределённых систем. Об отказах нужно судить как о зоне ответственности, а не как об исключительных ситуациях.
В сущности, устойчивое выполнение — это паттерн проектирования, постулат распределённых систем, а не конкретная реализация, например, Temporal, DBOS или любой движок для организации потоков задач. Это способ понимания надёжности, обеспечения возможности безопасного возобновления прерванных задач, поддержка согласованности, умение справляться с неопределённостью, независимо от того, участвует ли в данном рабочем цикле человек.
По всем и причинам книгу нужно начинать читать с главы 1. То есть, постепенно выстроить мысленный каркас, необходимый, чтобы рассуждать о таких системах.
Как организована книга
Очень чётко: транзакции → распределённые транзакции → обработка ошибок → репликация → консенсус → устойчивое выполнение. Каждая последующая концепция базируется на предыдущей. Вот почему у меня не получилось начать читать книгу с 11 главы.
Последнюю главу «Облако и сервисы» автор заканчивает рассказом о времени, проведённом в SAP. Это не резюме, а размышление о том, как необходимость предоставления облачных ресурсов повлияло на подход автора к распределённым системам.
Что я вынес из книги
Чтобы понимать устойчивое выполнение, необходимо разобраться, на чём оно основано. Невозможно просто взять и пропустить сложные разделы об обработке отказов и распределённой координации. Также в книге нет решений, которые можно просто списать. Она учит самостоятельно рассуждать о распределённых системах. Вот почему важно прочитать её от корки до корки.
Заключение
Эта книга лишний раз напомнила мне, что самые мощные инструменты в арсенале инженера — это не фреймворки, платформы или продукты, а ментальные модели, на основе которых решаются задачи. В этих системах ментальная модель — это орудие, помогающее судить об отказах, согласованности и надёжности. Книга рассказывает, как решения проектировщика волнообразно распространяются на разные сервисы и команды. В ней вы не просто изучите концепции, но научитесь мыслить о распределённых системах с учётом их развития, масштабирования, существования в условиях неопределённости и меняющихся потребностей бизнеса. Сложный технический материал, но, одолев её, вы будете вознаграждены.
Автор: BHV_publishing
