¿Qué es el caso de microservicio?
Definición
En el artículo de Martin Fowler & James Lewis (referencia [1]), se da una definición de arquitectura de microservicio:
La arquitectura de microservicio es la Forma en que se construye una aplicación utilizando un conjunto de pequeños servicios.
Cada servicio se ejecuta en un proceso independiente y los diferentes servicios se comunican a través de algunos mecanismos de interacción ligeros, como RPC, HTTP, etc.
Los servicios se basan en capacidades empresariales y se basan en mecanismos de implementación automática para una implementación independiente.
Esta definición es relativamente vaga, pero aún describe algunos conceptos clave de los microservicios: procesos pequeños e independientes y automatización.
Origen
Por la definición de microservicios, nos resulta familiar. Ya en 1994, Mike Gancarz propuso 9 principios famosos (referencia [4]), de los cuales los primeros 4 están particularmente cerca del concepto de arquitectura de microservicios. Los microservicios son como aplicar la filosofía UNIX a los sistemas distribuidos (ver [3]).
Lo pequeño es hermoso.
Haga que cada programa haga bien una cosa.
Cree un prototipo lo antes posible.
Elija la portabilidad por encima de la eficiencia.
Lo pequeño es hermoso: un servicio pequeño tiene menos código y menos errores, es fácil de probar y mantener, y también es más fácil de iterar y mejorar para volverse más refinado y hermoso.
Un programa sólo necesita hacer una cosa bien: un servicio sólo necesita hacer una cosa bien, y sólo centrándose se puede hacer bien.
Cree prototipos lo antes posible: proporcione API de servicio lo antes posible, establezca contratos de servicio y alcance acuerdos de coherencia para la comunicación entre servicios. La implementación y la mejora se pueden realizar lentamente.
La portabilidad es más importante que la eficiencia: primero se deben considerar protocolos de interacción ligeros entre servicios. Entre eficiencia y portabilidad, se deben considerar la compatibilidad y la portabilidad.
Se puede ver que los microservicios no se crean de la nada, tienen sus propios orígenes históricos. Diez años antes de los microservicios, todo el mundo hablaba a menudo de un modelo arquitectónico llamado SOA (orientado a servicios). En el libro de Sam Newman "Building Microservices" (referencia [2]), el autor define la diferencia entre SOA y Microservicios:
Deberías pensar en los Microservicios como un enfoque específico para SOA de la misma manera que XP. o Scrum son enfoques específicos para el desarrollo de software ágil.
Puedes pensar en los microservicios como una práctica para SOA, del mismo modo que XP o Scrum son enfoques específicos para el desarrollo de software ágil. Estoy de acuerdo con esta definición. El concepto de arquitectura orientada a servicios (SOA) ha existido durante más de diez años. Propuso una idea de diseño arquitectónico, pero no proporcionó una implementación de referencia estándar. La primera industria del software empresarial exploró su propia práctica. enfoque: Enterprise Service Bus (ESB).
Sin embargo, la historia ha demostrado que la implementación de ESB no ha tenido éxito ni siquiera en la industria de software empresarial tradicional. Martin Fowler dijo en el artículo que es precisamente porque ESB arruinó muchos proyectos en ese entonces, invirtió millones de dólares y el resultado fue. casi cero, por lo que al concepto de SOA también se le dio una etiqueta desconocida, por lo que cuando surgió la arquitectura de microservicios, sus defensores comenzaron a negarse a usar la etiqueta SOA, que estaba envuelta en la sombra del fracaso, y la llamaron directamente arquitectura de microservicios ( Estilo de arquitectura de microservicios), lo que hizo que la gente pensara que era una Es una nueva idea arquitectónica, pero de hecho su esencia sigue siendo una forma práctica de SOA.
Características
¿Qué características debe tener un sistema construido según el concepto de arquitectura de microservicios? Martin dio una explicación detallada en su artículo (referencia [1]), la resumiré brevemente aquí.
Servicio de componentes
La forma tradicional de implementar componentes es a través de una biblioteca. La biblioteca se ejecuta en el proceso junto con la aplicación. Los cambios locales en la biblioteca significan la reimplementación de toda la aplicación. . Implementar componentes a través de servicios significa dividir la aplicación en una serie de servicios que se ejecutan en diferentes procesos. Luego, los cambios locales en un solo servicio solo requieren la reimplementación del proceso de servicio correspondiente.
Organizar servicios por capacidades comerciales
Organizar servicios por capacidades comerciales significa que las capacidades proporcionadas por los servicios corresponden a las funciones comerciales, como los servicios de pedidos y los servicios de acceso a datos. El negocio real relacionado con el pedido, este último es un servicio técnico abstracto que no refleja el negocio real. Por lo tanto, al dividir los servicios según el concepto de arquitectura de microservicios, no debería haber un servicio como el servicio de acceso a datos.
Melvin Conway observó un fenómeno en 1967 y resumió una famosa ley de Conway (referencia [5]):
Las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación. de estas organizaciones.
Diseñar organizaciones de sistemas y, en última instancia, producir diseños que sean equivalentes a las estructuras de comunicación de la organización. En el método de desarrollo tradicional, colocamos a los ingenieros en capas de front-end, capas intermedias y capas de datos de acuerdo con sus habilidades y experiencia. Los roles correspondientes al front-end son UI, creador de páginas, etc. La capa intermedia son ingenieros de desarrollo empresarial de back-end y la capa de datos corresponde a roles como DBA.
De hecho, la estructura jerárquica de la arquitectura de diseño de aplicaciones tradicional refleja la estructura de comunicación de diferentes roles. Por lo tanto, si desea crear aplicaciones basadas en microservicios, también debe ajustar la estructura organizativa del equipo en consecuencia. La organización de los pequeños equipos detrás de cada servicio es multifuncional y abarca toda la gama de habilidades necesarias para ejecutar el negocio.
Servicio como Producto
El desarrollo de aplicaciones tradicional se basa en el modelo de proyecto. Después de que el equipo de desarrollo desarrolla una aplicación de software basada en una lista de funciones y la entrega al cliente, el software. la aplicación entra en modo de mantenimiento, otro equipo de mantenimiento es responsable y las responsabilidades del equipo de desarrollo finalizan. La arquitectura de microservicio recomienda evitar este modelo de proyecto y preferir dejar que el equipo de desarrollo sea responsable de todo el ciclo de vida de todo el producto. Amazon presenta un punto de vista al respecto:
Tú lo construyes, tú lo ejecutas.
El equipo de desarrollo asume toda la responsabilidad del funcionamiento del software en el entorno de producción, lo que permite Los desarrolladores del servicio interactúan con el servicio. Los usuarios (clientes) reciben comentarios de comunicación diarios, y los comentarios de los clientes directos ayudan a los desarrolladores a mejorar la calidad de los servicios.