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

type storm

tag storm

url http://localhost:8080

window 600

sys 0

Мониторинг работоспособности сервисов

В качестве последнего примера рассмотрим применение паттерна  Adapter для мониторинга работоспособности контейнера приложе-ния. Разберем задачу мониторинга работоспособности контейнера  типовой СУБД. В данном случае контейнер СУБД предоставляет-ся ее разработчиками, и мне не хотелось бы модифицировать его  Глава 4. Адаптеры 73

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

тоспособности, делая, например, запросы к базе данных? Оркестраторы  контейнеров  наподобие  Kubernetes  также  по-зволяют  задавать  сценарии  оболочки,  проверяющие  работо-способность контейнера. Имея такую возможность, мы можем  написать сложный сценарий оболочки, выполняющий несколь-ко диагностических запросов к базе данных, чтобы определить  степень ее работоспособности. Но где хранить такой сценарий  и как следить за его версиями?

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

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

Допустим, вы хотите следить за работоспособностью базы дан-ных  MySQL  путем  периодического  выполнения  запросов,  со-ответствующих  рабочей  нагрузке  вашего  приложения.  Одним  из  вариантов  будет  добавить  в  контейнер  MySQL  проверку  работоспособности, отвечающую вашим требованиям. В общем  случае,  однако,  это  не  очень  желательное  решение,  поскольку  74 Часть I. Одноузловые паттерны проектирования

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

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

Исходный текст такого адаптера довольно прост и выглядит на  языке Go следующим образом (очевидно, что его можно реали-зовать и на другом языке):

package main

import (

"database/sql"

"flag"

"fmt"

"net/http"

_ "github.com/go-sql-driver/mysql"

)

var (

user = flag.String("user", "", "Имя пользователя базы данных") passwd = flag.String("password", "", "Пароль к базе данных") db = flag.String("database", "", "К какой базе данных необходимо подключиться")

query = flag.String("query", "", "Тестовый запрос") addr = flag.String("address", "localhost:8080", "По какому IP-адресу принимать запросы")

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

// Пример использования:

// db-check --query="SELECT * from my-cool-table" \ // --user=bdburns \

// --passwd="you wish"

//

func main() {

flag.Parse()

db, err := sql.Open("localhost", fmt.Sprintf("%s:%s@/%s", *user, *passwd, *db))