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

стр.

Разработка реальных приложений — тренировка по построению  гетерогенных,  гибридных  систем.  Одни  части  вашего  прило-жения  могут  быть  написаны  вашей  командой  с  нуля,  другие  Глава 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 предоставляет средства визуализации  и язык запросов для анализа собранных показателей. Чтобы обе-