Con los microservicios en pleno apogeo, cada vez más proyectos han comenzado a intentar transformarse en una arquitectura de microservicios.Los microservicios no solo brindan comodidad al desarrollo de proyectos, sino que también aumentan la dificultad de operación y mantenimiento y la probabilidad de que la red no sea confiable.
Cuando se habla de las ventajas y desventajas de los microservicios, la comparación será más obvia. Primero, hablemos de la estructura monolítica.
Arquitectura monolítica
En una arquitectura monolítica, el sistema generalmente adopta un modelo de arquitectura en capas (MVC), una capa de persistencia, una capa de presentación y una capa de lógica empresarial. La arquitectura tiene principalmente los siguientes problemas:
- El sistema interno se accede entre sí y el acoplamiento estrecho hace que sea difícil de mantener;
- Cada área de negocio necesita adoptar la misma pila de tecnología y es difícil aplicar rápidamente nuevas tecnologías (por ejemplo, es difícil transformar a SSM usando SSH);
- Cualquier modificación del sistema debe volver a implementarse / actualizarse junto con todo el sistema;
- Cuando aumenta la carga del sistema, es difícil escalar horizontalmente;
- Cuando ocurre un problema en una parte del sistema, afectará a todo el sistema;
Para superar las deficiencias anteriores, se creó la arquitectura de microservicios. Microservicios, también conocidos como arquitectura de microservicios. Los microservicios son servicios pequeños y autónomos que funcionan en conjunto.
Arquitectura de microservicio
ventaja:
1. Heterogeneidad técnica
En diferentes servicios, se pueden utilizar diferentes tecnologías para desarrollar por separado, siempre que los servicios puedan cooperar entre sí.
2. Flexibilidad
Cuando un determinado servicio en el microservicio no está disponible, no afectará a todo el sistema, sino que solo afectará la indisponibilidad de las funciones relacionadas.
3. Expansión
Fácil de expandir, utilizar pequeños servicios múltiples, más fácil de expandir nuevas funciones
4. Simplifique la implementación
Actualizar la implementación de un servicio sin volver a implementar toda la aplicación
5. Puede combinarse
Al combinar varios servicios, se pueden proporcionar algunas funciones nuevas
6. Alternativa
Debido a que cada microservicio es relativamente pequeño, es factible volver a implementar un determinado servicio o eliminarlo directamente.
Desventajas:
1. Alta complejidad
Los microservicios interactúan a través de REST, RPC y otras formas. En comparación con el modo monolítico, se deben considerar varias situaciones anormales, como fallas de llamadas, sobrecarga y pérdida de mensajes, y la lógica del código es más complicada.
Para las operaciones transaccionales entre microservicios, debido a que diferentes microservicios utilizan diferentes bases de datos, no será posible utilizar el mecanismo de transacción de la propia base de datos para garantizar la coherencia. Es necesario introducir tecnologías como el compromiso de dos fases.
Al mismo tiempo, cuando hay una pequeña cantidad de funciones compartidas entre microservicios pero no se pueden extraer en microservicios, cada microservicio generalmente necesita volver a desarrollar esta parte de la función, o al menos copiar el código para evitar el acoplamiento entre microservicios y aumentar el desarrollo. .costo.
2. Operación y mantenimiento complejos
Al adoptar la arquitectura de microservicios, el sistema se compone de varios microservicios que operan de forma independiente, y se requiere un sistema de monitoreo bien diseñado para monitorear el estado de ejecución de cada microservicio. El personal de operación y mantenimiento necesita tener un conocimiento detallado del sistema para tener un mejor sistema de operación y mantenimiento.
3. Afecta el rendimiento
En comparación con la arquitectura monolítica, los microservicios interactúan a través de REST, RPC y otras formas, y el retraso en la comunicación se verá muy afectado.
Introducción de transacciones distribuidas
Como se dijo arriba
Para las operaciones transaccionales entre microservicios, debido a que diferentes microservicios utilizan diferentes bases de datos, no será posible utilizar el mecanismo de transacción de la propia base de datos para garantizar la coherencia. Es necesario introducir tecnologías como el compromiso de dos fases.
En un solo proyecto, es fácil lograr el control de transacciones, pero difícil de lograr entre múltiples servicios.
Suponga que la llamada de servicio es la siguiente:
Los asuntos de ABCD son controlados por cada servicio ¿Cómo hacerlo, coordinar y asegurar la consistencia de los datos?
Solución de transacciones distribuidas
Compromiso de dos fases basado en el protocolo XA
XA es un protocolo de transacciones distribuidas propuesto por. XA se divide aproximadamente en dos partes: administrador de transacciones y administrador de recursos locales. Entre ellos, los administradores de recursos locales a menudo se implementan mediante bases de datos. Por ejemplo, las bases de datos comerciales como Oracle y DB2 implementan la interfaz XA. Como programador global, el administrador de transacciones es responsable del envío y reversión de varios recursos locales. El principio de XA para implementar transacciones distribuidas es el siguiente:
Fase 1:
Segunda etapa:
En general, el protocolo XA es relativamente simple y una vez que la base de datos comercial implementa el protocolo XA, el costo de usar transacciones distribuidas también es relativamente bajo. Sin embargo, XA también tiene un defecto fatal, es decir, el rendimiento no es ideal, especialmente en el enlace de orden de transacción, a menudo la cantidad de concurrencia es muy alta, XA no puede cumplir con los escenarios de alta concurrencia. XA es actualmente compatible con bases de datos comerciales en lugar de ser compatible idealmente con la base de datos mysql. La implementación XA de mysql no registra registros de fase de preparación. El cambio de regreso a principal y en espera provoca inconsistencias de datos entre la base de datos principal y la base de datos en espera. Muchos nosql no son compatibles con XA, lo que hace que los escenarios de aplicación de XA sean muy limitados.
Transacción de mensaje + consistencia final
La llamada transacción de mensajes se basa en la confirmación en dos fases del middleware de mensajes. Es esencialmente un uso especial del middleware de mensajes. Coloca las transacciones locales y el envío de mensajes en una transacción distribuida para garantizar que la operación local tenga éxito Y el mensaje externo tiene éxito, o ambos fallan, el código abierto RocketMQ admite esta función.
Este esquema adopta la consistencia final, a expensas de la consistencia, a cambio de una mejora sustancial en el desempeño. Existe el riesgo de incoherencia de datos
Modo de programación TCC
El llamado modelo de programación TCC también es una variante de la presentación en dos fases. TCC proporciona un marco de programación que divide toda la lógica empresarial en tres partes: probar, confirmar y cancelar tres operaciones. Tomando el pedido en línea como ejemplo, el inventario se deducirá en la fase Probar, y el estado del pedido se actualizará en la fase Confirmar. Si la actualización del pedido falla, entrará en la fase Cancelar y se restaurará el inventario. En resumen, TCC implementa el envío en dos etapas a través de código de forma artificial, el código escrito en diferentes escenarios de negocios es diferente y la complejidad también es diferente, por lo que este modo no se puede reutilizar bien.
Implementación
LCN
La función principal del marco de transacciones distribuidas de LCN es la coordinación y el control de las transacciones locales. El marco en sí mismo no crea transacciones, sino que solo coordina y controla las transacciones locales. Por lo tanto, el marco tiene una gran compatibilidad con otros marcos de terceros, admite todas las transacciones de bases de datos relacionales, admite múltiples fuentes de datos y admite el uso de marcos de bases de datos de terceros (como sharding-jdbc). Solo necesita agregar distribución cuando utilizando el marco El comentario del tipo transacción es suficiente y la intrusión en el negocio es baja. El marco LCN es principalmente para proporcionar soporte de transacciones distribuidas para el marco de microservicio, y se han realizado más optimizaciones del mecanismo de transacción en el marco de microservicio. En algunos escenarios de carga, el mecanismo de transacción LCN tiene un mejor rendimiento que el mecanismo de transacción local. El marco está abierto después de 4.0 El mecanismo de complemento de Fanglai permite que entren más marcos de terceros.
Actualmente LCN es la versión 4.1
caracteristica principal:
- Admite varios marcos de base de datos basados en primavera
- Compatible con SpringCloud, Dubbo, motan
- Fácil de usar, de baja dependencia y el código es completamente de código abierto.
- Marco de transacciones de fuerte coherencia basado en aspectos
- Alta disponibilidad, los módulos pueden depender de los módulos RPC para la agrupación en clústeres, y TxManager también se puede agrupar
- Apoyar la coexistencia de transacciones locales y transacciones distribuidas
- Admite el mecanismo de compensación de transacciones, aumenta el recordatorio de decisión de compensación de transacciones
El uso de un esquema de consistencia fuerte, la transacción tiene éxito o falla, asegurando la consistencia de la transacción, el código es simple, acaba de introducir el jarpaquete original relacionado con el proyecto y el método de la transacción requiere la participación de agregar anotaciones para guardar El costo de la transformación del código.
Ejemplo de Spring Cloud:
Agregar dependencia
<properties>
<lcn.last.version>4.1.0</lcn.last.version>
</properties>
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>transaction-springcloud</artifactId>
<version>${lcn.last.version}</version>
</dependency>
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>tx-plugins-db</artifactId>
<version>${lcn.last.version}</version>
</dependency>
Agregue un comentario sobre la transacción que debe ejecutarse
@Override
@TxTransaction(isStart = true)
@Transactional
public int save() {
}
Que @TxTransaction(isStart = true)es la anotación de control de transacciones lcn , que isStart = trueindica que el método es el originador de la transacción, por ejemplo, necesita llamar al servicio Un servicio B, el servicio B necesita llamar al servicio C, esta vez para el servicio Una parte iniciadora del servicio, el resto de los participantes, participantes simplemente @TxTransactionEso es todo.