2015-09-30 10:34 GMT+02:00 Marco Beri <marcob...@gmail.com>: > On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron <mi...@python.it> wrote: >> Già, è un bel casino. Dato che non sempre la consistenza eventuale è >> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte >> le complicazioni del caso. > > "The main disadvantage to this algorithm is that it cannot recover in the > event the network is segmented in any manner. The original 3PC algorithm > assumes a fail-stop model, > where processes fail by crashing and crashes can be accurately detected, and > does not work with network partitions or asynchronous communication: > > Brrr...
Riporto un dialogo immaginario tra me e un personaggio fittizio che chiamerò Pelatone™ per proteggerne l'identità. me non c'è soluzione, al problema del partitioning ma nemmeno con nessuna replica master-master relazionale quindi è un problema comune Pelatone certo ma tu useresti un db replicato in una applicazione finanziaria per esempio? me se lo devo scalare sui c100k non vedo grosse alternative Pelatone ok 100.000 connessioni al secondo in una app finanziaria... uhm... solo la borsa mi sa però in quel caso lì io devo essere sicuro delle transazioni... come faranno? me evitano accuratamente che il sistema si partizioni :D Pelatone :D :D bella roba... allora è come dicevo io... non si usano i microservizi in una app finanziaria me ripeto, il problema del partitioning non è insito nei microservizi ce l'hai anche nello sharding solo la replica master/slave ne è immune ma presenta forti limiti di scalabilità, infatti poi non è vero che il fail-stop model è sempre la soluzione migliore per esempio la borsa. se la cina si isola, il sistema borsa crolla? no, si formano due isole indipendenti; il mercato va avanti da una parte senza la cina, dall'altra solo con la cina e poi qualche povero deficente riconcilia il casino ammano :-/ hai indubbiamente perso consistenza. ma è la migliore quantità di consistenza che puoi ottenere in un sistema distribuito peer e non c'è nessun "non me lo posso permettere" che tenga, punto. >> Probabilmente è vero che l'architettura a >> microservizi è da adottare quando ulteriori evoluzioni o scale up di >> software monolitico diventano troppo >> complesse/costose/rischiose/wathever. > > Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura che > hai scelto te la tieni e la manutieni col sudore e con le lacrime :-) non è sempre vero. se hai solo problemi evolutivi, succederà che il costo evolutivo diventerà insopportabile ed il sistema stagnerà finché qualcuno non propone una alternativa più economica. se invece devi anche scalare (per esempio, per adattare il tuo sistema nazionale ad un nuovo mercato), allora se il costo complessivo di riscrittura è inferiore a quello evolutivo, riscrivere conviene (ipotizzando che la riscrittura abbassi la complessità/migliori le prestazioni/etc di ordini di grandezza) ㎝ -- |:**THE BEER-WARE LICENSE** (*Revision 42*): | <mi...@python.it> wrote this mail. As long as you retain | this notice you can do whatever you want with this stuff. | If we meet some day, and you think this stuff is worth it, | you can buy me a beer in return. | --Carlo Miron : _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
