<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 9:01 AM, Marco Beri <span dir="ltr"><<a href="mailto:marcoberi@gmail.com" target="_blank">marcoberi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Uno dei rovesci dell'architettura a microservices che trovo davvero duro da digerire è questo:</div><div> <br></div><div><i>"Business transactions that update multiple business entities are fairly common. These kinds of transactions are trivial to implement in a monolithic application because there is a single database. In a microservices-based application, however, you need to update multiple databases owned by different services. Using distributed transactions is usually not an option, and not only because of the CAP theorem. They simply are not supported by many of today’s highly scalable NoSQL databases and messaging brokers."</i></div><div><br></div><div>La soluzione non la trovo utilizzabile in ambito, per esempio, finanziario (ma ammetto di essere ignorante in questo approccio, per questo chiedo un parere qui):</div><div><i><br></i></div><div><i>"You end up having to use an eventual consistency based approach, which is more challenging for developers."</i></div></blockquote></div><br><br>A me questa faccenda non convince in modo eccessivo. Allora, e' normale avere business transactions che coinvolgono piu' entita'? Ovviamente. Capita di continuo.</div><div class="gmail_extra"><br></div><div class="gmail_extra">La quale cosa puo' essere un problema anche semplicemente con una API rest progettata in modo idiota (ma questo non vuole dire che bisogna evitare Rest).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Prendiamo il caso piu' semplice: devo prendere soldi da un conto e mettere soldi su un altro conto. Se la mia API e' qualcosa del tipo</div><div class="gmail_extra"><br></div><div class="gmail_extra">PUT /account/<id>/amount/<new-amount></div><div class="gmail_extra"><br></div><div class="gmail_extra">per esempio, diventa gia' li molto livello fare la normalissima transazione di cui parlavo. Bisogna scrivere parecchia sessione a mano per gestire la cosa in modo opportuno (nb, PUT e' intesa idempotente, quindi devo dirgli quale e' l'amount, non posso dirgli aggiungi o sottrai... oppure potrebbe essere, se voglio aggiungere o sottrarre)</div><div class="gmail_extra"><br></div><div class="gmail_extra">PUT /account/<id>/transaction/<tid>/add/<amount-to-add-or-subtract></div><div class="gmail_extra"><br></div><div class="gmail_extra">Per inciso, questo ha pure il vantaggio che si possono correlare le due operazioni, il che rende tutto parecchio piu' semplice. Non ho voglia di riconcepire gli esempi anche con POST, perche' temo che poi diventi troppo confuso.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ora, un'API vagamente piu' sensata potrebbe avere una faccia tipo</div><div class="gmail_extra"><br></div><div class="gmail_extra">PUT /transaction/<tid>/<src-account>/<dst-account>/<amount></div><div class="gmail_extra"><br></div><div class="gmail_extra">A questo punto la transazione non va piu' gestita a livello HTTP e rimane nel server ed e' molto piu' semplice.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ora tutta questa conversazione ha piuttosto senso se stiamo assumendo di avere i conti correnti in qualcosa che si comporta come un db univoco. Solo che tipicamente i due conti correnti sono due mondi distinti. E infatti le banche non fanno le cose a quel modo punto.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Comunque, il fatto chiaro e' che avere una API invece che l'altra rende le cose (apparentemente) molto piu' facili. E ci indica anche che spezzare in due microservice la gestione di sta roba ci mette punto a capo (incidentalmente, alla fine dei conti dovremo parlare con due banche diverse -- o dire ad una banca cosa deve fare con l'altra, che e' il motivo per cui la prima API e' veramente broken... ma tant'e'). </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Comunque, mi aspettavo che sarebbe stato piu' interessante da leggere. TL;DR, se spezzare una certa cosa in due microservizi porta un mondo di dolore, e' possibile che quei due micro-servizi non siano la scelta giusta. Esattamente come se spezzare la responsibilita' di un oggetto in due oggetti apre a dolore e bachi probabilmente l'API corretta dovrebbe avere un solo oggetto. Questo al di la del livello di dettaglio con cui guardiamo le cose (livello intra-servizio, livello inter-servizio, livello design/OOP). </div><div class="gmail_extra"><br></div><div class="gmail_extra">Questo per me non e' uno svantaggio dei micro-servizi, e' semplicemente una scelta architetturale sbagliata.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>