Arquitectura de microservicio - Introducción
El microservicio es una metodología de desarrollo de aplicaciones basada en servicios. En esta metodología, las grandes aplicaciones se dividirán en unidades de servicio independientes más pequeñas. El microservicio es el proceso de implementación de la Arquitectura orientada a servicios (SOA) dividiendo la aplicación completa como una colección de servicios interconectados, donde cada servicio atenderá solo una necesidad comercial.
El concepto de ser micro
En una arquitectura orientada a servicios, los paquetes de software completos se subdividirán en pequeñas unidades de negocio interconectadas. Cada una de estas unidades de pequeñas empresas se comunicará entre sí mediante diferentes protocolos para ofrecer negocios exitosos al cliente. Ahora la pregunta es, ¿en qué se diferencia la Arquitectura de microservicio (MSA) de la SOA? En una palabra, SOA es un patrón de diseño y Microservice es una metodología de implementación para implementar SOA o podemos decir que Microservice es un tipo de SOA.
A continuación se presentan algunas reglas que debemos tener en cuenta al desarrollar una aplicación orientada a microservicios.
Independent - Cada microservicio debe poder implementarse de forma independiente.
Coupling - Todos los microservicios deben estar acoplados libremente entre sí de modo que los cambios en uno no afecten al otro.
Business Goal - Cada unidad de servicio de toda la aplicación debe ser la más pequeña y capaz de ofrecer un objetivo comercial específico.
Consideremos un ejemplo de portal de compras en línea para comprender el microservicio en profundidad. Ahora, dividamos todo este portal de comercio electrónico en unidades de pequeñas empresas, como gestión de usuarios, gestión de pedidos, registro, gestión de pagos, gestión de entregas, etc. Un pedido exitoso debe pasar por todos estos módulos en un tiempo específico. marco. A continuación se muestra la imagen consolidada de diferentes unidades de negocio asociadas a un sistema de comercio electrónico.
Cada uno de estos módulos comerciales debe tener su propia lógica comercial y partes interesadas. Se comunican con otros softwares de proveedores externos para algunas necesidades específicas y también entre ellos. Por ejemplo, la gestión de pedidos puede comunicarse con la gestión de usuarios para obtener información del usuario.
Ahora, considerando que está ejecutando un portal de compras en línea con todas estas unidades de negocios mencionadas anteriormente, necesita alguna aplicación de nivel empresarial que consta de diferentes capas, como front-end, back-end, base de datos, etc. Si su aplicación no está escalada y completamente desarrollado en un solo archivo war, entonces se llamará como una aplicación monolítica típica. Según IBM, una aplicación monolítica típica debería poseer la siguiente estructura de módulo internamente, donde solo un punto final o aplicación será responsable de manejar todas las solicitudes de los usuarios.
En la imagen de arriba, puede ver diferentes módulos como Base de datos para almacenar diferentes usuarios y datos comerciales. En el front-end, tenemos diferentes dispositivos donde generalmente procesamos datos de usuarios o negocios para su uso. En el medio, tenemos un paquete que puede ser un archivo EAR o WAR implementable que acepta solicitudes desde el final del usuario, las procesa con la ayuda de los recursos y las devuelve a los usuarios. Todo irá bien hasta que las empresas quieran realizar cambios en el ejemplo anterior.
Considere los siguientes escenarios en los que debe cambiar su aplicación de acuerdo con las necesidades comerciales.
La unidad de negocio necesita algunos cambios en el módulo "Búsqueda". Luego, debe cambiar todo el proceso de búsqueda y volver a implementar su aplicación. En ese caso, está reasignando sus otras unidades sin ningún cambio en absoluto.
Ahora, nuevamente, su unidad de negocios necesita algunos cambios en el módulo "Check out" para incluir la opción "billetera". Ahora tiene que cambiar su módulo "Check out" y volver a implementar el mismo en el servidor. Tenga en cuenta que está volviendo a implementar los diferentes módulos de sus paquetes de software, mientras que nosotros no le hemos realizado ningún cambio. Aquí viene el concepto de arquitectura orientada a servicios más específico para la arquitectura de microservicios. Podemos desarrollar nuestra aplicación monolítica de tal manera que todos y cada uno de los módulos del software se comporten como una unidad independiente, capaz de manejar una sola tarea comercial de forma independiente.
Considere el siguiente ejemplo.
En la arquitectura anterior, no estamos creando ningún archivo ear con un servicio compacto de extremo a extremo. En cambio, estamos dividiendo diferentes partes del software al exponerlas como un servicio. Cualquier parte del software puede comunicarse fácilmente entre sí consumiendo los servicios respectivos. Así es como el microservicio juega un papel importante en las aplicaciones web modernas.
Comparemos nuestro ejemplo de carrito de compras en la línea de microservicio. Podemos desglosar nuestro carrito de compras en los diferentes módulos como "Buscar", "Filtro", "Pagar", "Carrito", "Recomendación", etc. Si queremos construir un portal de carrito de compras, entonces tenemos que construir el módulos mencionados anteriormente de tal manera que puedan conectarse entre sí para brindarle una buena experiencia de compra 24x7.
Ventajas desventajas
A continuación se muestran algunos puntos sobre las ventajas de usar microservicios en lugar de usar una aplicación monolítica.
Ventajas
Small in size- Microservicios es una implementación del patrón de diseño SOA. Se recomienda mantener su servicio tanto como pueda. Básicamente, un servicio no debe realizar más de una tarea comercial, por lo que obviamente será de tamaño pequeño y fácil de mantener que cualquier otra aplicación monolítica.
Focused- Como se mencionó anteriormente, cada microservicio está diseñado para entregar solo una tarea comercial. Al diseñar un microservicio, el arquitecto debe preocuparse por el punto focal del servicio, que es su entrega. Por definición, un microservicio debe ser de pila completa y debe comprometerse a entregar solo una propiedad comercial.
Autonomous- Cada microservicio debe ser una unidad de negocio autónoma de toda la aplicación. Por lo tanto, la aplicación se acopla de manera más flexible, lo que ayuda a reducir el costo de mantenimiento.
Technology heterogeneity- El microservicio admite diferentes tecnologías para comunicarse entre sí en una unidad de negocio, lo que ayuda a los desarrolladores a utilizar la tecnología correcta en el lugar correcto. Al implementar un sistema heterogéneo, se puede obtener la máxima seguridad, velocidad y un sistema escalable.
Resilience- La resiliencia es una propiedad de aislar una unidad de software. El microservicio sigue un alto nivel de resiliencia en la metodología de construcción, por lo tanto, cuando una unidad falla, no afecta a todo el negocio. La resiliencia es otra propiedad que implementa un sistema altamente escalable y menos acoplado.
Ease of deployment- Como toda la aplicación está subdividida en pequeñas unidades, cada componente debe ser de pila completa. Todos ellos se pueden implementar en cualquier entorno de manera muy sencilla con menos complejidad de tiempo a diferencia de otras aplicaciones monolíticas del mismo tipo.
A continuación, se presentan algunos puntos sobre las desventajas de la arquitectura de microservicios.
Desventajas
Distributed system- Debido a la heterogeneidad técnica, se utilizarán diferentes tecnologías para desarrollar diferentes partes de un microservicio. Se requiere un gran conjunto de profesionales capacitados para admitir este gran software distribuido heterogéneo. Por lo tanto, la distribución y la heterogeneidad son una de las principales desventajas del uso de microservicios.
Cost - El microservicio es costoso, ya que debe mantener un espacio de servidor diferente para diferentes tareas comerciales.
Enterprise readiness- La arquitectura de microservicio puede considerarse como un conglomerado de diferentes tecnologías, ya que la tecnología evoluciona día a día. Por lo tanto, es bastante difícil hacer que una empresa de aplicaciones de microservicio esté lista para compararla con el modelo de desarrollo de software convencional.
Microservicio sobre SOA
La siguiente tabla enumera ciertas características de SOA y microservicio, destacando la importancia de usar microservicio sobre SOA.
| Componente | SOA | Microservicio |
|---|---|---|
| Patrón de diseño | SOA es un paradigma de diseño para software informático, donde los componentes de software se exponen al mundo exterior para su uso en forma de servicios. | Micro Service es parte de SOA. Es una implementación especializada de SOA. |
| Dependencia | Las unidades de negocio dependen unas de otras. | Todas las unidades de negocio son independientes entre sí. |
| Talla | El tamaño del software es mayor que el del software convencional. | El tamaño del software es pequeño. |
| Tecnología | La pila de tecnología es menor que Microservicio. | El microservicio es de naturaleza heterogénea ya que se utilizan tecnologías exactas para realizar una tarea específica. Los microservicios pueden considerarse como un conglomerado de muchas tecnologías. |
| Autónomo y Foco | Las aplicaciones SOA están diseñadas para realizar múltiples tareas comerciales. | Las aplicaciones de microservicio están diseñadas para realizar una única tarea empresarial. |
| Naturaleza | De naturaleza monolítica. | Pila completa en la naturaleza. |
| Despliegue | La implementación requiere mucho tiempo. | La implementación es muy sencilla. Por lo tanto, llevará menos tiempo. |
| Rentabilidad | Más rentable. | Menos rentable. |
| Escalabilidad | Menos en comparación con los microservicios. | Totalmente escalado. |
| Ejemplo | Consideremos una solicitud de reserva de CAB en línea. Si queremos construir esa aplicación usando SOA, entonces sus unidades de software serán:
|
Si la misma aplicación se crea utilizando una arquitectura de microservicio, entonces sus API serán:
|