I microservizi si allentano con l'uso della logica di business distribuita o centralizzati?

2

Come otteniamo un accoppiamento libero nello scenario seguente:

N microservizi (chiamiamoli chiamanti) ha bisogno di una logica o di un business (chiamiamolo Worker) per essere eseguito con diversi contratti. Sebbene il contratto sia diverso, la logica è quasi identica e il lavoro sui dati memorizzati centralizzati in un DB Worker rischia di evolvere un po 'rispetto a ciascun microservizio del chiamante.

Inoltre, vorrei aggiungere che Worker avrà sempre gli stessi dati con cui lavorare.

Quindi, sto pensando alle seguenti opzioni da considerare:

  1. Abbiamo aggiunto la logica (business) a tutti i microservizi di Caller che potrebbero avere modifiche logiche minori e ottenere i dati dal microservice che mantiene i dati?
  2. Creo più endpoint (con un contratto separato) da un singolo microservizio con logica centralizzata per il lavoratore e gestisco i dati?
  3. Avere un singolo endpoint e unire più contratti di microservizi e con logica centralizzata per l'operatore e conservare i dati?

Inoltre, quale tipo di comunicazione si adatta a Kafka vs Rest e in quale scenario?

    
posta Vishal nigam 18.08.2018 - 17:43
fonte

1 risposta

1

Ecco un riassunto di ciò che hai detto dalla mia comprensione (per favore conferma):

  • Hai N microservices, dove N ~ = 10 (potrebbe crescere). Chiamiamoli consumatori
  • Ogni microservizio richiede richiede dati
  • I dati richiesti sono memorizzati 1 database
  • Ogni microservizio richiede questi dati in modo diverso

Per supportare questi requisiti, proponi che uno specifico microservizio gestisca i dati richiesti dai consumatori. Inoltre, questo nuovo produttore manterrà la logica aziendale necessaria per i consumatori.

Prima di rispondere alle 3 domande, ricorda che un microservizio può essere disaccoppiato così tanto da diventare un anti-microservizio. Ad esempio, creare una nuova applicazione con uno stack tecnologico specifico solo per mantenere il nome di un utente in cui un altro manterrà le informazioni personali non è l'ideale. Quindi, invece di vedere il tuo problema da un punto di vista tecnico, incorpora l'aspetto commerciale di esso.

  1. Abbiamo una logica (business) aggiunta a tutti i microservizi del Caller che possono avere modifiche logiche minori e ottenere i dati dal microservice che mantiene i dati?

    • Se la logica di business è specifica per i chiamanti, dovrebbe rimanere nei chiamanti e lasciare che l'operatore fornisca solo le informazioni nel database.
  2. Creo più endpoint (con un contratto separato) da un singolo microservizio con logica centralizzata per il lavoratore e gestisco i dati?

    • Se si desidera utilizzare un'architettura di microservizio, questi dati devono essere gestiti da un solo microservizio, l'operatore. Chiunque desideri che i dati (e possano modificarli) lo richiedano dal lavoratore. Gli endpoint multipli sarebbero i diversi contratti richiesti da altri servizi o possibili umani. cioè ottenere un elenco dei dati disponibili, eliminare alcuni dati, aggiornare i dati.
  3. Avere un unico endpoint e unire più contratti di microservizi e con logica centralizzata per il lavoratore e conservare i dati?

    • Dipende molto da ciò di cui i chiamanti hanno bisogno. Se per ogni nuovo chiamante, si riutilizza lo stesso endpoint dal worker e si aggiunge la nuova logica nel worker, è possibile interrompere la compatibilità tra gli altri chiamanti e il worker. Funziona se non è necessaria la logica per l'endpoint e invia esclusivamente informazioni e i chiamanti applicano la propria logica ai dati.

Tutto sommato, rivisita qual è esattamente la logica aziendale necessaria per chiamante. Se solo il lavoratore può applicare questa logica, quindi utilizzare diversi endpoint (contratti). Se la logica è inerente ai chiamanti, spostare la logica verso i chiamanti e mantenere l'endpoint il più semplice possibile. Di conseguenza, tale endpoint può essere riutilizzato fino a quando un nuovo chiamante ha bisogno di una nuova API dal worker.

REST vs Kafka

Per quanto riguarda la tua ultima domanda, considera questi:

  • Kafka è una tecnologia che utilizza un modello di sottoscrizione editore
  • REST è un'architettura che è possibile utilizzare per rappresentare i dati nel tempo

Direi di utilizzare il modello di sottoscrizione dell'editore solo se hai bisogno che la tua applicazione ti avvisi e / o ti venga notificato qualcosa. Nel tuo caso, se i tuoi chiamanti usano Kafka, in pratica staranno aspettando notifiche di aggiornamento sui dati dal lavoratore. Ciò significa anche che devono persistere i dati dalla loro parte. Se sia i chiamanti che i worker si trovano nello stesso sistema, questa è una complessità non necessaria (se si desidera solo leggere i dati da un database).

    
risposta data 22.08.2018 - 15:16
fonte

Leggi altre domande sui tag