Directorio
Ventajas y desventajas de los microservicios.
Pila de tecnología de microservicios
Algunos malentendidos comunes sobre el principio de CAP
La relación entre la nube de primavera y la bota de primavera
La diferencia entre Spring Cloud y Dubbo
Microservicios
El núcleo de los microservicios es dividir la aplicación única tradicional en servicios uno por uno de acuerdo con el negocio, y desacoplarlos completamente. Cada microservicio proporciona un servicio con una única función comercial, y un servicio hace una cosa , desde una perspectiva técnica. Es un proceso pequeño e independiente, similar al concepto de un proceso, que se puede iniciar o destruir de forma independiente y tiene su propia base de datos independiente.
Ventajas y desventajas de los microservicios.
Echemos un vistazo a los microservicios que nos pueden brindar. Características de la arquitectura de microservicios:
Para el lanzamiento de un servicio específico, el impacto es pequeño, el riesgo es pequeño y el costo es bajo.
Versiones de lanzamiento frecuente para cumplir rápidamente los requisitos
Expansión de bajo costo, expansión elástica, adaptarse al entorno de la nube
Conocemos un concepto simple. Nada es perfecto. Cualquier cosa tiene dos lados, y debe haber algunas pérdidas. Por lo tanto, al elegir microservicios se resuelven los problemas de respuesta rápida y escalado elástico, nos trae Cual es el problema
La complejidad de los sistemas distribuidos.
El costo de implementación, prueba y monitoreo
Problemas relacionados con transacciones distribuidas y CAP
La aplicación del sistema ha cambiado de una sola unidad a docenas a cientos de proyectos diferentes. Se requieren problemas como dependencias entre servicios, cómo desempaquetar servicios, especificaciones de interfaz interna, transferencia de datos, etc., especialmente la división de servicios. El equipo está familiarizado con el proceso comercial y conoce las compensaciones. Para garantizar que el servicio granular de la división se ajuste al principio básico de "alta cohesión y bajo acoplamiento", también debe tener en cuenta el desarrollo del negocio y la visión de la compañía. E invierta activamente en lograr un equilibrio entre múltiples partes.
Para los sistemas distribuidos, la implementación, las pruebas y la supervisión requieren una gran cantidad de middleware para su soporte, y el middleware en sí también necesita mantenimiento. La simple aplicación original de problemas de transacción única, se vuelve muy complicado pasar a un entorno distribuido . Si la transacción se resuelve utilizando un mecanismo simple de reintento + compensación o un método de consistencia fuerte, como un protocolo de confirmación de dos fases, depende de la familiaridad con el escenario comercial y las compensaciones repetidas. El mismo problema también incluye las compensaciones en el modelo CAP. En resumen, los microservicios tienen requisitos más altos en el nivel técnico general del equipo.
Pila de tecnología de microservicios
| Entrada de microservicio | Tecnología de piso |
| Servicio de desarrollo | Springboot 、 Spring 、 SpringMVC |
| Servicio de configuración y gestión | Archaius de Netflix, Diamante de Ali, etc. |
| Servicio de registro y descubrimiento | Eureka 、 Cónsul 、 Zookeeper 等 |
| Llamada de servicio | Descanso 、 RPC 、 gRPC |
| Fusible de servicio | Hystrix 、 Enviado 等 |
| Balanceo de carga | Cinta 、 Nginx 等 |
| Llamada de interfaz de servicio (herramienta simplificada para que el cliente llame al servicio) | Feign y cols. |
| Cola de mensajes | Kafka 、 RabbitMQ 、 ActiveMQ 等 |
| Gestión del centro de configuración de servicios | SpringCloudConfig 、 Chef 等 |
| Enrutamiento de servicio (puerta de enlace API) | Zuul y col. |
| Servicio de monitoreo | Zabbix 、 Nagios 、 Métrica 、 Espectador 等 |
| Seguimiento completo de enlaces | Zipkin ， Brave 、 Dapper 等 |
| Despliegue de servicio | Docker 、 OpenStack 、 Kubernetes 等 |
| Kit de desarrollo de operación de flujo de datos | SpringCloud Stream (encapsulación y Redis, Rabbit, Kafka, etc., envía y recibe mensajes) |
| Bus de mensaje de evento | Spring Cloud Bus |
Principio CAP
Primero, presente brevemente cuál es el principio de CAP:
C: consistencia
Fuerte consistencia, los datos obtenidos al acceder a todos los nodos deben ser los mismos. Tenga en cuenta que la consistencia aquí se refiere a una consistencia fuerte, es decir, los datos que se ven después de acceder a cualquier nodo son completamente consistentes después de actualizar los datos.
A: disponibilidad
Disponibilidad, todos los nodos mantienen alta disponibilidad. Tenga en cuenta que la alta disponibilidad aquí también incluye que no pueden ocurrir retrasos. Por ejemplo, si el Nodo B bloquea las solicitudes debido a la espera de la sincronización de datos, entonces el Nodo B no cumple con la alta disponibilidad.
En otras palabras, cualquier servicio que no haya fallado debe devolver un conjunto de resultados razonable dentro de un tiempo limitado.
P: tolerancia de partición
Tolerancia de partición, aquí se refiere a la partición en el sentido de la red. Debido a que la red no es confiable, es probable que no haya comunicación entre todos los nodos. Cuando los nodos no pueden comunicarse, es necesario asegurarse de que el sistema pueda continuar con el servicio normal.
En términos de efecto real, la partición es equivalente al límite de tiempo de comunicación. Si el sistema no puede lograr la coherencia de los datos dentro del límite de tiempo, significa que se ha producido una partición y debe elegir entre C y A para la operación actual.
El principio CAP dice que un sistema distribuido de datos no puede satisfacer las tres condiciones de C y A y P al mismo tiempo. Por lo tanto, al diseñar un sistema, el arquitecto del sistema no debe desperdiciar energía en cómo diseñar un sistema distribuido perfecto que satisfaga los tres, sino que debe elegir. Debido a la naturaleza poco confiable de la red, la mayoría de los sistemas distribuidos de código abierto implementarán P, es decir, tolerancia de partición, y luego elegirán entre C y A.
Algunos malentendidos comunes sobre el principio de CAP
Vi muchos artículos en Internet que decían que el principio CAP es la piedra angular de un sistema distribuido , pero el principio CAP es en realidad una conclusión de un sistema de almacenamiento de datos distribuido . Suponemos que cada nodo de un sistema distribuido lee y escribe la misma instancia de mysql, por lo que para este sistema distribuido no tiene sentido discutir el principio CAP. Debido a que cada nodo puede comunicarse sin replicación de datos, cumple con la tolerancia de partición (P), puede responder a las solicitudes en cualquier momento y cumple con la disponibilidad (A). Al mismo tiempo, debido a que está accediendo a una instancia de base de datos, ya ha garantizado la consistencia de los datos ( C)
Por lo tanto, cuando se discute el principio de CAP, está más dirigido a aquellos sistemas de almacenamiento distribuido con almacenamiento de datos y escenarios de replicación de datos, es decir, la conocida base de datos NoSql.
Como la mayoría de nosotros no diseñará una nueva base de datos NoSql para usar, más es usar el sistema de código abierto NoSql existente para el almacenamiento de datos, como Hbase, MongoDB, Cassandra, etc. Entonces, la mayoría de las veces, en realidad no utilizamos el principio CAP.
Con respecto al principio de CAP, una cosa que necesita atención especial es que, aunque diseñamos el sistema, no podemos garantizar tener tres puntos al mismo tiempo. Pero eso no significa que después de garantizar dos de ellos, el otro punto será completamente abandonado. Es solo un relativo sacrificio . Por ejemplo, en el caso de garantizar CP, aunque no hay forma de garantizar una alta disponibilidad, esto no significa que la disponibilidad sea 0. Podemos mejorar la disponibilidad tanto como sea posible a través de un diseño razonable y hacer que la disponibilidad sea lo más cercana posible al 100%. Del mismo modo, en el caso de AP, también puede intentar garantizar la coherencia de los datos o lograr una coherencia débil, es decir, una coherencia final.
Nube de primavera
SpringCloud = una solución integral bajo la arquitectura de microservicios distribuidos, es una colección de tecnologías de aterrizaje de varias arquitecturas de microservicios, comúnmente conocidas como microservicios
SpringCloud, basado en SpringBoot, proporciona un conjunto de soluciones de microservicios, que incluyen registro y descubrimiento de servicios, centro de configuración, monitoreo de enlace completo, puerta de enlace de servicio, equilibrio de carga, fusibles y otros componentes, además de un empaque muy abstracto basado en componentes de código abierto NetFlix También hay algunos componentes de código abierto que son neutrales en la selección.
SpringCloud utiliza la conveniencia de desarrollo de SpringBoot para simplificar sutilmente el desarrollo de la infraestructura de sistemas distribuidos SpringCloud proporciona a los desarrolladores algunas herramientas para construir rápidamente sistemas distribuidos, incluyendo administración de configuración, descubrimiento de servicios, interruptores de circuito, enrutamiento, microagentes y eventos Los autobuses, bloqueos globales, campañas de decisión, sesiones distribuidas, etc., se pueden iniciar y desplegar con un solo clic utilizando el estilo de desarrollo SpringBoot.
SpringBoot no repite la fabricación de ruedas. Simplemente combina los marcos de servicio más maduros y prácticos desarrollados por varias compañías. La reencapsulación a través del estilo SpringBoot protege los complejos principios de configuración e implementación, y finalmente brinda a los desarrolladores Se deja de lado un conjunto de kits de herramientas de desarrollo de sistemas distribuidos que son fáciles de entender, fáciles de implementar y fáciles de mantener.
La relación entre la nube de primavera y la bota de primavera
SpringBoot se centra en el desarrollo de microservicios individuales individuales de forma rápida y sencilla.
SpringCloud es un marco global de coordinación y gobernanza de microservicios que integra y administra microservicios
individuales desarrollados por SpringBoot para proporcionar varios microservicios , gestión de configuración, descubrimiento de servicios, disyuntores, enrutamiento, micro proxy, Servicios integrados como bus de eventos, bloqueo global, campaña de decisión, sesión distribuida, etc.
SpringBoot puede dejar SpringCloud para usar proyectos de desarrollo de forma independiente, pero SpringCloud es inseparable de SpringBoot, que pertenece a la relación de dependencia.
SpringBoot se enfoca en el desarrollo rápido y conveniente de un solo microservicio individual, y SpringCloud se enfoca en el marco de gobierno de servicio global.
La diferencia entre Spring Cloud y Dubbo
La mayor diferencia: Spring Cloud abandonó la comunicación RPC de Dubbo y usó REST basado en HTTP.
Estrictamente hablando, estos dos métodos tienen sus propias ventajas y desventajas. Aunque este último sacrifica el rendimiento de las llamadas de servicio en cierta medida, también evita los problemas causados por el RPC nativo mencionado anteriormente. Y REST es más flexible que RPC. El proveedor de servicios y la persona que llama dependen de un solo contrato, y no hay una dependencia fuerte a nivel de código. Esto es más apropiado en un entorno de microservicio que enfatiza la rápida evolución.
Dubbo y Spring Cloud no son completamente competitivos, y los dominios de problemas que resuelven son diferentes: el posicionamiento de Dubbo es siempre un marco RPC, y el propósito de Spring Cloud es una solución integral bajo la arquitectura de microservicios.
A modo de comparación, Dubbo se puede comparar con la pila de tecnología de Netflix OSS, y Spring Cloud integra Netflix OSS como una solución de gestión de servicios distribuidos, pero además Spring Cloud también proporciona distribuidos, incluyendo configuración, transmisión, seguridad, detective, etc. Servicio de soluciones.
En la actualidad, debido a problemas como el protocolo RPC y la falta de coincidencia de metadatos del registro, Dubbo y Spring Cloud solo pueden elegir uno de dos cuando se enfrentan a la selección del marco básico de microservicios, por lo que siempre se comparan.
Después de que Dubbo buscará adaptarse activamente al ecosistema de Spring Cloud, como el uso de la solución de comunicación binaria de SpringCloud para aprovechar las ventajas de rendimiento de Dubbo, o Dubbo se adapta a Spring Cloud a través de la modularización y el soporte http
La diferencia entre máquina de marca y máquina de ensamblaje
Obviamente, la función de Spring Cloud es más poderosa que DUBBO y cubre un rango más amplio, y como primer proyecto de Spring, también se puede integrar perfectamente con otros proyectos de Spring como Spring Framework, Spring Boot, Spring Data, Spring Batch, etc. Estos son para microservicios Es crucial. La arquitectura de microservicios construida con Dubbo es como ensamblar una computadora. Tenemos un alto grado de libertad en la elección de cada enlace, pero es probable que el resultado final no sea brillante debido a la calidad de una memoria. Siempre es incómodo, pero si Siendo un maestro, estos no son problemas, y Spring Cloud es como una máquina de marca. Bajo la integración de Spring Source, se han realizado muchas pruebas de compatibilidad para garantizar que la máquina tenga una mayor estabilidad, pero si desea utilizar Para cosas fuera de los componentes originales, debe tener una comprensión suficiente de sus conceptos básicos.
Apoyo comunitario y esfuerzos de actualización
Lo más importante, DUBBO ha dejado de actualizarse durante aproximadamente 5 años, aunque se reinició en 2017.7. Los propios desarrolladores deben ampliar y actualizar los nuevos requisitos para el desarrollo tecnológico (por ejemplo, DubboX ha fabricado DubboX). Esto obviamente no es adecuado para muchas organizaciones de software pequeñas y medianas que desean adoptar una arquitectura de microservicio. Las pequeñas y medianas empresas no son tan poderosas La capacidad técnica para modificar el código fuente de Dubbo + un conjunto completo de soluciones, no todas las empresas han probado Ali Daniel + entorno de producción real en línea.
