{"id":4424,"date":"2018-01-10T21:21:37","date_gmt":"2018-01-11T05:21:37","guid":{"rendered":"http:\/\/www.couchbase.com\/blog\/?p=4424"},"modified":"2023-06-23T09:00:33","modified_gmt":"2023-06-23T16:00:33","slug":"saga-pattern-implement-business-transactions-using-microservices-part","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/saga-pattern-implement-business-transactions-using-microservices-part\/","title":{"rendered":"Saga Pattern | Transacciones de aplicaciones utilizando microservicios - Parte I"},"content":{"rendered":"

\"\"<\/a><\/p>\n

Las transacciones son una parte esencial de las aplicaciones. Sin ellas, ser\u00eda imposible mantener la coherencia de los datos.<\/span><\/p>\n

Uno de los tipos de transacciones m\u00e1s potentes es el llamado Two-Phase Commit, que se resume cuando <\/span>el commit de una primera transacci\u00f3n depende de la finalizaci\u00f3n de una segunda.<\/span> Es \u00fatil sobre todo cuando hay que actualizar varias entidades al mismo tiempo, como confirmar un pedido y actualizar las existencias a la vez. <\/span><\/p>\n

Sin embargo, cuando realizas orquestaci\u00f3n de microservicios, por ejemplo, las cosas se complican. Cada servicio es un sistema aparte con su propia base de datos, y ya no puedes aprovechar la simplicidad de los two-phase-commits locales para mantener la consistencia de todo tu sistema.<\/span><\/p>\n

Cuando se pierde esta capacidad, RDBMS se convierte en una opci\u00f3n bastante mala para el almacenamiento, ya que se podr\u00eda lograr la misma \"transacci\u00f3n at\u00f3mica de entidad \u00fanica\" pero docenas de veces m\u00e1s r\u00e1pido con s\u00f3lo usar un Base de datos NoSQL<\/a> como Couchbase. Por eso, la mayor\u00eda de las empresas que trabajan con microservicios tambi\u00e9n utilizan NoSQL.<\/span><\/p>\n

Para ejemplificar este problema, considere la siguiente arquitectura de Microservicios de alto nivel de un sistema de comercio electr\u00f3nico:<\/span><\/p>\n

\"\"<\/p>\n

En el ejemplo anterior, no se puede hacer un pedido, cobrar al cliente, actualizar el stock y enviarlo a reparto todo en una \u00fanica transacci\u00f3n ACID. Para ejecutar todo este flujo de forma coherente, ser\u00eda necesario crear una transacci\u00f3n distribuida.<\/span><\/p>\n

Todos sabemos lo dif\u00edcil que es implementar cualquier cosa distribuida, y las transacciones, por desgracia, no son una excepci\u00f3n. Tratar con estados transitorios, consistencia eventual entre servicios, aislamientos y reversiones son escenarios que deben ser considerados durante la fase de dise\u00f1o.<\/span><\/p>\n

Afortunadamente<\/span> ya se nos ocurrieron algunos buenos patrones para ello, ya que llevamos m\u00e1s de 20 a\u00f1os implementando transacciones distribuidas. El que me gustar\u00eda hablar hoy se llama patr\u00f3n Saga.<\/span><\/p>\n

El patr\u00f3n SAGA<\/b><\/h2>\n

A patr\u00f3n de la saga<\/strong> es una secuencia de transacciones locales en la que cada transacci\u00f3n actualiza datos dentro de un \u00fanico servicio. La primera transacci\u00f3n de una saga se inicia mediante una solicitud externa correspondiente a la operaci\u00f3n del sistema y, a continuaci\u00f3n, cada paso posterior se desencadena por la finalizaci\u00f3n del anterior.<\/p>\n

Uno de los patrones m\u00e1s conocidos para las transacciones distribuidas se llama Saga. El primer art\u00edculo al respecto<\/span> se public\u00f3 en 1987<\/span><\/a> y las sagas han sido un<\/span> soluci\u00f3n desde entonces.<\/span><\/p>\n

Utilizando nuestro ejemplo anterior de comercio electr\u00f3nico, en un dise\u00f1o de muy alto nivel una implementaci\u00f3n del patr\u00f3n saga tendr\u00eda el siguiente aspecto:<\/span><\/p>\n

\"saga<\/p>\n

Hay un par de maneras diferentes de implementar una transacci\u00f3n saga, pero los dos m\u00e1s populares son:<\/span><\/p>\n