Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Decomponi per transazioni
In un sistema distribuito, un'applicazione deve in genere chiamare più microservizi per completare una transazione aziendale. Per evitare problemi di latenza o problemi di commit in due fasi, puoi raggruppare i tuoi microservizi in base alle transazioni. Questo schema è appropriato se consideri importanti i tempi di risposta e i diversi moduli non creano un monolite dopo averli impacchettati. Nella seguente tabella sono descritti i vantaggi e gli svantaggi di questo modello.
Vantaggi | Svantaggi |
---|---|
|
|
Nella figura seguente, il monolite assicurativo è suddiviso in più microservizi in base alle transazioni.
In un sistema assicurativo, una richiesta di risarcimento viene in genere contrassegnata a un cliente dopo essere stata inviata. Ciò significa che un servizio di reclami non può esistere senza un microservizio del Cliente. Vendite e clienti sono raggruppati in un unico pacchetto di microservizi e una transazione commerciale richiede il coordinamento con entrambi.