Como programador de Java, todavía necesito tener claro la evolución de la arquitectura del sistema.Primero, describiré brevemente la evolución de la arquitectura.
1. Arquitectura monolítica (arquitectura centralizada)
La estructura única es relativamente elemental, una estructura típica de tres niveles, front-end (web/terminal móvil) + capa de lógica comercial intermedia + capa de base de datos. Esta es una aplicación de marco Java Spring MVC típica
La arquitectura monolítica consiste en reunir todas las funciones y módulos en un proyecto y desplegarlos en un servidor para proporcionar servicios externos (arquitectura centralizada, servicio monolítico, aplicación monolítica)
Las aplicaciones monolíticas son más fáciles de implementar y probar. En las primeras etapas de un proyecto, las aplicaciones monolíticas pueden funcionar bien. Sin embargo, a medida que la demanda siguió aumentando y más y más personas se unieron al equipo de desarrollo, la base de código también se expandió rápidamente. Lentamente, la aplicación monolítica se vuelve cada vez más inflada, la capacidad de mantenimiento y la flexibilidad disminuyen gradualmente y el costo de mantenimiento se vuelve cada vez más alto.
2. Arquitectura distribuida
En el libro "Principios y paradigmas de los sistemas distribuidos", existe la siguiente definición: un sistema distribuido es una colección de varias computadoras independientes , y estas computadoras son como un solo sistema relacionado para los usuarios. Un sistema de nodos de computadora que trabajan juntos para realizar una tarea común.
En pocas palabras, es dividir todas las funciones y módulos en diferentes subproyectos e implementarlos en varios servidores diferentes. Estos subproyectos cooperan entre sí para proporcionar servicios externos.
En comparación con la arquitectura única, esta arquitectura proporciona capacidades de equilibrio de carga, mejora en gran medida la capacidad de carga del sistema y resuelve los requisitos de alta concurrencia del sitio web. Por ejemplo, un proyecto de comercio electrónico se puede dividir en subproyectos/módulos, como usuario usuario, orden de pedido, tienda de carrito de compras, etc.
La imagen es de Baidu.
Ventajas de esta arquitectura:
(1) Reduzca el grado de acoplamiento: divida el módulo, use la interfaz para comunicarse y reduzca el grado de acoplamiento entre los módulos
(2) Responsabilidades claras: dividir el proyecto en varios subproyectos/módulos, y diferentes equipos son responsables de diferentes subproyectos/módulos
(3) Fácil de expandir: al agregar funciones, solo necesita agregar otro subproyecto/módulo y llamar a la interfaz de otros sistemas.
(4) Fácil implementación: implementación distribuida flexible
(5) Mejorar la reutilización del código: por ejemplo, si la capa de servicio no adopta la arquitectura de servicio distribuido, es necesario escribir una capa de servicio en los extremos de PC, Android e iOS. La gran cantidad de desarrollo es difícil. para mantener y actualizar Los servicios distribuidos se utilizan y comparten una capa de servicio
Desventajas: la interacción entre sistemas requiere comunicación remota y el desarrollo de la interfaz aumenta la carga de trabajo (pero las ventajas generales superan las desventajas)
3. Arquitectura de microservicios
Lo siguiente se enfoca en peinar
4. Arquitectura nativa de la nube
Las aplicaciones nativas de la nube generalmente se refieren a aplicaciones que admiten de forma nativa la implementación en la nube y pueden aprovechar al máximo las capacidades de la plataforma en la nube. Generalmente tiene tres características:
Embalaje en contenedores. La encapsulación en contenedores se refiere a la aplicación basada en contenedores, que se encapsula en el contenedor y se ejecuta en el contenedor, para realizar el aislamiento relativo de los recursos y la reutilización de las imágenes del contenedor.
Orientado a microservicios. Orientado a microservicios se refiere a dividir una gran aplicación funcional en microaplicaciones con una sola función, relativamente independientes y desacopladas entre sí, y las microaplicaciones se comunican a través de interfaces.
Gestión dinámica. La gestión dinámica se refiere a la gestión y programación dinámicas de estos microservicios a través de una herramienta de orquestación unificada, como K8S.
Posteriormente, con el desarrollo de la computación en la nube, la CNCF Cloud Native Computing Foundation agregó dos elementos más: la API declarativa y la cuadrícula de servicios .
Si una aplicación cumple con las características anteriores, puede denominarse aplicación nativa de la nube. Debido a las ventajas inherentes de las aplicaciones nativas de la nube, cada vez más empresas están adoptando aplicaciones nativas de la nube, lo que requiere que las empresas tengan una nueva arquitectura técnica para hacer un mejor uso de las tecnologías nativas de la nube. Y este tipo de arquitectura técnica que utiliza tecnología nativa de la nube para hacer que las empresas sean más ágiles, rentables y más poderosas puede convertirse en una arquitectura nativa de la nube. Utiliza tecnología de contenedores, se basa en microservicios y utiliza métodos ágiles para lograr la entrega continua de aplicaciones a través del viaje de DevOps.
Arquitectura nativa de la nube = Microservicios + Contenedorización + DevOps + Entrega continua .
1. Arquitectura de microservicios
Arquitectura de microservicios
Los microservicios (Microservices) es un estilo arquitectónico para crear una sola aplicación a través de la composición de múltiples servicios pequeños, que se crean en torno a las capacidades comerciales en lugar de estándares técnicos específicos. Cada servicio puede usar diferentes lenguajes de programación, diferentes tecnologías de almacenamiento de datos y ejecutarse en diferentes procesos. El servicio adopta un mecanismo de comunicación ligero y un mecanismo de implementación automatizado para lograr la comunicación, operación y mantenimiento.
El origen de los microservicios
El término técnico "microservicio" se propuso por primera vez en 2005. Fue utilizado por primera vez por el Dr. Peter Rodgers en la Cloud Computing Expo 2005 (Web Services Edge 2005), cuando se denominó "Micro-Web-Service", se refiere a un solo -Servicio web detallado, independiente del lenguaje y centrado en la responsabilidad (Servicios web granulares).
microservicios
El verdadero auge de los microservicios fue en 2014, y también fue la primera vez que aprendí sobre los microservicios del artículo " Microservicios: una definición de este nuevo término arquitectónico " coescrito por Martin Fowler (Martin Fowler) y James Lewis (James Lewis ). . El "microservicio" que todos conocen es el "microservicio" definido en este artículo
Enlace original a Microservicios
Traducir el enlace original al blog de microservicios｜YYGCui
En este artículo, primero se da el concepto de microservicios modernos:
Los microservicios son un estilo arquitectónico que crea una aplicación única a través de la composición de múltiples servicios pequeños. Estos servicios se construyen en torno a las capacidades comerciales en lugar de estándares técnicos específicos. Cada servicio puede usar diferentes lenguajes de programación, diferentes tecnologías de almacenamiento de datos, ejecutarse en diferentes procesos. El servicio adopta un mecanismo de comunicación liviano y un mecanismo de implementación automatizado para lograr la comunicación, operación y mantenimiento ".
Además, el artículo enumera nueve características comerciales y técnicas centrales de los microservicios, que se enumerarán e interpretarán a continuación.
- Organizado en torno a la capacidad empresarial . Aquí se vuelve a enfatizar la importancia de la Ley de Conway: un equipo con cualquier estructura, escala y capacidades producirá productos con las estructuras, escalas y capacidades correspondientes. Esta conclusión no es una coincidencia encontrada por un determinado equipo o una determinada empresa, sino un resultado inevitable de la evolución. Si las funciones que deberían pertenecer al mismo producto se dividen en diferentes equipos, inevitablemente se producirá una gran cantidad de comunicación y colaboración entre equipos. Cruzar los límites del equipo tendrá costos más altos en términos de gestión, comunicación y organización del trabajo. Equipos eficientes Naturalmente, se realizarán mejoras para IT Cuando el equipo y el producto se ajusten y estabilicen, el equipo y el producto tendrán una estructura consistente.
- Gobernanza descentralizada . Esto es para expresar el significado de "cuyo hijo está a cargo". El equipo de desarrollo correspondiente al servicio es directamente responsable de la calidad de la operación del servicio, y también debe tener el derecho de controlar todos los aspectos del servicio sin interferencia externa, como como elegir y otros servicios Tecnologías heterogéneas para implementar sus propios servicios. Este punto tiene cierto margen de maniobra en la práctica real. La mayoría de las empresas no usarán Java para un servicio, Python para otro y Golang para el siguiente. En cambio, generalmente tienen un lenguaje principal unificado, o incluso una pila de tecnología unificada o una plataforma de tecnología patentada. Los microservicios no defienden ni se oponen a este tipo de "unificación". Siempre que el equipo responsable de proporcionar y mantener la pila de tecnología básica tenga la conciencia de que todas las partes confían en él, y debe estar mentalmente preparado para "ser despertado a menudo por el despertador a las 3 de la mañana", bien. Microservicios enfatiza que cuando la heterogeneidad técnica es realmente necesaria, deberían tener el derecho de elegir "no uniformidad". Por ejemplo, Node.js no debería verse obligado a desarrollar páginas de informes. Al hacer modelos de entrenamiento de inteligencia artificial, debería poder elija Python, etc.
- Componentización vía Servicios para realizar componentes independientes y autónomos (Componentización vía Servicios). La razón por la que enfatizamos la creación de componentes a través de "Servicio" en lugar de "Biblioteca" es porque la biblioteca de clases está vinculada estáticamente al programa en tiempo de compilación y proporciona funciones a través de llamadas locales, mientras que el servicio es un componente fuera de proceso. se proporciona a través de llamadas remotas. En el artículo anterior, hemos analizado que si bien los servicios remotos tienen costos de invocación más altos, este es un precio necesario para brindar aislamiento y autonomía a los componentes.
- Pensamiento de producto (Productos no Proyectos). Evite ver el desarrollo de software como una función a completar, sino como un proceso de mejora y mejora continua. Por ejemplo, la operación y el mantenimiento no deben considerarse únicamente como el trabajo del equipo de operación y mantenimiento, sino que el desarrollo debe considerarse únicamente como el trabajo del equipo de desarrollo, que debe ser responsable de todo el ciclo de vida del producto de software. Los desarrolladores no solo deben saber cómo se desarrolla el software, sino también saber cómo se desarrolla, cómo funciona, cómo retroalimentan los usuarios e incluso cómo se lleva a cabo el trabajo de soporte postventa. Tenga en cuenta que el usuario del servicio aquí no es necesariamente el usuario final, sino que también puede ser otro servicio que consume este servicio. En el pasado, bajo la estructura monolítica, la escala del programa determinaba que todo el personal no podía prestar atención al producto completo. En la organización, habría miembros con una división detallada del trabajo, como desarrollo, operación y mantenimiento, y soporte. Cada persona solo se centró en su propio trabajo, pero con los microservicios, es factible que todos en el equipo de desarrollo piensen en el producto y se preocupen por todos los aspectos del producto completo.
- Descentralización de datos (Gestión de datos descentralizados). Los microservicios abogan claramente por que los datos se gestionen, actualicen, mantengan y almacenen de forma descentralizada. En un único servicio, cada módulo funcional de un sistema suele utilizar la misma base de datos. Es cierto que el almacenamiento centralizado es inherentemente más sencillo para evitar problemas de coherencia. Sin embargo, la forma abstracta de la misma entidad de datos suele ser diferente desde la perspectiva de los diferentes servicios. Por ejemplo, el libro en la aplicación Librería se enfoca en el precio en el campo de ventas, la cantidad de inventario en el campo de almacenamiento y la información de introducción de los libros en el campo de visualización del producto. Si se usa como almacenamiento centralizado, todos los campos deben Modificar y mapear a la misma entidad hace posible que diferentes servicios se afecten entre sí y pierdan su independencia. Aunque es bastante difícil lidiar con el problema de la coherencia en un entorno distribuido, a menudo es imposible utilizar el procesamiento de transacciones tradicional para garantizarlo, pero el menor de los dos males es que aún vale la pena pagar algunos costos necesarios.
- Tubería débil de terminal fuerte (Smart Endpoint y Dumb Pipe). La canalización débil (Dumb Pipe) es casi un conjunto de mecanismos de comunicación complejos que se oponen directamente a SOAP y ESB. ESB puede gestionar el procesamiento de codificación de mensajes, la conversión de reglas de negocio, etc., BPM puede orquestar de forma centralizada los servicios empresariales de la empresa, SOAP tiene docenas de familias de protocolos WS-* para gestionar una serie de tareas como transacciones, coherencia, autenticación y autorización, etc. se construyen sobre la tubería de comunicación. La función anterior puede ser necesaria para cierta parte del servicio en un sistema determinado, pero es una carga impuesta para más otros servicios. Si el servicio necesita las capacidades de comunicación adicionales anteriores, debe resolverse en el propio Endpoint del servicio, en lugar de un paquete en la canalización de comunicación. Los microservicios abogan por un método de comunicación simple y directo similar a los filtros clásicos de UNIX, y la comunicación de estilo RESTful será una opción más adecuada en los microservicios.
- Diseño tolerante a fallas (Design for Failure). Ya no es la búsqueda ilusoria de la estabilidad eterna de los servicios, sino la aceptación de la realidad de que los servicios siempre fallarán. En el diseño de microservicios, existe un mecanismo automático que puede detectar rápidamente las fallas de los servicios de los que dependen y aislarlas cuando siguen fallando Vuelva a conectar cuando se restablezca el servicio. Por lo tanto, las instalaciones como los "disyuntores" no son componentes periféricos opcionales para los microservicios en el entorno de producción real, sino un punto de apoyo necesario. Si no hay un diseño tolerante a fallas, el sistema se dañará fácilmente debido a uno o dos. La avalancha efecto provocado por el colapso de un servicio es abrumado. Es totalmente posible que un sistema confiable esté compuesto por servicios que pueden fallar, es ahí donde radica el mayor valor de los microservicios, y este es el significado del título de este documento de código abierto "The Fenix Project".
- Diseño Evolutivo . El diseño tolerante a fallas reconoce que los servicios fallarán y el diseño evolutivo reconoce que los servicios quedarán obsoletos. Un servicio bien diseñado debe poder desecharse, no se espera que viva para siempre. Si existen servicios inmutables e irreemplazables en el sistema, esto no significa cuán excelente e importante es el servicio, sino más bien una muestra de la fragilidad del diseño del sistema.La independencia y autonomía que persiguen los microservicios también está en contra de la manifestación de esta vulnerabilidad.
- Automatización de Infraestructura . La automatización de la infraestructura, como el rápido desarrollo de CI/CD, ha reducido significativamente la complejidad del trabajo de construcción, lanzamiento, operación y mantenimiento. Debido a que los objetos de operación y mantenimiento bajo microservicios tienen un aumento de orden de magnitud en comparación con la arquitectura única, los equipos que usan microservicios dependen más de la automatización de la infraestructura y es difícil para los humanos brindar soporte a cientos, miles o incluso decenas de miles. de servicios. .
Los microservicios son servicios muy pequeños, tan pequeños que un servicio solo corresponde a una sola función y hace una sola cosa. Este servicio se puede implementar y ejecutar de forma independiente, y los servicios pueden interactuar entre sí a través de rpc Cada microservicio es desarrollado, probado, implementado y lanzado por un pequeño equipo independiente, responsable de todo su ciclo de vida.
Los servicios distribuidos se distribuyen y despliegan en diferentes máquinas.Un servicio puede ser responsable de varias funciones.Es una arquitectura orientada a SOA.Los servicios también interactúan a través de rpc o webservice.
Cada módulo de un sistema distribuido interactúa con los datos a través de interfaces, de hecho, distribuido también es una especie de microservicio, porque divide los módulos en unidades independientes y proporciona interfaces para llamar
Por lo tanto, encontraremos que hay muchas similitudes entre los servicios distribuidos y los microservicios, pero no son idénticos. Todavía hay algunas diferencias entre ellos.
1. En comparación con los servicios distribuidos, los microservicios tienen una granularidad más pequeña y un menor acoplamiento entre servicios. Dado que cada microservicio está a cargo de un pequeño equipo independiente, tiene una mayor agilidad. Los servicios distribuidos finalmente evolucionarán a una arquitectura de microservicio
2. La diferencia esencial entre microservicios y distribuidos
La diferencia esencial entre microservicios y estructuras distribuidas se refleja en el "objetivo"
La diferencia sutil entre los microservicios y los distribuidos es que la aplicación de los microservicios no está necesariamente dispersa en varios servidores, sino que también puede ser el mismo servidor.
Distributed pertenece a los microservicios y el módulo se divide en una unidad de servicio independiente para realizar la interacción de datos a través de la interfaz.
La arquitectura de los microservicios distribuidos es muy similar, pero la forma de implementación es diferente.
La arquitectura distribuida es para resolver: una máquina no puede permitirse una gran cantidad de visitas de usuarios, o debido a problemas de costos, se deben usar varias máquinas para completar la implementación de servicios
El diseño de la estructura del microservicio no debe afectar el negocio del sistema existente debido a la actualización y el BUG de un determinado módulo, solo separa cada módulo y no se verá afectado entre sí, como actualizaciones de módulos o BUG o refactorización, etc. afectar a otros módulos, los microservicios se pueden implementar en una máquina
Los microservicios se centran en el desacoplamiento para que cada módulo sea independiente. Distribuido se enfoca en compartir recursos y acelerar la computación de la computadora
Distribuido también es un tipo de microservicio, y el microservicio también se distribuye
Ejemplo, SpringCloud
El microservicio es un método de arquitectura de proyectos y un concepto de arquitectura; luego, Spring Cloud es la realización técnica de este método de arquitectura.
Sitio web oficial de SpringCLoud: Spring Cloud
Lo siguiente se cita del sitio web oficial.
Spring Cloud proporciona herramientas para que los desarrolladores construyan rápidamente algunos de los patrones comunes en los sistemas distribuidos (por ejemplo, gestión de configuración, descubrimiento de servicios, disyuntores, enrutamiento inteligente, micro-proxy, bus de control, tokens únicos, bloqueos globales, elección de liderazgo, distribución sesiones, estado del clúster). La coordinación de los sistemas distribuidos conduce a patrones estándar y, al usar Spring Cloud, los desarrolladores pueden implementar rápidamente servicios y aplicaciones que implementan esos patrones. Funcionarán bien en cualquier entorno distribuido, incluida la propia computadora portátil del desarrollador, centros de datos completos y plataformas administradas como Cloud Foundry.
Características
Spring Cloud se enfoca en proporcionar una buena experiencia lista para usar para casos de uso típicos y un mecanismo de extensibilidad para cubrir otros.
Configuración distribuida/versionada
Registro y descubrimiento de servicios
Enrutamiento
Llamadas de servicio a servicio
Balanceo de carga
Rompedores de circuito
Bloqueos globales
Elección de liderazgo y estado de grupo
mensajería distribuida
La traducción es la siguiente:
Spring Cloud proporciona a los desarrolladores herramientas para construir rápidamente algunos patrones comunes en sistemas distribuidos y resolver algunos problemas comunes (como gestión de configuración, descubrimiento de servicios, disyuntores, enrutamiento inteligente, microagentes, buses de control, tokens únicos, bloqueos globales, elecciones de líder, sesiones distribuidas, estado de clúster). La coordinación de los sistemas distribuidos genera una gran cantidad de código repetitivo (mucho código con rutinas fijas) y, al usar Spring Cloud, los desarrolladores pueden crear rápidamente servicios y aplicaciones que implementen estos patrones. Funcionan bien en cualquier entorno distribuido, incluidas las computadoras portátiles de los desarrolladores, los centros de datos completos y las plataformas de alojamiento, como la computación en la nube;
Características de la nube de primavera
Spring Cloud proporciona buenas funciones listas para usar para escenarios típicos de aplicaciones de desarrollo de sistemas distribuidos, tales como:
Configuración distribuida/versionada
Registro y descubrimiento de servicios
enrutamiento
Llamadas entre servicios
balanceo de carga
interruptor automático
bloqueo global
Elección de líder y estado de grupo
mensajería distribuida
Proyecto principal de SpringCloud
Configuración de la nube de primavera
Nube de primavera Netflix
Autobús de la nube de primavera
Nube de primavera Cloudfoundry
Agente de servicio abierto de Spring Cloud
Cúmulo de nubes de primavera
Cónsul Nube Primaveral
Seguridad en la nube de primavera
Detective de nubes de primavera
Flujo de datos de la nube de primavera
Arroyo de nubes de primavera
Iniciadores de la aplicación Spring Cloud Stream
Tarea de nube de primavera
Iniciadores de la aplicación Spring Cloud Task
Guardián del zoológico Nube primaveral
Nube de primavera AWS
Conectores de nube de primavera
Arrancadores de nubes de primavera
CLI de Spring Cloud
Contrato de nube de primavera
Puerta de enlace de la nube de primavera
Nube de primavera OpenFinge
Canalizaciones de Spring Cloud
Función de nube de primavera
Spring Cloud es una solución integral basada en la arquitectura de microservicios distribuidos desarrollada en SpringBoot, que incluye registro y descubrimiento de servicios, centro de configuración, puerta de enlace de servicios, balanceo de carga, fusión, monitoreo completo de enlaces,
etc. El "cubo familiar" del sistema de servicio no es una determinada tecnología, sino una colección ordenada de una serie de soluciones o marcos de microservicios. Integra marcos de microservicios maduros y probados en el mercado, y los vuelve a empaquetar a través de la idea de Spring Boot, protegiendo y ajustando la configuración compleja y los principios de implementación, y finalmente proporciona a los desarrolladores un conjunto de herramientas simples, fáciles de entender y fáciles. -to-deploy Y un kit de desarrollo de sistemas distribuidos fácil de mantener.
La versión lanzada por Spring Cloud es un nombre alfabético de la estación de metro de Londres ("Angel" es la primera versión, "Brixton" es la segunda), el orden alfabético es de AZ, la última versión estable 2021.0 .x aka Jubilee , cuando algunos subproyectos en Spring Cloud tienen errores críticos o actualizaciones importantes, la secuencia de lanzamiento lanzará una versión cuyo nombre termina con ".SRX", donde "X" es un número, como: Greenwich SR1, Greenwich SR2, Greenwich SR3
1. Componentes comunes de Spring Cloud
Spring Cloud en sí no es un marco listo para usar, es un conjunto de especificaciones de microservicio con dos generaciones de implementación.
(1) Spring Cloud Netflix es la implementación de primera generación de Spring Cloud, compuesta principalmente por Eureka, Ribbon, Feign, Hystrix y otros componentes.
(2) Spring Cloud Alibaba es la implementación de segunda generación de Spring Cloud, compuesta principalmente por Nacos, Sentinel, Seata y otros componentes.
Spring Cloud (específicamente Spring Cloud Netflix) contiene casi 20 subproyectos, como spring-cloud-config y spring-cloud-bus, que brindan gobernanza de servicios, puerta de enlace de servicios, enrutamiento inteligente, equilibrio de carga, disyuntor, seguimiento de monitoreo, soluciones de distribución en los campos de colas de mensajes y gestión de configuración.
Netflix es un sitio web de videos en línea en los EE. UU. Es reconocido como un destacado practicante de microservicios a nivel de producción a gran escala y líder en la industria de microservicios. Los componentes de código abierto de Netflix se han probado en producción durante muchos años en su entorno de microservicios distribuidos a gran escala, y son maduros y confiables.
Spring Cloud integra los componentes de servicio de código abierto en Netflix (como Eureka, Ribbon, Feign y Hystrix, etc.) en el módulo Spring Cloud Netflix. Los componentes integrados se denominan Spring Cloud Netflix XX, por lo que la implementación de SpringCloud de primera generación también es llamado Nube de primavera Netflix
Se harán distinciones posteriores entre Spring Cloud Netflix y Spring Cloud Alibaba
Los componentes comunes de Spring Cloud (especialmente Spring Cloud Netflix ) se muestran en la siguiente tabla
| Componentes de Spring Cloud | describir |
|---|---|
| Nube de primavera Netflix Eureka | El componente de gobernanza de servicios en Spring Cloud Netflix incluye la implementación del registro de servicios, el registro de servicios y el mecanismo de descubrimiento. |
| Cinta de Netflix Nube primaveral | Componentes de invocación de servicios y equilibrio de carga de clientes en Spring Cloud Netflix. |
| Nube de primavera Netflix Hystrix | Conocido como "Brother Porcupine", el componente de administración tolerante a fallas de Spring Cloud Netflix brinda una fuerte tolerancia a fallas para demoras y fallas en el servicio. |
| Spring Cloud Netflix Fingir | Un componente de llamada de servicio declarativo basado en Ribbon e Hystrix. |
| Nube de primavera Netflix Zuul | El componente de puerta de enlace en Spring Cloud Netflix proporciona funciones como enrutamiento inteligente y filtrado de acceso. |
| Puerta de enlace de la nube de primavera | Un marco de puerta de enlace desarrollado en base a tecnologías como Spring 5.0, Spring Boot 2.0 y Project Reactor. Utiliza la cadena de filtro para proporcionar las funciones básicas de la puerta de enlace, como seguridad, monitoreo/indicadores y limitación de corriente. |
| Configuración de la nube de primavera | La herramienta de administración de configuración de Spring Cloud admite el uso de Git para almacenar contenido de configuración, realiza el almacenamiento externo de la configuración de la aplicación y admite operaciones como actualizar, cifrar y descifrar la configuración en el lado del cliente. |
| Autobús de la nube de primavera | El bus de eventos y mensajes de Spring Cloud se utiliza principalmente para propagar eventos o cambios de estado en el clúster para desencadenar el procesamiento posterior, como la configuración de actualización dinámica. |
| Arroyo de nubes de primavera | El componente de middleware de mensajes de Spring Cloud integra middleware de mensajes como Apache Kafka y RabbitMQ, y realiza perfectamente el aislamiento entre la aplicación y el middleware de mensajes al definir el enlazador como la capa intermedia. Al exponer un canal de canal unificado a la aplicación, la aplicación puede enviar y recibir mensajes fácilmente sin tener que considerar varias implementaciones de middleware de mensajes. |
| Detective de nubes de primavera | El componente de seguimiento de enlaces distribuidos de Spring Cloud puede integrar perfectamente Zipkin de Twitter. |
2. Asociación entre Spring Cloud y Spring Boot
SpringBoot se enfoca en el desarrollo rápido y conveniente de microservicios individuales.
SpringCloud es un marco de gobernanza y coordinación de microservicios que se centra en la situación general. Integra y gestiona microservicios individuales desarrollados por SpringBoot y proporciona: gestión de configuración, descubrimiento de servicios, disyuntores, enrutamiento, microagentes, servicios integrados como bus de eventos, bloqueo global, campaña de toma de decisiones, sesión distribuida, etc.
SpringBoot se enfoca en el desarrollo rápido y conveniente de microservicios individuales, mientras que SpringCloud se enfoca en el marco de gobernanza de servicios globales
Spring Boot puede crear directamente proyectos o módulos que pueden ejecutarse de forma independiente sin Spring Cloud
Spring Cloud se implementa en base a Spring Boot. No puede crear proyectos o módulos de forma independiente, y mucho menos ejecutarse independientemente de Spring Boot.
La relación correspondiente entre Spring Cloud y las versiones compatibles con Spring Boot es la siguiente (consulte el sitio web oficial de Spring Cloud )
3. Diagrama de arquitectura de Spring Cloud Netflix
Proveedor de servicios: el proveedor de servicios que expone el servicio
Consumidor del servicio: el consumidor del servicio que llama al servicio remoto.
Servidor EureKa: Registro de Servicios y Centro de Descubrimiento de Servicios
artículo de referencia