2015-09-30 10:01 GMT+02:00 Marco Beri <marcob...@gmail.com>:
> 2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti <
> riccardo.magliocche...@gmail.com>:
>
>> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>>>
>>> Uso python. Ultimamente stiamo mettendo su una architettura microservice
>>> che
>>> prevede API gateway piccolissimo in node che fa il dispatch, dietro ci
>>> sono i
>>> microservice python. Abbiamo copiato un po' da qua
>>> https://www.nginx.com/blog/introduction-to-microservices/
>>>
>>
>> link interessante grazie
>
>
> Uno dei rovesci dell'architettura a microservices che trovo davvero duro
> da digerire è questo:
>
> *"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."*
>
> 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):
>
> *"You end up having to use an eventual consistency based approach, which
> is more challenging for developers."*
>
Marco, hai centrato perfettamente il nodo della questione.
In una app monolitica puoi fare:
def purchase_product(product_id, payment_id):
with transaction.atomic():
product = Product.objects.select_for_update().get(pk=prod_id)
if product.status != 'available':
raise ProductNotAvaliable()
product.status = 'purchased'
product.save()
Payment.objects.create(product=product, payment_id=payment_id)
sfruttando alla grande le funzionalità del db relazionale per sincronizzare
l'accesso ai dati e per garantire l'integrità e la consistenza.
Se product e Payment fossero in due microservice differenti, dovremmo
creare una transazione distrubita (XA) e gestire il fallimento a livello
applicativo. Molto + codice, molto + difficile da testare.
L'approccio che propongo, e sul quale sto sperimentando da un po', si basa
su un core monolitico django e *alcuni* microservice periferici che stanno
dietro ad un "frontend application tier" (scusate il nome) in nodejs che
permette l'isomorfismo di parte della app e con API graphql. Tutti questi
componenti girano in container docker. Ultimamente stiamo usando trhift per
la comunicazione interna tra questi "microservice". Stiamo scopiazzando un
po' da facebook ;)
In generale nella maggior parte dei progetti in cui lavoro alla fine non ci
saranno mai sopra più di una decina di sviluppatori, quindi l'architettura
monolitica se ben incapsulata va benissimo. I microservice a noi servono
per gestire un po' meglio la scalabilità e il ciclo di vita dei singoli
componenti e poer poterli scrivere in linguaggi diversi in alcuni casi.
Marco
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
