Come posso creare un microservizio Python su AWS che accetta entrambe le connessioni REST ed elabora i messaggi SQS?

0

Sfondo : sto lavorando a un nuovo progetto al lavoro che verrà eseguito in AWS. Stiamo cercando di utilizzare una moderna architettura di microservice e sfruttare la tecnologia cloud, ma non abbiamo ancora molta esperienza in questo senso. A causa di alcune limitazioni della libreria, è necessario eseguire almeno alcuni dei servizi in Python, che la mia organizzazione ha una grave mancanza di esperienza di produzione con. La maggior parte delle nostre precedenti applicazioni sono in Spring / Java (e alcuni dei nostri altri microservizi saranno in esecuzione usando loro).

Nella nostra architettura, vogliamo avere un numero di microservizi in esecuzione in una sorta di pipeline di elaborazione che comunica usando SQS / SNS per la comunicazione asincrona. Allo stesso tempo, dovranno essere in grado di accettare le comunicazioni REST dal nostro frontend o da altri servizi che necessitano di dati del servizio.

La mia domanda : come posso gestire al meglio entrambe queste forme di comunicazione in python? La mia soluzione è sotto vitale, o dovremmo fare qualcosa di completamente diverso con la nostra strategia di comunicazione?

Quello che mi è venuto in mente : la mia idea attuale è di avere l'elaborazione in background / pipeline per un microservizio su un'istanza EC2 che ascolterà ed elaborerà messaggi SQS, quindi creerà una richiesta POST a un servizio di archiviazione specifico per quel microservizio che si trova dietro un gateway API AWS e utilizza le funzioni Lambda per archiviare i risultati in un database. In questo modo, possiamo chiamare frontend / altri servizi al gateway API per estrarre i dati dal microservice senza interrompere l'elaborazione dei messaggi SQS. Questo ci permette anche di sfruttare l'architettura senza server, rendendo il ridimensionamento molto più semplice.

Personalmente sono abbastanza inesperto e non sono stato in grado di trovare informazioni soddisfacenti o esempi di architettura come questa attraverso la mia ricerca, quindi apprezzerei qualsiasi intuizione o input che puoi dare.

Per chiarire, ciò di cui sono più curioso è il problema più fine di come aprire i miei microservizi sia a REST che alle comunicazioni di messaggistica, o se qualche altro modello sarebbe un'idea migliore.

    
posta SBR 07.11.2017 - 18:02
fonte

2 risposte

0

Se vuoi che il tuo microservizio basato su Lambda sia attivato sia tramite i messaggi REST che SQS, puoi farlo semplicemente utilizzando entrambi i gateway API e anche pubblicando i messaggi SQS su un SNS argomento. Le funzioni Lambda possono essere attivate da più fonti di eventi, vedi qui: link

Fammi sapere se questo non ha senso. Se decidi comunque di eseguire il tuo runtime Python su EC2 e cerchi un buon framework Python per l'esecuzione di codice asincrono, ti consiglio Twisted Framework ( link )

    
risposta data 07.11.2017 - 20:16
fonte
-1

Da quando hai chiesto informazioni su

... or if some other pattern would be a better idea.

Il modo moderno di fare questo genere di cose è con un approccio completamente ibrido. La soluzione che sto per offrire è una soluzione specifica per AWS (e, so che non è di moda, ma non mi piace seriamente AWS e preferisco Digital Ocean)

Crea, Aggiorna, Elimina (CUD) - > implementalo come servizio containerizzato se vuoi (i virts hanno una tecnologia decennale e non possono girare fino a una velocità simile a quella di un container) o meglio come una serie di lambda dietro un gateway (hai menzionato i gateway). Leggere e scrivere su un archivio dati è così comune che quasi non vale la pena parlarne. Tuttavia, si desidera pubblicare tutte le modifiche all'entità su un argomento SNS. È qui che altri servizi possono attingere ai canali degli eventi creati da SNS (che, per la cronaca, non è un vero argomento). Se metti i dati in dinamo, automaticamente attiverà un lambda per te in modo da poter uccidere 2 piccioni con una fava.

READ (R) d'altra parte è dove le cose diventano molto più interessanti: tutte le letture devono essere indirizzate a una cache distribuita (come, REDIS che è supportato nativamente da AWS). Usi un Lambda per ricevere gli eventi CUD dal tuo argomento SNS che potresti poi trasformare e pubblicare nel tuo cluster REDIS (che gestirà la propagazione).

Questa strategia è conosciuta come CQRS

La tua domanda è stata aggiornata in modo significativo da quando ho inizialmente risposto.

Affinché il tuo servizio gestisca endpoint REST e messaggistica asincrona (l'ingresso è un problema reale) diventerà davvero difficile con AWS. SNS (nonostante quello che dice e quindi perché lo odio) è NON un argomento, quindi non puoi ricevere messaggi broadcast. Ma questo è esattamente ciò di cui hai bisogno se il tuo microservizio è scalabile orizzontalmente e in un cluster (è / sarà, giusto?) In modo che tutte le istanze possano ricevere lo stesso messaggio.

Gli unici 2 modi pronti che conosco per fare questo sono: 1. Metti in piedi il tuo cluster AMQP e utilizza un lambda per pubblicare su REAL TOPIC quindi ricevere da esso. Ma questo ha numerosi problemi operativi da superare. 2. pubblica i messaggi in arrivo in un cluster Redis (da AWS) e rendi la tua app parte del cluster in modo che i messaggi vengano propagati ad esso.

    
risposta data 07.11.2017 - 19:02
fonte

Leggi altre domande sui tag