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

Разработка реальных приложений — тренировка по построению гетерогенных, гибридных систем. Одни части вашего прило-жения могут быть написаны вашей командой с нуля, другие Глава 4. Адаптеры 65

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

Рис. 4.1. Обобщенный паттерн Adapter

Далее в главе мы рассмотрим несколько приложений паттерна Adapter.

66Часть I. Одноузловые паттерны проектирования

Мониторинг

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

Существует множество стандартизированных интерфейсов мониторинга — syslog , мониторинг событий Windows (ETW), JMX для Java-приложений и многие другие протоколы и ин-терфейсы. Однако все они различаются как протоколами, так и способами коммуникации (push или pull). К сожалению, приложения, входящие в вашу распределенную систему, могут включать в себя как части из самописного кода, так и готовые open-source-компоненты. В результате вы сталкиваетесь с широким разнообразием интерфейсов мониторинга, которые необходимо интегрировать в одну по-нятную систему.

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

Глава 4. Адаптеры 67

Разбиение системы таким образом позволяет создавать более понятные и легко сопровождаемые системы. Развертывание новых версий приложения не требует развертывания новой вер-сии адаптера для мониторинга. К тому же контейнер-монитор может быть повторно использован совместно с разными контей-нерами приложений. Кроме того, его может даже предоставить независимая команда, занимающаяся поддержкой подсистемы мониторинга. Наконец, развертывание адаптера для мониторин-га в виде отдельного контейнера гарантирует, что каждый кон-тейнер получит свой выделенный набор ресурсов: процессор, память и т. п. Благодаря этому неправильно функционирующий контейнер не вызовет проблем с пользовательскими сервисами. Практикум. Мониторинг с помощью Prometheus

В качестве примера рассмотрим мониторинг состояния контей-неров с помощью Prometheus ( https://prometheus.io/ ). Prometheus — это агрегатор данных мониторинга, который собирает показатели организует в упорядоченную по времени базу данных. Кроме базы данных, Prometheus предоставляет средства визуализации и язык запросов для анализа собранных показателей. Чтобы обе-

спечить сбор показателей из разных систем, Prometheus рассчи-тывает, что у каждого контейнера предусмотрен определенный программный интерфейс для сбора показателей. Это позволяет Prometheus следить за самыми разными приложениями через единообразный интерфейс.