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

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

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

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

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

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

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

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

нентов.

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

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

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

Резюме

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

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

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

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

Мотивация

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

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