Распределенные системы. Паттерны проектирования - страница 17
Следующие главы познакомят вас с другими паттернами, де-монстрирующими иные области применения модульных, по-вторно используемых контейнеров.
3> Паттерн Ambassador В предыдущей главе мы рассмотрели паттерн Sidecar, в рамках которого контейнер-прицеп функционально дополняет суще-ствующий контейнер приложения. В этой главе мы познакомимся с паттерном Ambassador («посол»). Контейнер-посол выступает посредником во взаимодействии контейнера приложения с внеш-ним миром. Как и в случае с остальными одноузловыми паттерна-ми проектирования, два контейнера составляют симбиотический союз и исполняются совместно на одном компьютере. Схема данного паттерна изображена на рис. 3.1.
Рис. 3.1. Обобщенный паттерн Ambassador
Глава 3. Паттерн Ambassador 51
От паттерна Ambassador двойная польза. Во-первых, как и осталь-ные одноузловые паттерны, он позволяет создавать модульные, повторно используемые контейнеры. Разделение ответственно-сти между контейнерами упрощает их разработку и поддержку. Во-вторых, контейнер-посол можно использовать с различными контейнерами приложений. Такого рода повторное применение ускоряет разработку приложений, поскольку контейнеризо-ванный код можно задействовать в нескольких разных местах. Вдобавок повышаются качество и согласованность реализации, поскольку код собирается разово и затем используется во многих различных контекстах.
В оставшейся части данной главы мы рассмотрим несколько практических примеров реализации паттерна Ambassador. Использование паттерна Ambassador для шардирования сервиса В какой-то момент данных на уровне хранилища (storage layer) становится так много, что они перестают помещаться на одной машине. В таких ситуациях необходимо шардировать уровень хранилища.
Шардинг (шардирование) — разделение уровня хранилища на несколько независимых частей (шардов), каждая из которых размещается на отдельной машине. В данной главе рассматри-вается одноузловой паттерн проектирования, предназначенный для адаптирования существующих сервисов, чтобы те могли взаимодействовать с другими, шардированными сервисами, находящимися где-то в Интернете. Здесь не рассматривается, откуда появляются шардированные сервисы. О шардировании многоузловом паттерне проектирования шардированных сервисов мы подробно поговорим в главе 6. 52 Часть I. Одноузловые паттерны проектирования
Схема шардированного сервиса представлена на рис. 3.2.
Рис. 3.2. Обобщенная схема шардированного сервиса При развертывании шардированного сервиса возникает вопрос о том, как интегрировать его с программным обеспечением клиентского или промежуточного уровня. Очевидно, должен существовать модуль, который бы переадресовывал конкрет-ный запрос конкретному шарду. Часто такой шардированный клиент тяжело интегрировать в систему, компоненты которой рассчитывают на подключение к единому хранилищу данных. К тому же шардированные сервисы препятствуют совместному использованию конфигурации средой разработки (где храни-лище состоит, как правило, из одного шарда) и средой эксплуа-тации (где хранилище часто состоит из множества шардов). Один из вариантов — включить всю логику шардирования в сам шардированный сервис. При таком подходе шардированный сервис должен также иметь балансировщик нагрузки с незави-симой обработкой транзакций, адресующий трафик нужному шарду. Этот балансировщик нагрузки будет, по сути, распре-Глава 3. Паттерн Ambassador 53
деленной реализацией паттерна Ambassador в виде сервиса. Клиентская реализация паттерна Ambassador становится не нужна, но за счет этого усложняется развертывание шардиро-ванного сервиса. Другой вариант — интегрировать одноузловую реализацию паттерна Ambassador на стороне клиента, чтобы она перенаправляла трафик нужному шарду.
Развертывание клиента несколько усложняется, зато упроща-ется развертывание шардированного сервиса. Как и в случае с любыми компромиссами, особенности вашего конкретного приложения будут определять то, какой из двух подходов ока-