Dove dovrebbe trovarsi la logica aziendale nell'architettura dei microservizi?

Sto ancora cercando di avvolgere la mia testa attorno all'architettura dei microservizi da quando sono abituato a un approccio monolitico

Supponiamo di provare a costruire un sistema di prenotazione Uber estremamente semplificato . Per semplificare le cose che diciamo che abbiamo 3 servizi e un gateway API per il cliente: Booking, Drivers, Notificatione noi abbiamo il seguente flusso di lavoro:

Quando si crea una nuova prenotazione:

1. Controlla se l'utente esistente ha già una prenotazione
2. Ottieni l'elenco dei driver disponibili
3. Invia una notifica ai conducenti per ritirare la prenotazione
4. L'autista ritira la prenotazione

Diciamo che tutta la messaggistica viene effettuata tramite una chiamata http anziché un bus di messaggistica come kafka per semplificare le cose.

Quindi, in questo caso, ho pensato che il Bookingservizio potesse fare il controllo per la prenotazione esistente. Ma allora chi dovrebbe ottenere l'elenco dei driver disponibili e le notifiche? Sto pensando di farlo a livello di gateway, ma ora la logica è in qualche modo divisa in due parti:

• Gateway - Ottieni l'elenco dei driver disponibili + invia notifiche
• Booking - verifica la prenotazione esistente

E sono abbastanza sicuro che il gateway non sia il posto giusto per farlo, ma mi sento come se lo stiamo facendo nel Bookingservizio, sta diventando strettamente accoppiato?

Per renderlo più complicato, cosa succede se abbiamo un altro progetto che vuole riutilizzare il sistema di prenotazione ma con la sua stessa logica aziendale? Ecco perché ho pensato di farlo a livello di gateway in modo che il nuovo gateway di progetto possa avere una propria logica aziendale separata da quella esistente.

Un altro modo di farlo suppongo sia che ogni progetto abbia un proprio servizio di prenotazione che parlerà con il servizio di prenotazione principale, ma non sono sicuro quale sia l'approccio migliore qui :-)

Le persone spesso ascoltano il "micro-servizio" e pensano "nano-servizio", e questo può creare confusione. Questi sono micro-servizi , quindi non è necessario un servizio separato per ogni singola entità. Tutto ciò che stai cercando di fare dovrebbe essere nei servizi bookinge notification. Non hai bisogno del driverservizio (per nessuna delle attività che hai descritto).

Ottenere un elenco di driver disponibili per la prenotazione rientra nel bookingservizio. Una trappola comune è quella di non raggruppare le attività correlate nello stesso servizio, questo si chiama bassa coerenza ed è molto male. Ricorda, raggruppa le cose in un servizio per dominio problematico, non per entità.

Ora, per quanto riguarda il riutilizzo, il vantaggio di avere un micro-servizio separato è, ora puoi avere tre team separati che creano app rivolte al consumatore. Un team per l'app Web HTML standard, un'app Android e un'app iOS. Tutte queste diverse applicazioni possono essere costruite in modo completamente diverso e apparire appropriate per la loro piattaforma specifica (senza ripetere il codice). Il bookingcodice di servizio viene riutilizzato da tutte e tre queste app, poiché tutte e tre le app effettuano chiamate http al servizio anziché avere il proprio codice di prenotazione.

Un tipico flusso di prenotazione sarebbe simile al seguente:

1. L'app Android chiama il bookingservizio per ottenere un elenco di driver disponibili
2. Il servizio di prenotazione restituisce un elenco di driver all'app
3. L'utente seleziona quindi il proprio driver e l'app chiama il metodo "book" del bookingservizio
4. Il bookingservizio di assistenza chiama il notificationservizio con i dettagli della prenotazione
5. Il notificationservizio invia una notifica all'autista, avvisandolo della prenotazione
6. L'app del driver invia un messaggio al notificationservizio quando si trovano entro un miglio dal cliente
7. Il notificationservizio invia l'avviso al cliente che il suo autista è quasi arrivato

Spero che questo abbia aiutato; ricordate, sono micro-servizi, non nano-servizi, non tentano di dividere lo stesso dominio problematico. Quindi, per rispondere al titolo della tua domanda, quando mantieni un micro-servizio della dimensione corretta, tutta o la maggior parte della logica di business per quel dominio problematico può vivere all'interno di quel micro-servizio.

Tutto dipende dal tuo esatto requisito.

Supponiamo che tu abbia due applicazioni per effettuare la prenotazione:

1. Primo caso: un'applicazione può consentire a un utente di prenotare più volte, l'altra ne consente solo una. Ciò significa che la limitazione della prenotazione è a livello di applicazione, in quanto tale o hai due punti di ingresso nel tuo sistema di prenotazione (uno che consente la prenotazione multipla, uno che non lo fa) o lo controlli semplicemente nei microservizi del relativo applicazione.
2. Secondo caso: fa parte della definizione di "Prenotazione" che un utente non può averne più qualunque sia l'applicazione, questa regola è vera per l'intero sistema: questo significa che è possibile inserire il controllo nel microservizio di prenotazione.

Per quanto riguarda il sistema di notifiche, puoi avere microservizi che si iscrivono al tuo servizio di prenotazione per ascoltare eventuali nuove prenotazioni. Pertanto il microservizio di prenotazione avviserà tutti gli abbonati e agiranno di conseguenza.

L'unico problema in questo tipo di architettura è cosa succede se qualcosa non riesce dopo che la notifica è stata pubblicata, poiché i due microservizi non funzionano come due funzioni che si eseguono nella stessa transazione del database, dovrai gestire gli errori con grazia ed eventualmente riprodurre i processi che hanno fallito (automaticamente o manualmente)

La semplice risposta è che i clienti dei microservizi sono ciò che gestisce la logica aziendale in un'architettura di microservizi "pura". Per facilitare la comprensione, considera un esempio ancora più semplice. Un servizio che restituisce solo flussi di byte basati su un URI. Di per sé, non è terribilmente utile. Senza sapere in alcun modo quali URI hanno cosa in loro, puoi solo indovinare dove estrarre le cose. Supponiamo ora di avere un microservizio diverso che fornisce una funzionalità di ricerca. Si invia una richiesta con una stringa di query e restituisce URI. Ora le cose si fanno più interessanti. Posso inserire riferimenti a URI per il primo servizio in un indice.

Tuttavia, dobbiamo coordinarci in qualche modo tra questi due. C'è una risposta semplice: si utilizza un browser per recuperare gli URI dal servizio indice e quindi recuperare i dati dal servizio dati. Nessuno dei due servizi "sa" dell'altro e non c'è assolutamente alcun accoppiamento tra loro. Posso utilizzare il servizio di indicizzazione con qualsiasi altro servizio dati e viceversa.

Non è necessariamente il caso che questo sia l'approccio migliore in tutti gli scenari, ma ci sono molti vantaggi nel costruire cose in questo modo, in particolare la riusabilità in scenari che al momento non sono noti.