Jak przyspieszyć tworzenie agentów RBM w ramach subskrypcji typu pull

Agenty RBM odbierają wiadomości i zdarzenia za pomocą relacji publikowania/subskrypcji w Google Cloud Pub/Sub. Gdy użytkownik odpowiada na wiadomości agenta, platforma RBM publikuje je w unikalnym temacie Pub/Sub, do którego dostęp ma tylko agent. Agent uzyskuje dostęp do tych wiadomości i wydarzeń za pomocą subskrypcji unikalnego tematu.

Pub/Sub obsługuje 2 typy subskrypcji: push i pull. W przypadku subskrypcji push Cloud Pub/Sub wysyła wiadomości na skonfigurowany przez Ciebie adres URL webhooka. W przypadku subskrypcji pull odpowiadasz za wpisanie kodu, który tworzy długotrwały odbiornik wiadomości i za ich przyjęciem.

Najbardziej popularną i popularną metodą dla większości deweloperów jest subskrypcja push. Jeśli korzystasz z interfejsów API firm zewnętrznych, prawdopodobnie korzystasz z adresów URL wywołania zwrotnego lub webhooka. Choć ta metoda jest prosta, wymaga ona publicznie dostępnego adresu URL, który wymusza wdrażanie na publicznych serwerach WWW za każdym razem, gdy użytkownicy chcą przetestować zmianę.

W tym artykule pokażę, jak skonfigurować subskrypcję pull do testowania lokalnego i jak jej używać w środowisku produkcyjnym Google Cloud App Engine.

Konfigurowanie Pub/Sub na potrzeby subskrypcji pull

Jeśli nie masz jeszcze skonfigurowanego Pub/Sub agenta, wykonaj instrukcje podane w Cloud Pub/Sub, aby utworzyć początkową subskrypcję.

Po utworzeniu subskrypcji możesz łatwo zmienić ją z modelu push na pull. Otwórz Google Cloud Console i przejdź do sekcji Pub/Sub > Subskrypcje. Kliknij rozszerzone menu obok subskrypcji utworzonej dla agenta i wybierz Edytuj. Powinien wyświetlić się ekran konfiguracji podobny do obrazu poniżej.

Ustaw Typ wyświetlania na Pull i kliknij Zapisz.

Konfigurowanie modułu obsługi subskrypcji asynchronicznego pobierania

Następnie musisz zaktualizować agenta RBM, aby pobrać wiadomości z subskrypcji. O tym, jak to zrobić w różnych językach programowania, dowiesz się z artykułu Asynchroniczne pobieranie. Możesz też zapoznać się z przykładami obsługi agentów RBM – wiele z nich korzysta z modelu pull.

W poniższym kodzie pokazano, jak w Node.js skonfigurować asynchroniczny detektor subskrypcji subskrypcji:

function initPubsub() {
    let pubsub = new PubSub({
        projectId: REPLACE_WITH_GCP_PROJECT_ID,
        keyFilename: REPLACE_WITH_SERVICE_ACCOUNT_KEY_FILE_LOCATION,
    });

    // references an existing subscription, (e.g. rbm-agent-sub)
    let subscription = pubsub.subscription(PUB_SUB_SUBSCRIPTION_NAME);

    // create an event handler to handle messages
    let messageHandler = (message) => {
        console.log(`Received message ${message.id}:`);
        console.log(`\tData: ${message.data}`);
        console.log(`\tAttributes: ${message.attributes}`);

        let userEvent = JSON.parse(message.data);

        // TODO: process the userEvent to create another RBM message
        // "Ack" (acknowledge receipt of) the message
        message.ack();
    };

    // Listen for new messages
    subscription.on('message', messageHandler);

    return { messageHandler: messageHandler, subscription: subscription };
}

Aby przetestować agenty lokalnie, wystarczy, że wywołasz funkcję initPubsub po uruchomieniu aplikacji ekspresowej. W konsoli zobaczysz odpowiedzi drukowania messageHandler.

Konfigurowanie i wdrażanie w App Engine od Google

W środowisku produkcyjnym musisz mieć pewność, że subskrypcja jest zawsze dostępna. Jednym z prostych rozwiązań jest poleganie na zadaniu cron do ponownego inicjowania odbiornika wiadomości Pub/Sub.

W App Engine zadania cron mogą być używane do planowania zadań z różnymi odstępami czasu. Zadanie cron jest skonfigurowane z opisem, adresem URL i interwałem. W aplikacjach Node.js konfigurujesz je w pliku cron.yaml, który możesz wdrożyć w App Engine przy użyciu pakietu SDK Google Cloud. Informacje o innych konfiguracjach języków znajdziesz w artykule Planowanie zadań z wykorzystaniem pliku cron.yaml.

Zadanie cron wymaga adresu URL, dlatego musisz dodać do niego punkt końcowy adresu URL, aby wywołał on cron. To z kolei wywołuje metodę initPubsub z poprzedniej sekcji, aby włączyć detektor.

router.get('/pubsubCallback', function(req, res, next) {
  let pubsubConfig = initPubsub();

      // Stop listening once the timeout is hit
      setTimeout(() => {
        pubsubConfig.subscription.removeListener('message', pubsubConfig.messageHandler);
      }, CRON_JOB_TIMEOUT * 1000);

  res.status(200).send();
});

W ramach wywołania zwrotnego musisz też usunąć odbiornik, zanim zaplanowane zadanie zostanie ponownie uruchomione. Jeśli np. zadanie cron działa co minutę, w parametrze CRON_JOB_TIMEOUT musisz ustawić wartość 60.

Poniżej znajduje się konfiguracja pliku cron.yaml, w której należy wykonywać ten punkt końcowy co minutę.

cron:
- description: "Processing Pub/Sub messages"
  url: /pubsubCallback
  schedule: every 1 mins

Aby wdrożyć zadania cron w App Engine, uruchom to polecenie:

gcloud app deploy cron.yaml

Po wdrożeniu App Engine automatycznie konfiguruje zadanie cron i jest ono widoczne w sekcji App Engine > Zadania cron, jak pokazano poniżej.

Podsumowanie i kierownik zespołu

Subskrypcja pull pull umożliwia testowanie i debugowanie lokalnie, co przyspiesza cykle programowania i skraca czas potrzebny na utworzenie agentów RBM. Mimo że model pull wymaga dodatkowej konfiguracji i kodu w porównaniu z modelem push, konfiguracja jest prosta i wymaga konfiguracji tylko raz. Zadania cron to łatwy sposób na zapewnienie, że subskrypcja pull będzie zawsze dostępna do obsługi przepływu wiadomości agenta, a App Engine znacznie obniży koszty konfiguracji i obsługi.

Powodzenia i kodowania!