Remote observer

Если проект вышел за рамки локальной машины, скорее всего придётся интегрироваться с какими-нибудь сторонними системами.

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

Задача

Существует торговая площадка, которая предоставляет доступ к своей товарной базе посредством WEB-сервисов. Партнёры площадки хотят узнавать об изменениях в базе в кратчайшие сроки.

Вариант решения

Мы знаем всех наших партнёров, можем запросить документацию по их ПО.

Можно реализовать работы с API наших партнёров, и при изменении товарного каталога оповещать их напрямую.

При таком подходе каждого нового клиента придётся подключать индивидуально. Если у партнёра что-то изменилось в софте, потребуются ресурсы на восстановление работоспособности. В общем, дополнительные траты и лишняя зона ответственности.

Очень не хочется устанавливать такие жесткие связи. Поэтому будем делать следующее.

За основу возьмём паттерн «наблюдатель». Предоставим нашим коллегам подписываться на события и получать необходимые им уведомления.

Реализация

Записи о подписках должны где-то храниться. Тип хранилища останется на совести разработчика. Рассмотрим ЧТО нужно хранить.

• Событие. Типов событий может быть достаточно много и чтобы не рассылать оповещения всем подряд, нужно знать кто на что подписался.
• URL. Берем самый простой вариант. Оповещение предполагает отправку HTTP-запроса на указанный URL. Если идея себя оправдает, то можно будет добавить поддержку других протоколов и технологий.
• Количество отказов. Оповещение подписчиков это работа, которая требует ресурсов (процессорное время, память, трафик). После отправки запроса, мы ожидает положительного ответа. Но на той стороне может что-то сломаться и слать туда запросы становится бессмысленным. Соответственно нужно следить за отказами и прекращать оповещение при достижении некоторого значения.

Предположим, что программная часть написана на PHP.

Для подписки на событие, необходимо отправить POST-запрос на некоторый URL. Например, b2b.api.my-soft.ru/event-subscription. И передать параметры URL и event(алиас события).

Обрабатываем так (на базе Laravel):

public function subscribe()
{
    $request = $this->getRequest();
    $eventName = $request->input('event');
    $url = $request->input('callback');

    $validator = \Validator::make([
        'url' => $url,
        'event' => $eventName
    ], [
        'url' => 'url|required',
        'event' => 'required'
    ]);

    if ($validator->fails()) {
        throw new BadRequestHttpException($validator->errors()->first());
    }

    $repository = $this->getRepository();
    if (!$repository->eventAvailable($eventName)) {
        throw new BadRequestHttpException(trans('api.error.eventSubscription.wrongEvent'));
    }

    if (!$repository->canAddEvent($eventName)) {
        throw new BadRequestHttpException(trans('api.error.eventSubscription.maxCallbacks'));
    }

    $model = $repository->createModel([
        'client_id' => $request->attributes->get('client')->id,
        'event' => $eventName,
        'url' => $url
    ]);
    if ($repository->save($model)) {
        return $this->response($model);
    }
    throw new \Exception();
}

Алгоритм действий прост:

• Проверяем, что все нужные данные пришли и пришли в нужном формате
• Проверяем, что тип события доступен
• Проверяем возможность подписки (метод canAddEvent)
• Сохраняем
• Сообщаем, что подписка успешна

Далее клиент ждёт оповещения.

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

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

Это можно организовать в один или два этапа.

В два, это когда сначала, в очередь ставится само событие. А на втором этапе, в порядке очереди, происходит выборка подписчиков и их оповещение.

Но, можно и сразу сделать выборку и постановку задач в очередь. Операция достаточно дешевая.

$subscribersRepository->with(['event' => $event->getEventName()])->getActive()->each(function ($model) use ($event) {
    $this->dispatch(new \Commands\RemoteCallback(
        $model->id,
        $model->url,
        $event->getData()->toArray()
    ));
});

Выбираем активных подписчиков на произошедшее событие и в цикле ставим их в очередь.

RemoteCallback реализован следующим образом:

public function handle(EventSubscriptionRepository $subscriptionRepository)
{
    $client = new \Guzzle\Http\Client();
    $res = $client->post($this->url, [], $this->data, ['connect_timeout' => 3, 'timeout' => 3]);
    try {
        if ($res->send()->getStatusCode() !== 200) {
            throw new \Exception();
        }
        $subscriptionRepository->dropErrors($this->subscriptionId);
    } catch (\Exception $e) {
        $subscriptionRepository->incrementError($this->subscriptionId);
    }
}

Порядок действий таков. Делаем POST-запрос на указанный URL. Если успех, то обнуляем счетчик отказов, иначе увеличиваем.

Здесь стоит пройтись по условиям и ограничениям. Про количество отказов уже было сказано выше. Отказом считается HTTP статус != 200, либо медленный ответ. В примере выше, клиенту выделяется 3 секунды на установление соединения и 3 секунды на обработку запроса. Если партнёрская система за это время не уложилась, то считать отказом.

Во время обработки запроса на подписку проверяется возможность этого (метод canAddEvent). В нём может быть всё что угодно, но в моём случае проверяется ограничение на количество слушателей. Не более 3х на каждый тип событий.

Плюс, конечно же, для работы с такими методами API необходима авторизация.

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