Applicazione architettonica di Python composta da molti piccoli script

4

Sto costruendo un'applicazione che al momento contiene molti piccoli script Python.

Ogni script Python elabora gli elementi da una coda Amazon SQS. Le e-mail entrano in una coda iniziale e vengono elaborate da uno script, e tipicamente lo script eseguirà una piccola unità di elaborazione (ad esempio, analizza la posta elettronica e memorizza alcuni campi del database), quindi un elemento verrà inserito nella coda successiva per l'ulteriore elaborazione , fino a quando l'e-mail non ha completato i vari script e le code.

Quello che mi piace di questo approccio è che è molto liberamente accoppiato.

Tuttavia, non sono sicuro di come implementarlo dal vivo. Dovrei rendere ogni script un demone che sta costantemente interrogando la sua coda in entrata per le cose da fare? O dovrebbe esserci qualche programma o processo di orchestrazione globale? O forse non dovrei avere molti piccoli script Python ma una grande applicazione?

Domande specifiche: Come dovrei eseguire ognuno di questi script - come un demone con qualche sorta o riavviare il monitor per riavviarli nel caso si fermino per qualsiasi motivo? Se sì, dovrei avere qualche programma che lo orchestra?

O l'idea di molti piccoli script non è buona, avrebbe più senso avere un programma python più grande che contenga tutte le funzionalità e che faccia tutto il polling e l'esecuzione delle funzionalità della coda per ogni coda? Qual è l'attuale approccio preferito alla demonizzazione degli script Python?

In generale, accolgo con favore qualsiasi commento o opinione su qualsiasi aspetto di questo.

grazie

    
posta Duke Dougal 28.04.2013 - 04:35
fonte

4 risposte

1

Se questa applicazione ha bisogno di rimanere in funzione per un lungo periodo di tempo, allora costruisci la resilienza ma uccidila in momenti casuali (anche il monitor - ma meno frequentemente), e fa in modo che un monitor lo riavvii. In questo modo si esercita costantemente il monitor e si riavvia la funzionalità del sistema in modo che quando un vero errore del sistema genera il sistema, è più probabile che si riprenda senza problemi.

    
risposta data 28.04.2013 - 07:54
fonte
0

Penso che tutto ciò dipenda molto dai tuoi obiettivi e dai tuoi limiti. Funziona abbastanza veloce in questo modo? È abbastanza flessibile per i tuoi casi d'uso? È troppo fragile / fallisce spesso? Sembra ben organizzato e facile da aggiornare / mantenere / migliorare?

Se funziona, fallo. Se non soddisfa le tue esigenze, cambialo. Potrebbe essere necessario testarlo in "live" per decidere se è accettabile.

Un singolo programma costituito da un framework per l'integrazione dei vari script come moduli sarebbe probabilmente l'ideale. Ma il lavoro richiesto per una cattedrale vale il guadagno? Potresti accontentarti di un Bazar?

    
risposta data 28.04.2013 - 07:39
fonte
0

Un'alternativa all'elaborazione della coda consiste nell'utilizzare uno schema noSQL con un campo di stato - ad es. 0-Nuovo, 1 in attesa, 2 elaborati OK, 3 errori elaborati e campi personalizzati per qualsiasi attività di elaborazione di cui hai bisogno.

All'interno dello schema è possibile inserire risultati di elaborazione o dati di errore utili. L'importante vantaggio di questo approccio è la trasparenza. In qualsiasi momento puoi richiedere lo stato della pipeline.

È importante con questo approccio utilizzare un aggiornamento atomico (in Mongo findAndUpdate), in modo che nessun processo recuperi la stessa attività.

    
risposta data 29.04.2013 - 09:02
fonte
0

Proporrei di trasformare gli script in servizi atomici autonomi (sì, lo so, i servizi DEVONO essere atomici, qualunque cosa). Quindi, puoi trovare alcuni ESB e incollarli tutti insieme. Il più popolare (credo, "citation needed") ESB per python è zato.io, ma non l'ho provato. Invece, ho visto MuleESB (soluzione Java), e funziona come fascino.

"Soluzione Java per script Python?" chiedi. Sì, funzionerà. I servizi sono indipendenti dalla lingua, sono piccole scatole nere, che fanno solo una cosa - come volevi. Li incollate insieme a ESB e qualche sistema di coda (ZeroMQ? ActiveMQ? La vostra scelta), e non c'è differenza, se scrivete servizi in python2, python3, Java, C (++), Smalltalk o persino dannatamente Brainfuck .

    
risposta data 25.11.2013 - 20:10
fonte

Leggi altre domande sui tag