comunicare i micro-servizi in un linguaggio statico (java)

2

Mi trovo di fronte a un'architettura di "microservizi" composta da servizi di avvio di primavera con un'applicazione di avvio di Vaadin Spring (con un gateway API in mezzo), tutti scritti in Java. La comunicazione tra l'app di frontend e i servizi, e tra i servizi, avviene tramite JSON su HTTP (non sto chiamando i servizi REST qui perché i principi REST non sono strettamente seguiti). JSON (un) marshalling viene eseguito utilizzando Jackson 2.

Poiché Java è un linguaggio tipizzato in modo statico, entrambi i lati devono avere lo stesso modello: se si ottengono dati da un servizio, si modifica una proprietà, quindi la si reinserisce nel servizio, si perderanno i dati se il modello è mancante una proprietà poiché Jackson avrebbe ignorato silenziosamente la proprietà mancante nel processo di deserializzazione.

Poiché devono avere una dipendenza dalla stessa esatta versione del modello di dominio, i servizi devono essere costruiti (ogni volta che il modello cambia solo un po ') e distribuiti insieme, rendendo l'architettura simile a un monolite distribuito.

In che modo questo è tipicamente evitato? Quando si utilizza un linguaggio dinamico come Javascript, tutte le proprietà JSON verranno mantenute anche se il client non è a conoscenza di alcune di esse. Pertanto, il servizio può cambiare senza influenzare il client finché rimane compatibile.

    
posta herman 04.08.2017 - 17:15
fonte

1 risposta

1

Since Java is a statically typed language, both sides need to have the exact same model

Non proprio.

if you get data from a service, change a property, then post it back to the service, you will lose data if your model was missing a property since Jackson will have silently ignored the missing property in the deserialization process.

Perché di solito leghiamo il modello dei dati di servizio a DTO. Questo è tutto.

Recentemente, ho iniziato a giocare con Tolerant Readers anziché con associazioni di dati. 1

Mappare il messaggio su una struttura ad albero di nodi è la chiave per rendere tolleranti i lettori. Come in Javascript, i nuovi campi non verranno ignorati. Il lettore rimarrà semplicemente all'oscuro di loro.

Ovviamente non è un proiettile d'argento, ma l'obiettivo qui è quello di ridurre al minimo la superficie di accoppiamento. 2

Because they need to have a dependency on the exact same version of the domain model, the services have to be built (whenever the model changes just a bit) and deployed together, making the architecture look more like a distributed monolith.

Poche cose qui.

L'accoppiamento

Supponiamo che ci sarà un accoppiamento. Allways. Da qualche parte. Non cercare l'accoppiamento zero perché non esiste. La nostra battaglia contro l'accoppiamento è ridotta a: cercare il posto giusto e tenerlo il più liberamente possibile .

In linea con questi argomenti, dobbiamo scoprire quanto accoppiamento / disaccoppiamento siamo disposti a permetterci.

A questo punto non essere dogmatico, sii pragmatico , perché non stiamo gestendo un'architettura della scala di Amazon o Netflix. Né il nostro bisogno di disaccoppiamento è lo stesso.

Condivisione di modelli di dati

I modelli di dati condivisi sono la radice del male. Idealmente, mappiamo / leggiamo / leggiamo l'essenziale e non permetteremo mai ai nostri binding di andare oltre lo strato anti-corruzione. In altre parole, se i nostri DTO stanno raggiungendo livelli superiori, il problema non è Java. Il problema è la mancanza di livelli di astrazione.

È assolutamente importante mantenere i modelli di dati del dominio inconsapevoli l'un l'altro. Questa è la chiave dei contesti limitati e degli SRP che rappresentano.

distribuzioni

Questo è il motivo per cui alcuni provider API eseguono il controllo delle versioni. Per un po ', la vecchia versione coesiste con quella nuova e i consumatori sono incoraggiati a spostarsi progressivamente da uno all'altro.

In ultima analisi, stiamo parlando di Microservices qui, dovremmo essere in grado di distribuire il numero di cui abbiamo bisogno e tante versioni che riteniamo appropriate. Ogni volta

Se non possiamo, abbiamo ragione dicendo che ...

the architecture looks more like a distributed monolith.

1: Non totalmente, devo dire. Leggo ancora i messaggi alle DTO ma solo a quelli che considero improbabili che cambino o relativamente piccoli.

2: Prendi in considerazione che ogni nuovo DTO che mappiamo contribuisce ad aumentare l'accoppiamento. Diciamo che i DTO aumentano la superficie di accoppiamento.

    
risposta data 04.08.2017 - 22:05
fonte

Leggi altre domande sui tag