Utiliser API Gateway soutenu par Lambda Fonctions qui communiquent entre Microservices utilisant SNS

En résumé, je m'intéresse à la construction de Microservices faiblement couplés connectés via SNS (pour la plupart) afin de traiter des requêtes API en temps réel.Utiliser API Gateway soutenu par Lambda Fonctions qui communiquent entre Microservices utilisant SNS

Prémisse

besoin de tout cela se produise dans un seul corps de réponse à la demande POST
Ne peut pas demander au client de tirer pour le téléchargement de succès et/ou le routage avec succès.

AWS passerelle API Endpoints

POST/api/documents/uploadAndRouteDownWorkflow, exécute documents.upload et reçoit une réponse combinée des fonctions de documents.upload et workflows.routeDocument indiquant plein succès (upload et itinéraire de travail), le succès partiel (upload mais pas la route), ou l'échec complet (upload échoué)

Fonctions Lambda (execut ed dans l'ordre):

- documents.upload

Invoqué API de point final passerelle
documents Uploads à un DMS (Document Management System)
Crée un message à un SNS microservice de workflow pour acheminer le document

- workflows.routeDocument

Invoqué du sujet abonné SNS
document Routes/documents dans un message SNS
Renvoie un succès/échec à la demande api originale

Défauts pourquoi documents. le téléchargement n'appelle pas les flux de travaux.routeDocument en interne

microservices pas plus faiblement couplés
temps de calcul double pour les deux fonctions lambda se forçait à être synchrone (est-il possible)

Est-ce modèle possible?

Merci!

Source

2017-02-12 David Garza

est ici où il se décompose:

-workflows.routeDocument

Renvoie un succès/échec à la demande api originale

Ce n'est pas possible. En utilisant SNS, vous avez découplé les services au point que la fonction Lambda chargée de générer une réponse à la requête API Gateway (documents.upload) n'a aucune idée de ce qui s'est passé dans l'autre fonction Lambda. La fonction Lambda workflows.routeDocument n'a pas accès aux objets API Gateway event et context et n'est donc pas capable de mettre à jour la réponse API. La seule façon que cela fonctionnerait est si la fonction Lambda invoquée par API Gateway a fait une sorte d'interrogation pour attendre jusqu'à ce que l'autre appel de fonction soit terminé, puis accédé à l'état de retour (stocké dans une base de données ou quelque chose?) et a renvoyé cela dans la réponse. Je pense que cela va introduire beaucoup de latence dans la gestion de vos requêtes.

Dans ce cas, je pense qu'il est plus logique pour documents.upload d'appeler la fonction Lambda workflows.routeDocument directement.

Source

2017-02-12 23:20:43

Donc, si je comprends bien, je vais devoir maintenir un certain type de flux synchrone afin de renvoyer un résultat indiquant un échec de succès à la demande POST d'origine? Sur ce, si je veux garder ces pièces lâchement couplé, je devrais chercher une solution différente en dehors d'AWS, il semble. La lecture sur le modèle RPC dans RabbitMQ via Direct Reply-to (https://www.rabbitmq.com/direct-reply-to.html) semble être en ligne avec ce que je suis intéressé à faire). Existe-t-il un autre moyen pour AWS de garder les choses plus facilement couplées tout en conservant un comportement synchrone? –

Le modèle RabbitMQ RPC pourrait également être implémenté avec SQS d'Amazon. Cependant, vous devez réaliser que RabbitMQ utilise toujours les files d'attente et l'interrogation pour communiquer une réponse. Dans toute solution totalement découplée, vous allez avoir une fonction 'documents.upload' de longue durée interrogeant une base de données ou une file d'attente ou quelque chose en attente d'une réponse générée par la fonction' workflows.routeDocument'. –

@DavidGarza Vous pourriez être intéressé par l'annonce AWS d'aujourd'hui: https://aws.amazon.com/about-aws/whats-new/2017/02/amazon-api-gateway-integration-with-aws-step-functions/ –

Utiliser API Gateway soutenu par Lambda Fonctions qui communiquent entre Microservices utilisant SNS

Répondre

Questions connexes