Please enable JavaScript.
Coggle requires JavaScript to display documents.
Fundamentos de Microservicios V.2 - Coggle Diagram
Fundamentos de Microservicios V.2
Microservicios
◘ Problemas
• Mientras más servicios existan, la complejidad de la mensajería se incrementa con respecto a la formula [(n(n-1))/2].
• El despliegue y escalamiento de microservicios tienen alta dependencia de contenedores que los administren.
• Implementar límites de la transacción entre múltiples microservicios produce una sobrecarga de gestión.
• Mientras más servicios existan, las dependencias y los fallos también incrementan.
◘ Características
• Sistema que cuenta con modulos de servicios pequeños e independientes que se ejecutan en su propio proceso.
• Deben ser simples, basados en las capacidades del negocio con las responsabilidades bien definidas.
• Deben ser desarrollados, desplegados y escalados como entidades independientes basándose en la tecnología de contenedores.
• Debe ser tolerante a fallos debido a que son más propensos por la cantidad de servicios y sus comunicaciones.
• Cada microservicio debe tener su propia BDD.
• Cuenta con un gobierno de servicios que provee la colaboración y coordinación de los diferentes servicios.
• Deben estar desarrollados en lenguaje neutral para que el lenguaje que se utilice en cada servicio no afecte a los demás.
• Cada microservicio debe conocer exclusivamente su funcionalidad.
◘ Beneficios
• Ofrecen facilidad de reemplazo debido a la naturaleza de los microservicios.
• Al mantener un monitoreo adecuado se pueden predecir potenciales fallos y aislarlos.
• El desarrollo de plataformas en contenedores facilita la capacidad de desplegar y escalar un servicio.
• Se alinean fácilmente con la estructura organizacional debido a que están orientados netamente a la funcionalidad del negocio.
• Poseen la propiedad de agilismo.
Evolución de lenguajes de programación
• Primera generación: lenguaje de máquina: tarjetas perforadas.
• Segunda generación: lenguajes ensamblados.
• Tercera generación: lenguajes de alto nivel como fortran, cobol hasta llegar a C, smalltalk de mayor nivel.
• Cuarta generación: lenguajes utilizados para definir las funciones de los servicios externos como protocolos http, etc.
Arquitecturas de sistemas
◘ Mainframe:
• El poder de procesamiento es centralizado
• Múltiples clientes pueden conectarse al sistema central a través de terminales tontas (menos potentes o de bajo nivel)
◘ Cliente-Servidor:
• Servidor potente al que varios clientes se conectan utilizando equipos menos potentes.
◘ Tres capas:
Utiliza una capa de cliente a través de la cual se ingresan datos se valida y finalmente se controla una parte de la lógica del negocio.
Capa de presentación
• Los elementos visuales que se presentan al cliente (interfaz).
• Permite agregar campos con la información que será transferida a las demás capas.
• Permite ingresar datos y presentar al usuario los resultados de su solicitud.
Capa de negocio
• Se gestiona la lógica de funcionamiento de la aplicación.
• Es decir, se define qué hacer con los datos.
• Contiene las validaciones de la aplicación.
Capa de almacenamiento de datos
• Se encarga de guardar y administrar los datos en las bases de datos.
• A la vez que se encarga de mantener la integridad de los datos al agregar o eliminar datos asociados.
◘ N-capas:
• Extensión de la arquitectura de tres capas donde existen multiples servidores de capa media con sus propias BDD y servidores
• Permite mayor control del flujo de datos al contener mayor número de validaciones.
Arquitecturas de red
◘ Punto a punto
• Puede estar presente en las arquitecturas mainframe y cliente-servidor.
• De un lado se encuentra el cliente y del otro lado el servidor, es decir, sólo cumplen una función a la vez.
◘ Hub and Spoke
• Conexiones tipo punto-multipunto.
• Cuenta con un hub (sistema central) en donde se redirige la conexión con otros sistemas.
◘ Enterprise Message Bus
• Utiliza protocolos propietarios de comunicación como por ejemplo el de IBM.
• No permiten ser heterogeneos a nivel de estructura.
• Hace uso de un sistema de colas para solicitudes entrantes.
◘ Enterprise Service Bus
• No existe una relación directa con un único proveedor de servicios.
• Permite la integración de aplicaciones de varios servidores.
Aplicaciones monolíticas
◘ Características
• Todas las funcionalidades son apiladas en una sola aplicación utilizando una arquitectura monolítica.
• Mantenimiento y actualización resulta difícil
◘ Beneficios
• Tiempo de puesta en marcha reducido.
• Facilidad para crear entornos de prueba
• Escalamiento fácil basado en balanceadores de carga.
• Ofrece bastante nivel de productividad cuando se desarrolla con equipos pequeños o individualmente.
◘ Desventajas
• Pueden llegar a ser muy grandes y terminar afectando la productividad del desarrollador.
• No se adapta a las tendencias y últimas tecnologías.
• No es posible integrar la aplicación a soluciones de plataformas distintas.
• Dificulta el desarrollo en equipo.
• La tecnología de la aplicación es establecida al inicio del desarrollo por lo que resulta complicado evolucionar.
• No se puede reutilizar código.
• Es inestable cuando ocurre algún error.
◘ Load Balancer
• Asigna secuencialmente carga de usuarios a varias copias de la misma aplicación con el fin de cumplir con la demanda de solicitudes que se generan
• Muchas copias de la aplicación pueden llegar a consumir muchos recursos hasta el punto de llegar a ser insostenible económicamente.
SOA y ESB
Hace frente a los desafíos de las aplicaciones monolíticas al agrupar las funcionalidades en servicios.
Ofrece los siguientes beneficios:
• Cuentan con interfaces bien definidas que separan el Qué del Cómo.
• Pueden ser accedidos por cualquier cliente utilizando un protocolo estándar de acceso sobre la red.
• Son autónomos (autosuficientes), idempotentes (asegura la integridad del resultado generado al ejecutar la misma operación varias veces) y sin estado (no guarda información de otros procesos).
• Son descubiertos dinámicamente de tal manera que los consumidores sólo se preocupan de la interfaz del servicio.
Servicios
• Cuentan con interfaces bien definidas que son independientes de su implementación.
• Pueden ser accedidos por cualquier cliente utilizando un protocolo estándar de acceso sobre la red.
• Se basan en APIs, de tal manera que los consumidores sólo se preocupan de la interfaz del servicio.
• Son autónomos (autosuficientes), idempotentes (asegura la integridad del resultado generado al ejecutar la misma operación varias veces) y sin estado (no guarda información de otros procesos).