Б Бёрнс - Распределенные системы. Паттерны проектирования

Общий язык обсуждения

подходов к разработке

Возможность учиться, а также лучше и быстрее понимать раз-работку распределенных систем — лишь часть преимуществ от наличия общего набора паттернов проектирования. Паттерны ценны даже для опытных разработчиков распределенных си-

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

Для того чтобы было понятнее, представим, что мы оба исполь-зуем один и тот же инструмент для постройки дома. Я называю его «сепулька», а вы называете его «бутявка». Как долго мы бу-дем спорить о преимуществах «сепулек» над «бутявками» или пытаться объяснить различие в их свойствах, пока не придем к тому, что это одно и то же? Только когда мы придем к тому, 26Глава 1. Введение

что «сепульки» и «бутявки» — одно и то же, мы сможем учиться на опыте друг друга.

При отсутствии общего словаря много времени тратится либо на споры в поисках «насильственного согласия», либо на объ-яснение понятий, которые остальные понимают, но называют по-другому. Следовательно, ценность паттернов состоит еще и в том, что они обеспечивают наличие общего набора понятий и их определений, позволяющего не тратить время на дискус-сии об именах, а перейти к обсуждению деталей реализации основных идей.

За то короткое время, что я работал над технологией кон-тейнеров, я убедился в этом. На тот момент идея контейне-ров-прицепов (будут описаны в главе 2) прочно укрепилась в сообществе «контейнерщиков». Благодаря этому не было необходимости тратить время на разъяснение того, что зна-чит быть контейнером-прицепом, а вместо этого можно было перейти к обсуждению того, как использовать этот паттерн для решения конкретной задачи. «А вот если мы здесь ис-пользуем паттерн Sidecar...» — «Ага, кажется, я знаю, какой контейнер отлично подойдет для этой задачи». Этот пример подводит нас к третьему показателю ценности паттернов про-ектирования — возможности создания повторно используе-мых компонентов.

Общие повторно используемые компоненты

Паттерны позволяют учиться на чужом опыте и предоставляют общий язык для обсуждения тонкостей построения систем, но, помимо этого, они дают программисту еще один инструмент — возможность выявлять общие компоненты, которые достаточно реализовать однократно.

Глава 1. Введение 27

Если бы мы писали весь необходимый программный код са-мостоятельно, то мы никогда бы ничего не доделали. Более того, у нас едва бы получалось начать. Каждая созданная или создаваемая на сегодня система является результатом тысяч, а то и сотен тысяч человеко-лет работы. Код операционных систем, драйверов принтеров, распределенных баз данных, исполнительных сред контейнеров и их оркестраторов — все, что мы сегодня строим, создается на основе совместно используемых библиотек и повторно используемых компо-

нентов.

Паттерны — основа формирования и развития таких компонен-тов. Формализация алгоритмов привела к созданию повторно используемых реализаций сортировки и других канонических алгоритмов. Благодаря выявлению интерфейсных паттернов проектирования появился целый ряд объектно-ориентирован-

ных библиотек, их реализующих.

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

Резюме

Распределенные системы необходимы для того, чтобы обе-спечить уровень надежности, гибкости и масштабируемости, ожидаемый от современных компьютерных программ. Проектирование распределенных систем пока остается «чер-ной магией» для посвященных, а не наукой, доступной не-профессионалу. Выявление общих шаблонов и практик упо-рядочило и усовершенствовало подходы к алгоритмическому и объектно-ориентированному программированию. Эта книга призвана сделать то же для распределенных систем. Поехали! Часть I

Одноузловые паттерны проектирования

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

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

Мотивация

Нам понятно, почему возникает потребность разбить распреде-ленное приложение на части, работающие на разных машинах. Но не так понятно, почему необходимо делить на контейнеры компонент приложения, работающий на одной машине. Чтобы разобраться в мотивации такой группировки контейнеров, стоит сначала понять цели, стоящие за контейнеризацией как таковой. В общем случае цель контейнера — установить ограничение на определенный ресурс (например, приложению нужно два про-

цессорных ядра и 8 Гбайт оперативной памяти). Такой лимит может также привести к разделению сфер ответственности команд разработчиков (например, конкретная команда отвеча-ет за определенный образ). Наконец, это может способствовать разделению обязанностей между частями кода (конкретный образ отвечает за конкретную функциональность). Все эти причины побуждают делить приложение на группу контейнеров даже в пределах одной машины. Сначала рассмо-Часть I. Одноузловые паттерны проектирования 31

трим изоляцию ресурсов. Ваше приложение может состоять из двух компонентов — сервера приложений, взаимодействующего с пользователем, и фонового загрузчика конфигурационных файлов. Очевидно, что в первую очередь требуется минимизи-ровать задержку обработки пользовательских запросов, поэто-му приложение, взаимодействующее с пользователем, должно иметь достаточно ресурсов, чтобы обеспечить максимальную отзывчивость. В то же время загрузчик конфигурационных файлов обычно нетребователен к времени отклика. Если он будет испытывать небольшую задержку в период максималь-ного количества пользовательских запросов, система будет в порядке. Более того, фоновый загрузчик конфигурационных файлов не должен влиять на качество обслуживания конечных пользователей.