Muchas aplicaciones modernas deben crearse en toda la empresa, a veces incluso en Internet. Cada aplicación debe cumplir con los requisitos de escalabilidad, disponibilidad, seguridad, confiabilidad y resistencia.
En este artículo, presentaré algunos patrones de diseño que pueden ayudarlo fácilmente a lograr las capacidades anteriores. Repasaré cada patrón, cómo usar este patrón en la nube y cuándo usarlo y cuándo no.
Algunos de estos patrones no son tan nuevos, pero son muy útiles en el mundo actual de la nube de Internet.
Aquí hay una lista de los patrones que discutiré en este artículo:
- Cortacircuitos
- Segregación de responsabilidad de consultas y comandos (CQRS)
- Abastecimiento de eventos
- Sidecar
- Backend para Frontend
- Estrangulador
Entonces empecemos.
1. Disyuntor
Los sistemas distribuidos deben diseñarse teniendo en cuenta las fallas. Hoy en día existen microservicios en el mundo, y estos servicios dependen principalmente de otros servicios remotos. Es posible que estos servicios remotos no respondan a tiempo por diversas razones, como la red, la descarga de aplicaciones, etc. En la mayoría de los casos, la implementación de reintentos debería poder resolver problemas.
Pero a veces puede haber problemas graves como la degradación de los servicios o una falla total de los servicios en sí. No tiene sentido seguir intentándolo de nuevo en tales casos. En este caso, el modelo de interruptor automático puede resultar útil.
El diagrama anterior muestra una implementación del esquema de disyuntor donde cuando el servicio 1 se da cuenta de que el servicio 2 tiene fallas / tiempos de espera continuos, en lugar de reintentar, el servicio 1 deshabilita las llamadas al servicio 2 y devuelve una respuesta en caso de falla.
Existen bibliotecas de código abierto populares como Netflix Hystrix
o Reselience4J que se pueden usar para implementar este patrón con mucha facilidad.
Si utiliza puertas de enlace API o proxies
como Envoy , esto se puede lograr en la propia capa de proxy.
Nota:Es muy importante que se implementen suficientes registros y advertencias cuando la cadena esté abierta para realizar un seguimiento de las solicitudes recibidas durante este tiempo y que el equipo de operaciones sea consciente de ello.
También puede implementar un medio disyuntor para continuar sirviendo a los clientes de servicio con problemas.
Cuando usar este patrón
- Cuando un servicio depende de otro servicio remoto y, en algunos escenarios, es probable que falle.
- Cuando el servicio tiene una dependencia muy fuerte (como los servicios de datos maestros).
Cuando no usar este patrón
- Cuando se trata de dependencias locales, un disyuntor puede generar gastos generales.
2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))
CQRS es un modelo muy útil para aplicaciones modernas de almacenamiento de datos. Se basa en el principio de separar las operaciones de lectura (consulta) y escritura / actualización (comando) en el almacén de datos.
Supongamos que está creando una aplicación que requiere almacenar datos en una base de datos como MySQL / PostgreSQL, etc. Como todo el mundo sabe, al escribir datos en el almacenamiento, una operación debe pasar por varias etapas (por ejemplo, validación, modelado y persistencia) y, por lo tanto, las operaciones típicas de escritura / actualización toman más tiempo que las operaciones simples de lectura.
Cuando usa el mismo almacén de datos para realizar operaciones de lectura y escritura al mismo tiempo y a escala, puede comenzar a ver problemas de rendimiento.
En tales casos, la plantilla CQRS puede resultar útil. El patrón CQRS sugiere usar diferentes modelos de datos para operaciones de lectura y escritura. Algunas variaciones también sugieren el uso de almacenes de datos separados para estos modelos.
Nota: La mayoría de las bases de datos PaaS en estos días brindan la capacidad de crear réplicas legibles ( Google Cloud SQL , Azure SQL DB , Amazon RDS
, etc.) de almacenes de datos, lo que hace que sea mucho más fácil lograr la replicación de datos.
Muchas bases de datos empresariales también ofrecen esta capacidad si se trata de bases de datos locales.
Nota: Algunas personas en estos días también prefieren implementar réplicas legibles como bases de datos NoSQL rápidas y de alto rendimiento como MongoDB y Elasticsearch.
Cuándo usar este patrón
- Cuando busca escalar una aplicación que espera una gran cantidad de lecturas y escrituras
- Cuando desee configurar operaciones de lectura y escritura por separado.
- Cuando sus operaciones de lectura son casi reales o consistentes en última instancia.
Cuando no usar este patrón
- Cuando está creando una aplicación CRUD normal que no espera una gran cantidad de lecturas y escrituras de una sola vez.
3. Abastecimiento de eventos
Un origen de eventos es un patrón de diseño interesante en el que una secuencia de eventos de dominio se almacena como un registro y una vista de registro agregado proporciona el estado actual de la aplicación.
Este patrón se usa comúnmente para sistemas que no pueden pagar bloqueos de almacenamiento de datos y que necesitan mantener el historial de eventos y auditoría, por ejemplo, aplicaciones como hoteles / conferencias / asientos.
Dado un sistema de reserva de habitaciones de hotel donde se espera que los usuarios hagan o cancelen una reserva. Aquí debe almacenar su reserva y cancelación como una serie de eventos. Las habitaciones disponibles se muestran en un resumen antes de cada reserva revisando los registros de eventos.
Nota:La mayoría de los proveedores de servicios en la nube admiten servicios de mensajería como Google Pub / Sub, Azure Service Bus, AWS SQS, etc. Estos servicios, combinados con almacenes de datos sólidos y consistentes, se pueden utilizar para implementar este esquema.
Cuándo usar este patrón
- Cuando las operaciones CRUD normales no son lo suficientemente buenas para cumplir con los requisitos
- Suele ser adecuado para sistemas de reserva de asientos como autobuses, trenes, conferencias, cines, etc. - o para sistemas de comercio electrónico, que consisten en actividades como carritos de compras, pagos, etc.
- Cuando se necesita una auditoría sólida y una reproducción de eventos para crear el estado actual y pasado de las aplicaciones.
Cuando no usar este patrón
- Cuando las operaciones CRUD normales son lo suficientemente buenas para satisfacer las necesidades del usuario.
4. Sidecar (patrón de diseño de sidecar)
El patrón Sidecar se hizo popular con la llegada de los microservicios. En este esquema, el componente de la aplicación se implementa en un proceso o contenedor separado. Esto ayuda a lograr la abstracción y la encapsulación.
Envoy Proxy es uno de los servidores proxy complementarios más populares y se utiliza ampliamente. Le ayuda a desacoplar la funcionalidad principal de la aplicación mediante el uso de una máquina lateral para aislar funciones comunes como redes, observabilidad y seguridad.
Este tipo de sidecar puede ayudar al tipo abstracto de comunicación L4 / L7. Los sidecars como Envoy Proxies incluso ayudan a lograr una mayor seguridad al implementar TLS mutuo.
Puede usar esto en combinación con una red de servicios para lograr una mejor conectividad y seguridad entre diferentes microservicios. Puedes leer más sobre esto en mi artículo anterior .
Cuándo usar este patrón
- Cuando se trata de microservicios numerosos y heterogéneos en una cartera de productos.
- Cuando se trata de aplicaciones heredadas que tienden a no manejar los desafíos de interoperabilidad y seguridad de la nueva era.
Cuando no usar este patrón
- Cuando se trata de un número limitado de servicios que necesitan comunicarse entre sí.
- Aplicaciones pequeñas en las que el despliegue de la silla de ruedas lateral puede resultar antieconómico o incómodo de operar
5. Backend-for-Front (BFF)
En un ciclo de desarrollo de producto típico, los ingenieros de back-end son responsables de crear servicios que interactúan con los almacenes de datos, mientras que los ingenieros de front-end se encargan de crear interfaces de usuario. Las aplicaciones de hoy en día deben crearse teniendo en cuenta tanto los dispositivos móviles como los de escritorio.
Si bien la brecha entre los dispositivos móviles y de escritorio se está acercando en términos de hardware, la conectividad y el uso siguen siendo un desafío para los dispositivos móviles.
En tales escenarios, las plantillas de BFF se vuelven bastante útiles. Aquí, se espera que cree / configure servicios internos para un front-end específico.
Para optimizar el rendimiento de los clientes móviles, es posible que desee crear un servicio de back-end independiente que responda con respuestas ligeras y basadas en páginas.
También es posible que desee utilizar este patrón para agregar varios servicios para reducir la comunicación de datos entre el back-end y el front-end.
Nota: en estos días, si está utilizando una puerta de enlace API, el patrón BFF se puede implementar fácilmente en la propia puerta de enlace y no necesitará prestar servicios por separado.
Cuando usar este patrón
- Cuando desee proporcionar un producto / servicio para varios clientes, como clientes de escritorio y móviles.
- Cuando desee optimizar su respuesta para un tipo específico de cliente.
- Cuando desee reducir las conversaciones entre clientes móviles y diferentes servicios.
- , .
- , .
6. Strangler ( )
Si trabaja para una organización que está en camino de modernizar las aplicaciones, entonces el patrón de diseño estrangulador es imprescindible. El patrón Strangler aboga por construir una superposición de fachada sobre su legado y su nueva aplicación, dando a los consumidores la capacidad de ver las cosas de manera objetiva.
Este patrón separa a los clientes de la actividad de migración entre las partes antiguas y nuevas de la aplicación.
Nota: En una organización de TI típica, si está migrando de un sistema ERP a otro, este tipo de esquema será extremadamente útil. Si está utilizando la API de puerta de enlace, será más fácil implementar esto en la puerta de enlace proxy.
Debe decidir si desea mantener el complemento (fachada) al final de la migración o eliminarlo.
Cuando usar este patrón
- Cuando está migrando o actualizando una aplicación compleja y altamente dependiente, como una migración de ERP
Cuando no usar este patrón
- Cuando la migración es fácil y el reemplazo directo es la mejor opción.