Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es la arquitectura basada en células?

El espacio API evoluciona continuamente, aumenta las opciones y cambia los paradigmas para adaptarse a casos de uso específicos. Esta evolución está impulsada, al menos en parte, por la continua adopción de la tecnología API en el espacio empresarial. Dicho esto, las demandas empresariales son únicas y estas advertencias específicas para los casos de uso tradicionales han creado nuevas soluciones y paradigmas para abordar la complejidad en constante evolución.
La arquitectura basada en células es una de esas soluciones. ¿Qué es esta arquitectura y qué es, específicamente, una célula? Hoy, vamos a sumergirnos en el enfoque basado en células, definir qué es una célula en este contexto y ver un caso de uso hipotético. También describiremos la diferencia entre una arquitectura basada en células y una arquitectura orientada a servicios.
Tenga en cuenta que esta es una descripción general de alto nivel de este enfoque; la solución en sí es bastante complicada. Para casos del mundo real, uno puede sumergirse en la documentación aquí .

El fundamento del enfoque basado en células

A medida que más empresas crean más microservicios, surgen nuevas necesidades. La composición, la seguridad, la capacidad de detección, la gobernanza, la coherencia y la unificación se han convertido en temas más importantes para los usuarios empresariales. Además, el desarrollo continuo y otros paradigmas ágiles han acortado significativamente el tiempo de espera para desarrollar y lanzar, lo que resulta en una fragmentación y una mayor complejidad que ocurre con mayor velocidad y frecuencia.
El enfoque basado en células se diseñó explícitamente para responder a estos problemas y mitigar esas preocupaciones. Según la documentación , la arquitectura basada en células está destinada a abordar este paradigma cambiante y abordar los desafíos futuros que se deriven de él.
La idea general detrás de la arquitectura basada en células es llevar el diseño de microservicios un paso más allá. Al aprovechar las celdas, que son componentes de aplicación y unidades de recursos compuestas por múltiples API, servicios, políticas, etc., la arquitectura basada en celdas tiene como objetivo reducir la complejidad de la unidad y, por lo tanto, proporcionar un control más granular y una mayor capacidad de funcionamiento.
En su nivel más básico, la arquitectura basada en células está diseñada para responder a cuatro realidades caóticas en la arquitectura empresarial:
  • Agilidad , o la capacidad de actuar rápidamente y enfrentar desafíos sin un tiempo de espera significativo;
  • Escalabilidad , la capacidad de aprovechar interfaces versionadas, replicables y bien definidas para satisfacer los cambios en la demanda;
  • Modularidad , o la capacidad de usar estructuras uniformes y definidas para cambiar rápidamente la asignación de recursos y afectar la plataforma general de una manera bien documentada y comprensible; y
  • Gobernanza , o la gestión, seguimiento y control de las políticas organizativas en la práctica en todo el servicio en su totalidad.
Para gestionar todo esto, la arquitectura aboga por el movimiento de recursos hacia una "célula". Pero, ¿qué es, en este contexto, una célula?

¿Qué es una celda?

La arquitectura basada en células se basa en la idea de agrupaciones de servicios y datos en torno a una puerta de enlace asociada con una colección de componentes. Esta colección total se denomina entonces una "celda". Cada celda es independiente de otras celdas y se puede implementar o administrar como entidades separadas de otras celdas. Estas celdas se comunican entre sí a través de un conjunto de puntos finales de red, al igual que lo haría una colección de API de microservicio, con la salvedad de que las políticas y los marcos para esas comunicaciones se integran en cada celda por separado.
Por tanto, cada célula es responsable de proporcionar su propia definición y documentación para la comunicación. El contenido de esas celdas (que según la documentación puede tener componentes 1: n agrupados) está diseñado para ser reutilizable y instanciable en múltiples instancias de celda.
En la aplicación práctica, lo que esto significa es que cada celda es su propio microservicio o microservicios, con sus interacciones gobernadas por sus políticas y configuraciones definidas por la lógica empresarial y el gobierno empresarial. Luego, estos datos se toman de la celda y se envían externamente a otras celdas o al punto final solicitante.
Esta interacción puede ser RESTful, lo que permite una abstracción que se puede consultar y alternar. Puede ser impulsado por eventos, lo que permite que los cambios desencadenen acciones en la celda. O puede ser impulsado por flujo, lo que permite la coincidencia de patrones y el análisis basado en comportamientos dinámicos. En última instancia, la relación celular es una situación en la que la teoría parece una aplicación en la práctica, pero en realidad, puede ser bastante abstraída dependiendo de la implementación final. Veamos una aplicación teórica para ver cómo se ve esto.

Arquitectura basada en células en acción

Supongamos que gestionamos un hotel con un sistema de reservas online. El hotel solía funcionar con un sistema de reserva heredado, pero a medida que desarrollamos nuevos sistemas, nos hemos alejado del monolito y nos hemos dedicado a los microservicios. El hotel también utiliza una colección de API para gestionar el servicio a la habitación, el alquiler de medios y otras actividades.
En el paradigma de la arquitectura basada en células, esto prácticamente se vería como un conjunto de células, cada una autogobernada pero comprensible a través de otras células. Separaríamos los componentes en células relacionadas, normalmente relacionadas por su forma de acción o instanciación. Por ejemplo, es probable que todo lo que tenga que ver con la hospitalidad esté impulsado por eventos (cuando un huésped solicita cobertura, una llamada de atención, etc.). Estos eventos luego desencadenarían algo dentro de esa celda. Por lo tanto, tendría sentido que la celda de hospitalidad existiera como su propia entidad, con un conjunto de extremos embajadores, adaptadores y secundarios para manejar la comunicación celular externa.
Nuestro hotel tiene tres dominios generales que deben ingresarse en celdas:
  • Cell-1:Reservationsmanejará todos los datos de reserva y la actividad y será impulsado por RESTful Web API. Esta celda aprovechará una puerta de enlace lateral para conectarse con los sistemas de datos generales. También tendrá un sistema de gobierno de políticas específico para garantizar que nos adherimos a PCI DSS, informes y otros estándares.
  • Cell-2:Hospitalityutilizará eventos para desencadenar acciones y respaldar a LaundryServices, MediaServices y FoodServices. Como cada uno de estos eventos se maneja desde otras interfaces, usaremos intermediarios para identificar si la solicitud es de un usuario o de un miembro del personal.
  • Cell-3:Legacyserá impulsada por la transmisión, por lo que cuando un usuario usa un código de reserva antiguo o intenta recuperar datos sobre una implementación anterior de la celda anterior, esos datos se pueden extraer de los recursos adecuados. Esto requerirá un sidecar para vincular los datos y un corredor para negociar si los datos son heredados o no.
  • Cell-4:Dataserá nuestra última celda. Alojará todas las bases de datos relacionales y podrá consultarse internamente utilizando puntos finales GraphQL y varias integraciones de sidecar para garantizar un servicio de datos adecuado.

Flujo de código de registro

Supongamos que una persona se queda en el hotel por una noche. Primero hacen su reserva en la API web, que es el primer punto de tránsito en nuestra red. Esto llega al Cell Gateway para Cell-1, que interpreta los datos y utiliza la API interna para llegar Cell-4, que luego almacena estos datos de reserva. Más tarde, cuando el cliente se registra, estos datos se recuperan mediante una solicitud GraphQL por parte del sistema de reservas para validar que los datos retenidos Cell-1Cell-4coinciden con los datos proporcionados por el cliente (matrícula para el estacionamiento del automóvil, identificación para la identidad, etc.)
Ahora que el usuario se ha registrado, su estado Cell-2se actualiza para reflejar que la sala está "activa". Esto se hace haciendo que la ReservationsAPI de Cell actualice la DataAPI de Cell, que es un evento desencadenante que Cell-2monitorea. De aquí en adelante, cualquier solicitud realizada a través de la API web en la celda de Reservas (que es el punto de tránsito con el que interactúa el cliente) se manejará como un evento reenviado Cell-2.
Las solicitudes como el servicio de habitaciones se pueden realizar a través de un cajero automático o un portal en línea. De cualquier manera, esta solicitud se comunica a través Cell-2de Cell Gateway, que solicita al rastreador de eventos que imprima un comando en la estación correspondiente (como un pedido de comida para la cocina o una solicitud de cobertura para el departamento de saneamiento).

Conversión heredada

El cliente es un usuario desde hace mucho tiempo y se ha alojado en el hotel muchas veces anteriormente. Debido a esto, tienen importantes puntos Rewards que se pueden utilizar en el sistema de reservas. Cell-1Sin embargo, debido a que es muy nuevo, estos puntos deben migrarse. Cuando el cliente inicia sesión, usa un formato de número que el sistema de Reservas ha marcado como un número heredado.
En este momento, Cell-1el Gateway notifica al usuario y lo redirige al Cell-3sistema heredado a través de un intermediario de gateway celular. Desde aquí, el cliente puede autenticarse y optar por migrar los datos al sistema moderno. Una vez que se hace esta elección, el sistema heredado agrega una marca a través del sidecar en Cell-4(datos) para actualizar el estado de la cuenta a "migrado", evitando cualquier necesidad adicional de acceder a los sistemas heredados.

El registro de salida

Una vez que el cliente ha terminado con su estancia, baja las escaleras. Solicitan una salida en el mostrador, y todo lo que sucedió cuando salieron se hace a la inversa.

Iteración y desarrollo

Nuestro ejemplo de hotel es un flujo típico de este tipo de arquitectura, pero podemos dar un paso más. Uno podría imaginar un sistema de autenticación para permitir el acceso remoto al gimnasio de un hotel. Esta funcionalidad adicional probablemente requiera una nueva celda.
Si bien otras arquitecturas requerirían que se actualice el sistema de reservas y que se cambien las bases de datos, dentro de la arquitectura basada en celdas, podemos construir la solución completa dentro de una nueva celda y simplemente aprovechar los sistemas existentes para verificar que el número de registro sea válido. . Esta extensibilidad demuestra el poder de la arquitectura basada en células. En esencia, la arquitectura basada en células es un microservicio de microservicios, y al abstraer estos conceptos entre sí y categorizarlos en negocios, lógica y función, el desarrollo ágil y escalable se hace más fácil.
Cabe señalar aquí que la organización en esta hipotética implementación es bastante amplia. En un enfoque de arquitectura completamente basada en células, cada elemento probablemente sería su propia célula. Las recompensas, las reservas y el check-in / check-out probablemente serían sus propias celdas, o al menos organizadas en celdas más pequeñas, a diferencia de la celda singular que se presenta aquí para simplificar

Comparación de servicios orientados y basados ​​en células

Por supuesto, quienes estén familiarizados con la arquitectura orientada a servicios (SOA) pueden ver la arquitectura basada en células como simplemente un cambio de marca de ese enfoque. La realidad es que los dos conceptos están relacionados, pero ocurren en diferentes niveles. Las arquitecturas orientadas a servicios separan los componentes en función de su propósito en el servicio al usuario y, de muchas formas, la arquitectura basada en células también lo hace.
Sin embargo, la arquitectura basada en celdas es una separación aún más específica en el sentido de que cada celda está construida no solo para albergar los componentes específicos para esa función, sino también para facilitar y controlar las interacciones negociadas por declaración de política y propósito. Además, estas celdas están diseñadas y construidas para expandirse y escalar.
Por ejemplo, en la arquitectura basada en servicios, si se implementara otro sistema de recompensas, este (en teoría) se ubicaría fuera del grupo de servicios o simplemente sería un servidor secundario dentro de la colección de servicios centrales. En el enfoque basado en células, como todo se abstrae en entidades únicas, la solución sería simplemente crear una nueva célula, indicar cómo se ve la comunicación intermediada, habilitar las diversas puertas de enlace y los intermediarios necesarios para llevar a cabo esto y, finalmente, habilitar el célula.
En el enfoque de arquitectura basada en células, las cosas se dividen en un nivel más pequeño, y cada célula representa un aspecto o grupo fundamental de una colección más grande de células que en su totalidad representan el servicio.

Reflexiones finales sobre la arquitectura basada en células

El paradigma de la arquitectura basada en células es interesante, pero requiere algunas condiciones específicas para que valga la pena la inversión en tiempo y recursos. La arquitectura basada en células es muy buena para las implementaciones empresariales, especialmente cuando hay una gran cantidad de gobernanza o política incorporada en cada interacción. A decir verdad, la efectividad de un punto de venta importante se reduce a la escala más pequeña de la implementación.
Cuando tiene muchos microservicios diferentes, todos interactuando de una manera específica y limitada, esta es la solución correcta. Si tiene un conjunto de servicios, todos los cuales están relacionados y funcionan con los mismos materiales, y no tiene la intención de escalar, es posible que esta no sea una gran solución, y un enfoque de microservicio más tradicional (o incluso monolito) puede ser más beneficioso.
Que piensas de esta aproximación? ¿Existen casos de uso para implementaciones más pequeñas? Háganos saber a continuación.

Publicar un comentario

0 Comentarios