no podemos definir simplemente como … los microservicios se utilizan para dividir nuestra aplicación y la acoplamos libremente.
En el desarrollo de software, las aplicaciones heredadas a gran escala se desarrollan en base a SOA.
Hoy en día, las industrias de desarrollo de software utilizan microservicios en lugar de SOA.
- ¿Cuál es la IA más inteligente para descargar en este momento?
- ¿Cuál es el mejor conjunto de herramientas automatizadas para la modernización heredada?
- Tengo 34 años, estoy a punto de completar un BSc en Matemáticas Aplicadas. Hice C ++ en mi primer año. ¿Cómo puedo mejorar la programación C / C ++ para ingresar al Desarrollo de Software?
- ¿Cuáles son los mayores errores conocidos de los programadores?
- ¿Hay algún sitio web donde pueda obtener entrevistas de software reales con empresas tecnológicas mediante la resolución de problemas de codificación?
SOA es un patrón arquitectónico para softwares de diseño.
En estos días, hay muchas discusiones sobre Microservicios en el lugar de trabajo o en conversaciones tecnológicas. Y si ha trabajado con SOA anteriormente, podría preguntarse cuál es la diferencia entre SOA y Microservicios. Aquí hay una comparación de ambas arquitecturas en detalles.
1. SOA
Una arquitectura orientada a servicios es un patrón de arquitectura de software, cuyos componentes de aplicación proporcionan servicios a otros componentes a través de un protocolo de comunicaciones a través de una red. La comunicación puede involucrar el paso simple de datos o podría involucrar dos o más servicios que coordinan servicios de conexión entre sí. Los servicios (como los servicios web RESTful) llevan a cabo algunas funciones pequeñas, como validar un pedido, activar una cuenta o proporcionar servicios de carrito de compras.
Hay 2 roles principales en SOA, un proveedor de servicios y un consumidor de servicios. Un agente de software puede desempeñar ambos roles. La capa del consumidor es el punto donde los consumidores (usuarios humanos, otros servicios o terceros) interactúan con la SOA y la capa del proveedor consta de todos los servicios definidos dentro de la SOA. La siguiente figura muestra una vista rápida de una arquitectura SOA.
Enterprise Service Bus (ESB) es un estilo de la arquitectura de integración que permite la comunicación a través de un bus de comunicación común que consiste en una variedad de conexiones punto a punto entre proveedores y consumidores. Además de lo anterior, el almacenamiento de datos se comparte dentro de todos los servicios en SOA.
Ahora, echemos un vistazo a la arquitectura de Microservicios, luego comparemos ambos juntos.
2. Arquitectura de microservicios
Microservices es un patrón de arquitectura de software en el que las aplicaciones complejas se componen de pequeños procesos independientes que se comunican entre sí mediante API independientes del lenguaje.
Los microservicios deben ser una necesidad real en la arquitectura del sistema, ya que podrían diseñarse incorrectamente. Significa que un servicio debe poder implementarse de manera independiente, o ser capaz de cerrar un servicio cuando no es necesario en el sistema y eso no debería tener ningún impacto en otros servicios. La siguiente figura muestra una vista rápida de una arquitectura de microservicios.
Como se muestra arriba, cada servicio tiene su propia base de datos o una base de datos se comparte entre algunos de los microservicios.
3) Arquitectura de microservicios vs. SOA
Como se discutió anteriormente, ambas arquitecturas tienen ventajas y desventajas similares y algunas diferencias. En ambas arquitecturas, cada servicio, a diferencia de una arquitectura monolítica, tiene una cierta responsabilidad. Por lo tanto, los servicios se pueden desarrollar en varias pilas tecnológicas que aportan diversidad tecnológica al equipo de desarrollo. El desarrollo de los servicios puede organizarse dentro de múltiples equipos, sin embargo, cada equipo necesita saber sobre el mecanismo de comunicación común en SOA.
En microservicios, los servicios pueden operar y desplegarse independientemente de otros servicios, a diferencia de SOA. Por lo tanto, es más fácil implementar nuevas versiones de servicios con frecuencia o escalar un servicio de forma independiente.
En SOA, ESB podría convertirse en un único punto de falla que afecta a toda la aplicación. Dado que cada servicio se está comunicando a través de ESB, si uno de los servicios se ralentiza, podría provocar que el ESB se obstruya con solicitudes de ese servicio. Por otro lado, los microservicios son mucho mejores en tolerancia a fallas. Por ejemplo, si hay una pérdida de memoria en un microservicio, solo ese microservicio se verá afectado. Los otros microservicios continuarán manejando las solicitudes.
En ambas arquitecturas, los desarrolladores deben lidiar con la complejidad de la arquitectura y un sistema distribuido. Los desarrolladores deben implementar el mecanismo de comunicación entre servicios entre microservicios (si la cola de mensajes se usa en arquitecturas de microservicios) o dentro de ESB y servicios.
Examen de la unidad es más difícil ya que los desarrolladores deben burlarse del mecanismo de comunicación en las pruebas. Debido a muchos tipos de servicios diferentes, la implementación y la complejidad operativa son una preocupación en ambas arquitecturas.
En SOA, los servicios comparten el almacenamiento de datos (como se muestra en la Figura 1) mientras que cada servicio puede tener un almacenamiento de datos independiente en microservicios. Compartir el almacenamiento de datos tiene sus ventajas y desventajas. por ejemplo, los datos pueden ser reutilizados por todos los servicios mientras que conlleva dependencia y estrechamente acoplado dentro de los servicios.
Por último, pero no menos importante, la principal diferencia entre SOA y microservicios radica en el tamaño y el alcance. El microservicio tiene que ser significativamente más pequeño de lo que SOA tiende a ser y principalmente es un servicio pequeño (er) desplegable independientemente. Por otro lado, un SOA puede ser un monolito o puede estar compuesto por múltiples microservicios.
También es importante que SOA se haya diseñado e implementado en varios estilos que podrían ser diferentes con lo que se describe aquí, generalmente debido a un enfoque en ESB que se utiliza para integrar aplicaciones monolíticas.