¿Cómo elegir la arquitectura de microservicios para la modernización de aplicaciones empresariales? El enfrentamiento definitivo entre Dubbo, Spring Cloud e Istio

Este artículo lo guiará a través de una comprensión sistemática de los conceptos clave y las pautas de selección para el gobierno y el desarrollo de microservicios a nivel empresarial, con la esperanza de brindarle inspiración para la construcción de su aplicación moderna a nivel empresarial.


Los microservicios son una opción inevitable bajo la tendencia de modernización de aplicaciones

        

Con el desarrollo continuo de la economía digital, las empresas se enfrentan a requisitos de TI más diversos y ágiles en la nueva era.

· Cambios en el comportamiento de los usuarios: el acceso de los usuarios a las aplicaciones comerciales es impredecible, el acceso aumenta repentinamente y hay períodos pico de negocios incontrolables, como eventos calientes temporales o períodos promocionales.

· Cambios en los modelos comerciales: todo el acceso comercial se realiza a través de canales de Internet, incluida la Web, aplicaciones móviles, applets de WeChat, etc.

· Cambios en el desarrollo del sistema empresarial: las aplicaciones ya no se planifican para medio año o un año en el pasado. La demanda cambia en cualquier momento y las iteraciones cada dos semanas se han convertido en la norma. Las aplicaciones comerciales tienen plazos de entrega cortos y requisitos de alta calidad.

· Cambios en el modelo de operación y mantenimiento: Se requiere actualización en línea y respuesta rápida las 24 horas del día, los 7 días de la semana Los diferentes equipos, especialmente los equipos de tercerización, utilizan pilas de tecnología diferentes, que no se pueden administrar y controlar de manera uniforme.

Por lo tanto, evaluar si una empresa necesita adoptar una arquitectura de microservicios a menudo examina estas cinco condiciones clave: volumen de datos y complejidad comercial, tamaño del equipo, respuesta a los cambios en el tráfico comercial, si se requiere suficiente tolerancia a fallas y costos de error y repetición funcional.

Bajo la competencia digital cada vez más feroz, las empresas deben aceptar los cambios del mercado más rápido, responder a las nuevas necesidades de los usuarios en cualquier momento y lanzar productos al mercado más rápido que los competidores.

Los microservicios, como un punto de partida importante para acelerar las empresas para mejorar sus capacidades de innovación ágil, pueden ayudar a las empresas a implementar rápidamente actualizaciones e implementaciones independientes de aplicaciones, y responder rápidamente a los cambios del mercado.Se ha convertido gradualmente en una opción inevitable para las empresas para acelerar la modernización de las aplicaciones.

¿Cómo elegir una arquitectura de microservicios?

· doblaje

Dubbo es una arquitectura de microservicio relativamente temprana, que permite que las aplicaciones realicen las funciones de entrada y salida de los servicios a través de RPC de alto rendimiento y se integra perfectamente con el marco Spring.

La ventaja es que la conexión larga RPC + NIO tiene un mayor rendimiento, pero las limitaciones del protocolo limitarán el desarrollo ecológico y la compatibilidad.

· Nube de primavera

Spring Cloud es un conjunto de marcos para implementar microservicios basados ​​en Spring Boot. Proporciona componentes como administración de configuración, descubrimiento de servicios, disyuntores, enrutamiento inteligente, microagentes y buses de control necesarios para el desarrollo de microservicios. Spring Cloud contiene muchos sub-frameworks. Entre ellos, Spring Cloud Netflix es uno de los frameworks. Fue desarrollado por Netflix y luego se incorporó a la familia Spring Cloud. Los módulos principales que proporciona incluyen: detección de servicios, disyuntor y monitoreo, enrutamiento inteligente, balanceo de carga del cliente, etc.

Spring Cloud tiene una ecología de comunidad Spring más madura y casos de aplicaciones empresariales más maduros, pero también hay ciertas deficiencias, como problemas de plataforma entre idiomas, y la gobernanza de microservicios es más intrusiva para el código.

· A ese

Istio es una solución de implementación relativamente popular en la forma actual de Service Mesh Se puede integrar profundamente con K8 para realizar la gestión de servicios de manera más rápida y conveniente. Istio proporciona una manera fácil de crear una red de servicios que proporciona balanceo de carga, autenticación entre servicios, monitoreo, etc., sin necesidad de cambiar el código del servicio. Al implementar un servicio de proxy sidecar dedicado en todo el entorno para interceptar todas las comunicaciones de red entre microservicios, toda la configuración y administración se realizan a través del panel de control de Istio.

Como una nueva generación de arquitectura de microservicios, su gobierno y desarrollo de microservicios están más completamente desacoplados y se adaptan a una gama más amplia de escenarios. Muchas empresas están pasando gradualmente de Spring Cloud a Service Mesh; pero es precisamente porque la tecnología es relativamente nueva que las empresas desarrollar los suyos propios Se requiere un cierto costo de aprendizaje, romper las barreras de la operación y el mantenimiento/desarrollo tradicionales de TI, y considerar la introducción de proveedores de tecnología profesional puede resolver perfectamente este problema.

La figura anterior muestra el principio básico de funcionamiento de Istio:

1. Cuando el usuario envía una nueva configuración a Kubernetes, el webhook registrado en kubernetes por Galley se activará primero y el webhook verificará si la configuración es legal, como se muestra en el paso 1 de la figura.

2. Si la configuración no pasa la verificación, kubernetes rechazará la configuración enviada por el usuario y mostrará el mensaje de error correspondiente. Paso 2 como se muestra en la figura.

3. Cuando la configuración pasa la verificación, galley obtiene la información de cambio de configuración a través del mecanismo de notificación de kubernetes

4. Galley convierte la información de configuración/servicio modificada al formato MCP y se la envía al piloto a través del protocolo MCP, como se muestra en el paso 4.

5. En el último paso, el piloto envía la configuración modificada al plano de datos a través del protocolo xDS.

Lo anterior es la arquitectura de microservicio común actual, entonces, ¿qué debe hacer la empresa cuando realmente se transforma? te sugerimos:

·  Diferentes tipos de aplicaciones pueden evolucionar a aplicaciones modernas a través de capacidades de microservicio.

Necesidad  de proporcionar una ruta de transformación estable para las aplicaciones tradicionales

Necesidad  de proporcionar una ruta de transformación nativa de la nube para las aplicaciones de Spring Cloud que no requiera una adaptación a gran escala.

¿Cómo diseñar una arquitectura de microservicios?

En primer lugar, desde la definición de microservicios, los microservicios son pequeñas unidades de servicio independientes que cooperan entre sí , que se pueden llamar de forma síncrona y asíncrona, o dividirse de forma independiente, implementarse de forma independiente y actualizarse de forma independiente. Middleware back-end, recursos de almacenamiento, bases de datos, etc. También son independientes, la mejor práctica es que cada microservicio tenga su propia base de datos, lo que realmente realiza el desacoplamiento de las aplicaciones de microservicio.

A continuación, veamos la ley de Conway , que es una teoría básica necesaria de los microservicios y un principio importante que las empresas deben seguir en los microservicios :

La forma organizacional es equivalente al diseño del sistema. Las organizaciones que diseñan sistemas producen diseños que equivalen a estructuras de comunicación dentro y entre organizaciones.

La primera ley: La comunicación dicta el diseño (la comunicación organizacional se expresará a través del diseño del sistema).

La comunicación entre personas es muy complicada y la energía de comunicación de una persona es limitada, por lo que cuando el problema es demasiado complicado y debe ser resuelto por muchas personas, debemos dividir la organización para lograr una gestión eficiente de la comunicación. Tener una comunicación frecuente y detallada dentro del equipo. Para el exterior del equipo, defina interfaces y contratos, y solo lleve a cabo una comunicación de grano grueso. Esto puede reducir los costos de comunicación y también cumplir con el principio de alta cohesión y bajo acoplamiento.

La segunda ley: nunca hay tiempo suficiente para hacer algo bien, pero siempre hay tiempo suficiente para hacerlo de nuevo (no importa cuánto tiempo tengas, una cosa no se puede hacer a la perfección, pero siempre hay tiempo para terminar una cosa) .

Los sistemas complejos deben optimizarse continuamente de manera tolerante a fallas y flexible. No espere un diseño o arquitectura grande y completo. Las buenas arquitecturas y diseños se iteran lentamente. Por lo tanto, las empresas deben aceptar el cambio, resolver la situación actual y completar primero los objetivos pequeños.

La tercera ley: Hay un homomorfismo del gráfico lineal de un sistema al gráfico lineal de su organización de diseño (existe una heterogeneidad potencial y un homomorfismo entre el sistema lineal y la estructura organizativa lineal).

Qué tipo de sistema quieres, qué tipo de equipo construyes y viceversa.

Cuarta ley: Las estructuras de los sistemas grandes tienden a desintegrarse durante el desarrollo, cualitativamente más que los sistemas pequeños (las organizaciones de sistemas grandes siempre están más inclinadas a desintegrarse que los sistemas pequeños).

Una organización grande siempre se dividirá en equipos pequeños (2 equipos de pizza) debido a los costos de comunicación/problemas de gestión.

Específicamente, las empresas pueden seguir los siguientes estándares al transformar la arquitectura de microservicios:

·  Un sistema compuesto por servicios distribuidos.

•  Dividir la organización por negocios en lugar de tecnología.

·  Hacer un producto vivo en lugar de un proyecto.

·  Descentralización.

Operación y mantenimiento automatizado  (DevOps).

·  Tolerancia a fallos.

•  Rápida evolución.

Al mismo tiempo, de acuerdo con la estructura organizativa y las condiciones comerciales propias de la empresa, se llevan a cabo la planificación y el diseño específicos.


Si tiene requisitos para la transformación de microservicios a nivel empresarial, contáctenos para explorar juntos las mejores prácticas de modernización de aplicaciones.

Anterior: Un tutorial práctico para la modernización de aplicaciones empresariales | ¿Cómo transformar aplicaciones en contenedores de forma rápida, precisa e incesante?

Siguiente: Un curso práctico sobre la modernización de aplicaciones empresariales | Una guía de acción de DevOps de lectura obligada para arquitectos de TI

Supongo que te gusta

Origin blog.csdn.net/alauda_andy/article/details/126609741
Recomendado
Clasificación