Patrón de capa anticorrupción

PDFRSS

Intención

El patrón de capa anticorrupción (ACL) actúa como una capa de mediación que traduce la semántica del modelo de dominio de un sistema a otro. Traduce el modelo del contexto limitado ascendente (monolito) a un modelo que se adapta al contexto limitado descendente (microservicio) antes de consumir el contrato de comunicación establecido por el equipo de gestión inicial. Este patrón puede aplicarse cuando el contexto limitado descendente contiene un subdominio central o el modelo ascendente es un sistema heredado que no se puede modificar. También reduce el riesgo de transformación y la interrupción de la actividad empresarial, ya que evita que las personas que llaman cambien de forma que las llamadas tengan que redirigirse de forma transparente al sistema de destino.

Motivación

Durante el proceso de migración, cuando una aplicación monolítica se migra a microservicios, es posible que se produzcan cambios en la semántica del modelo de dominio del servicio recién migrado. Cuando las funciones del monolito sean necesarias para llamar a estos microservicios, las llamadas deben enrutarse al servicio migrado sin necesidad de realizar cambios en los servicios de llamadas. El patrón ACL permite al monolito llamar a los microservicios de forma transparente, ya que actúa como un adaptador o una capa de fachada que traduce las llamadas a la semántica más reciente.

Aplicabilidad

Considere la posibilidad de utilizar este patrón cuando:

• La aplicación monolítica existente tiene que comunicarse con una función que se ha migrado a un microservicio, y el modelo y la semántica del dominio del servicio migrado difieren de la función original.

• Dos sistemas tienen una semántica diferente y necesitan intercambiar datos, pero no resulta práctico modificar un sistema para que sea compatible con el otro.

• Desea utilizar un enfoque rápido y simplificado para adaptar un sistema a otro con un impacto mínimo.

• La aplicación se comunica con un sistema externo.

Problemas y consideraciones

• Dependencias entre equipos: cuando los distintos servicios de un sistema pertenecen a diferentes equipos, la nueva semántica del modelo de dominio de los servicios migrados puede provocar cambios en los sistemas de llamadas. Sin embargo, es posible que los equipos no puedan realizar estos cambios de forma coordinada, porque es posible que tengan otras prioridades. La ACL desacopla a las personas que llaman y las traduce para que coincidan con la semántica de los nuevos servicios, lo que evita que las personas que llaman tengan que realizar cambios en el sistema actual.

• Sobrecarga operativa: el funcionamiento y el mantenimiento del patrón de ACL requieren un esfuerzo adicional. Este trabajo incluye la integración de la ACL con las herramientas de monitoreo y alerta, el proceso de publicación y los procesos de integración y entrega continuas (CI/CD).

• Punto único de fallo: cualquier fallo en la ACL puede impedir el acceso al servicio de destino y provocar problemas en las aplicaciones. Para mitigar este problema, debe incorporar capacidades de reintento y disyuntores. Consulte los patrones de reintento con retardo y disyuntor para obtener más información sobre estas opciones. La configuración de las alertas y el registro adecuados mejorará el tiempo medio de resolución (MTTR).

• Deuda técnica: Como parte de su estrategia de migración o modernización, considere si la ACL será una solución transitoria o provisional, o una solución a largo plazo. Si se trata de una solución provisional, debe registrar la ACL como deuda técnica y desmantelarla una vez que se hayan migrado todas las llamadas dependientes.

• Latencia: la capa adicional puede introducir latencia debido a la conversión de las solicitudes de una interfaz a otra. Se recomienda definir y probar la tolerancia al rendimiento en las aplicaciones que son sensibles al tiempo de respuesta antes de implementar la ACL en los entornos de producción.

• Cuello de botella de escalado: en aplicaciones con una carga elevada, en las que los servicios pueden ampliarse hasta alcanzar picos de carga, la ACL puede convertirse en un cuello de botella y provocar problemas de escalado. Si el servicio de destino se amplía según la demanda, debe diseñar la ACL para que escale en consecuencia.

• Implementación compartida o específica del servicio: puede diseñar la ACL como un objeto compartido para convertir y redirigir las llamadas a varios servicios o clases de servicios específicos. Tenga en cuenta la latencia, el escalado y la tolerancia a los errores al determinar el tipo de implementación de la ACL.

Implementación

Puede implementar la ACL en su aplicación monolítica como una clase específica del servicio que se está migrando o como un servicio independiente. La ACL debe retirarse una vez que todos los servicios dependientes se hayan migrado a la arquitectura de microservicios.

Arquitectura de alto nivel

En la siguiente arquitectura de ejemplo, una aplicación monolítica tiene tres servicios: servicio de usuario, servicio de carrito y servicio de cuentas. El servicio de carrito depende del servicio de usuario y la aplicación utiliza una base de datos relacional monolítica.

En la siguiente arquitectura, el servicio de usuario se ha migrado a un nuevo microservicio. El servicio de carrito llama al servicio de usuario, pero la implementación ya no está disponible en el monolito.  También es probable que la interfaz del servicio recién migrado no coincida con la interfaz anterior, cuando estaba dentro de la aplicación monolítica.

Si el servicio de carrito tiene que llamar directamente al servicio de usuario recién migrado, será necesario realizar cambios en el servicio de carrito y realizar pruebas exhaustivas de la aplicación monolítica. Esto puede aumentar el riesgo de transformación y la interrupción del negocio. El objetivo debe ser minimizar los cambios en la funcionalidad existente de la aplicación monolítica.

En este caso, le recomendamos que introduzca una ACL entre el servicio de usuario anterior y el servicio de usuario recién migrado. La ACL funciona como un adaptador o una fachada que convierte las llamadas en la interfaz más nueva. La ACL se puede implementar dentro de la aplicación monolítica como una clase (por ejemplo, UserServiceFacade oUserServiceAdapter) específica del servicio que se migró. La capa anticorrupción debe retirarse una vez que todos los servicios dependientes se hayan migrado a la arquitectura de microservicios.

Implementación mediante servicios AWS

El siguiente diagrama muestra cómo puede implementar este ejemplo de ACL mediante AWS servicios.

El microservicio de usuario se migra fuera de la aplicación monolítica de ASP.NET y se implementa como una función AWS Lambdaen AWS. Las llamadas a la función Lambda se enrutan a través de Amazon API Gateway. La ACL se implementa en el monolito para traducir la llamada y adaptarla a la semántica del microservicio del usuario.

Cuando se Program.cs llama al servicio de usuario (UserInMonolith.cs) dentro del monolito, la llamada se enruta a la ACL (). UserServiceACL.cs La ACL traduce la llamada a la nueva semántica e interfaz, y llama al microservicio a través del punto final de API Gateway. La persona que llama (Program.cs) no conoce la traducción y el enrutamiento que tienen lugar en el servicio de usuario y en la ACL. Como la persona que llama no está al tanto de los cambios en el código, se producen menos interrupciones en el negocio y se reduce el riesgo de transformación.

Código de muestra

El siguiente fragmento de código proporciona los cambios en el servicio original y la implementación de. UserServiceACL.cs Cuando se recibe una solicitud, el servicio de usuario original llama a la ACL. La ACL convierte el objeto de origen para que coincida con la interfaz del servicio recién migrado, llama al servicio y devuelve la respuesta a la persona que llama.

public class UserInMonolith: IUserInMonolith
{
    private readonly IACL _userServiceACL;
    public UserInMonolith(IACL userServiceACL) => (_userServiceACL) = (userServiceACL);
    public async Task<HttpStatusCode> UpdateAddress(UserDetails userDetails)
    {
        //Wrap the original object in the derived class 
        var destUserDetails = new UserDetailsWrapped("user", userDetails);
        //Logic for updating address has been moved to a microservice
        return await _userServiceACL.CallMicroservice(destUserDetails);
    }
}

public class UserServiceACL: IACL
{
    static HttpClient _client = new HttpClient();
    private static string _apiGatewayDev = string.Empty;

    public UserServiceACL()
    {
        IConfiguration config = new ConfigurationBuilder().AddJsonFile(AppContext.BaseDirectory + "../../../config.json").Build();
        _apiGatewayDev = config["APIGatewayURL:Dev"];
        _client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
    }
    public async Task<HttpStatusCode> CallMicroservice(ISourceObject details)
    {
        _apiGatewayDev +=  "/" + details.ServiceName;
        Console.WriteLine(_apiGatewayDev);

        var userDetails = details as UserDetails;
        var userMicroserviceModel = new UserMicroserviceModel();
        userMicroserviceModel.UserId = userDetails.UserId;
        userMicroserviceModel.Address = userDetails.AddressLine1 + ", " + userDetails.AddressLine2;
        userMicroserviceModel.City = userDetails.City;
        userMicroserviceModel.State = userDetails.State;
        userMicroserviceModel.Country = userDetails.Country;

        if (Int32.TryParse(userDetails.ZipCode, out int zipCode))
        {
            userMicroserviceModel.ZipCode = zipCode;
            Console.WriteLine("Updated zip code");
        }
        else
        {
            Console.WriteLine("String could not be parsed.");
            return HttpStatusCode.BadRequest;
        }

        var jsonString = JsonSerializer.Serialize<UserMicroserviceModel>(userMicroserviceModel);
        var payload = JsonSerializer.Serialize(userMicroserviceModel);
        var content = new StringContent(payload, Encoding.UTF8, "application/json");

        var response = await _client.PostAsync(_apiGatewayDev, content);
        return response.StatusCode;
    }  
}

GitHub repositorio

Para obtener una implementación completa de la arquitectura de ejemplo para este patrón, consulte el GitHub repositorio en https://github.com/aws-samples/anti-corruption-layer-pattern.

Contenido relacionado

• Patrón de higo estrangulador

• Patrón de disyuntores

• Patrón de reintento con retroceso