Microservizi e librerie condivise

9

Stiamo progettando un sistema basato su microservizi indipendenti (collegati tramite un bus RabbitMq). Il codice (almeno per i primi componenti) sarà scritto in Python (sia Python2 che Python3). Abbiamo già un'applicazione monolite che implementa alcune delle logiche aziendali, che vogliamo riformattare come microservizi ed estendere. Una domanda che mi preoccupa è:

Qual è il modo migliore per condividere il codice tra i diversi microservizi. Abbiamo funzioni helper comuni (elaborazione dati, registrazione, analisi della configurazione, ecc.), Che devono essere utilizzate da diversi microservizi.

I microservizi stessi saranno sviluppati come progetti separati (repository git). Le librerie comuni possono essere sviluppate anche come progetto autonomo. Come posso condividere queste librerie tra i microservizi?

Vedo diversi approcci:

copia intorno alla versione della libreria necessaria per ciascun microservizio e aggiorna se necessario
rilasciare le librerie comuni su un PyPi interno ed elencare tali librerie come dipendenze nei requisiti del microservizio
include il repository della libreria come sottomodulo git

Vorrei leggere qualcosa in più sugli approcci suggeriti, le migliori pratiche, le esperienze passate prima di decidere come procedere. Hai qualche suggerimento o collegamento?

python microservices

— dangonfast
fonte

Non sono abbastanza esperto nei microservizi (la mia azienda ha recentemente iniziato a fare qualcosa di simile) per rispondere, ma ecco un link a una presentazione sul perché ciò che stai descrivendo è una bandiera rossa e può portare a un "monolito distribuito" . I microservizi non dovrebbero aver richiesto librerie condivise. Dovrebbero davvero comunicare solo tra API ben definite come Swagger (ora chiamato Open API ).

— Captain Man,

@CaptainMan: Certo, ma supponiamo che tu abbia questa semplice funzione: fib(n)(implementazione della serie fibonacci). Non si desidera ripetere l'implementazione in ciascun microservizio. Appartiene a una utilslibreria (con versione, per funzionalità e correzioni di bug). Questo non è un monolito distribuito, è solo uno strato di funzionalità comune. La mia domanda è: come gestire questo livello a livello di implementazione?

— dangonfast,

I nostri microservizi hanno librerie condivise per garantire che parlino con tutti gli altri microservizi nel nostro sistema allo stesso modo. Non sono sicuro di come sarebbe possibile farlo con librerie non condivise; come minimo tutti avrebbero bisogno di alcune librerie di manipolazione XML / JSON / etc. Non ho ancora visto quella presentazione, ma avevi in mente un significato più specifico di "biblioteca condivisa" rispetto a quello a cui sto pensando?

— Ixrec,

1

@ jeckyll2hide Stiamo usando il C ++, ma la nostra infrastruttura per questo è all'incirca equivalente al tuo secondo punto elenco: repository separato, tutti dichiarano le loro dipendenze, sistema di build standard che sa come trovare quelle dipendenze al momento della compilazione, ecc.

— Ixrec

1

Mi sento un manichino, la tua domanda non riguarda davvero i microservizi che condividono specificamente le librerie, ma si chiede davvero come condividere le librerie del tuo team con il team. Ne so abbastanza per pubblicare una risposta.

— Captain Man,

5

La tua seconda opzione è sicuramente la strada da percorrere. Suddividere le librerie comuni e installarle sul server PyPi locale.

L'opzione 1 è orrenda perché i miglioramenti delle librerie saranno difficili da propagare ad altri che potrebbero usarla.

L'opzione 3 è simile all'opzione 1.

Il modello comune è quello di configurare Jenkins in modo che quando si passa al master di un repository di libreria, esegua una build in Python e lo carichi automaticamente nel repository PyPi. Dopo aver scritto questo script di build, non dovrai mai preoccuparti di impacchettare le librerie e caricarle manualmente su PyPi. E con questa opzione, tutti gli aggiornamenti della libreria saranno immediatamente disponibili per essere eventualmente aggiornati ad altri microservizi.

Configurare il proprio server PyPi è molto semplice. Mi piace questa guida

— Tommy
fonte

1

Concordo sul fatto che l'opzione 2 è la migliore, ma l'opzione 3 con i sottomoduli ha molto più in comune con l'opzione 2 rispetto all'opzione 1.

— 8bittree

@ 8bittree: sì, l'opzione 3 è simile all'opzione 2, ma il server git (il "telecomando" centrale) è il meccanismo di distribuzione del pacchetto. Da un lato sta usando git per qualcosa a cui non si fa riferimento (gestione delle dipendenze), dall'altro riduce il numero di componenti (non è necessario il PyPi privato)

— dangonfast

2

Non è un tipo Python ma il server PyPi sembra l'opzione migliore. Una rapida ricerca su Google dà l'impressione che sia analogo ad avere un repo Nexus per i barattoli Java del team.

Fintanto che viene distribuito in una sorta di repository centrale (in ufficio / team) con cui il tuo strumento di gestione delle dipendenze preferito può funzionare (leggi e distribuisci), allora è una buona opzione.

L'opzione 1 è davvero la peggiore, non dovresti mai avere a che fare manualmente con le dipendenze. È un dolore Prima del college conoscevo Maven e quando pensavo che Git fosse troppo complicato, abbiamo fatto tutto manualmente, dalla fusione del codice di tutti alla creazione di percorsi di classe, all'acquisizione di dipendenze. È stato un dolore, non vorrei seriamente che nessuno passasse nemmeno una piccola parte di quel problema, specialmente in un ambiente di lavoro in cui l'efficienza è importante.

L'opzione 3 probabilmente funzionerebbe bene, ma non ha alcun reale vantaggio rispetto a un PyPi locale (a parte forse essere più facile da configurare, ma i vantaggi di un vero sistema di gestione delle dipendenze sono decisamente migliori).

— Capitan Man
fonte

1

Innanzitutto dividere un monolite in microservizi sarà sempre difficile. Vedi Gestione dei dati decentralizzata - incapsulamento dei database in microservizi per avere un'idea del perché.

Detto questo, ci sono diverse ricette su come farlo in modo relativamente sano. Uno di questi è http://12factor.net/ . Quello direbbe che è necessario mantenere ogni libreria e applicazione in modo indipendente, quindi gestire esplicitamente le dipendenze. Se segui questa strada, ti consiglio vivamente di avere un semplice comando che aggiorni tutte le dipendenze a ciò che è corrente e lo esegui regolarmente per ogni micro-servizio. È importante disporre di un corretto processo di rilascio in cui bloccare le versioni delle librerie in produzione. Tuttavia, davvero, davvero , davvero non vuoi essere in una posizione in cui le dipendenze diventano stantie e non sai cosa c'è là fuori.

Concentrati anche sul rendere le tue librerie di supporto più strette e focalizzate possibile. Ci sarà sempre una naturale spinta per iniziare ad aggiungere elementi alle librerie di base per una facile condivisione. Fallo e tirerai rapidamente l'intera sfera di spaghetti esistenti in librerie condivise e tornerai effettivamente al caos che hai ora. È quindi meglio correggere eccessivamente l'altro modo.

— btilly
fonte

0

Dovresti essere in grado di andare senza server puntando direttamente da un file di dipendenza del pacchetto Python ai repository GitHub privati contenenti le librerie. Pipenv e Poet lo sostengono entrambi, credo.

— Dogweather
fonte