Arquitectura de microservicios: diseño de arquitectura de plataforma en la nube PaaS basada en microservicios y tecnología de contenedores Docker

El objetivo de construir una plataforma en la nube PaaS basada en una arquitectura de microservicios y tecnología de contenedores Docker es proporcionar a nuestros desarrolladores un conjunto de procesos para un rápido desarrollo, implementación, gestión de operación y mantenimiento de servicios, y un desarrollo continuo y continuo. integración. La plataforma proporciona recursos como infraestructura, middleware, servicios de datos y servidores en la nube. Los desarrolladores solo necesitan desarrollar códigos comerciales y enviarlos a la biblioteca de códigos de la plataforma, y ​​realizar algunas configuraciones necesarias. El sistema se construirá e implementará automáticamente para lograr una agilidad y eficiencia. iterar el desarrollo rápido de aplicaciones. En términos de arquitectura del sistema, la plataforma en la nube PaaS se divide principalmente en tres partes: arquitectura de microservicio, tecnología de contenedor Docker y DveOps. Este artículo se centra en la implementación de la arquitectura de microservicio.

Si quieres aprender ingeniería, alto rendimiento y distribución de Java, explícalo de forma sencilla. Los amigos que estén interesados ​​en microservicios, análisis de código fuente de Spring, MyBatis y Netty pueden unirse a mi intercambio avanzado de Java: 854630135. En el grupo, hay una explicación de tecnología transmitida en vivo por Alibaba Daniel, así como videos de tecnología de Internet a gran escala de Java. para compartir con todos de forma gratuita.

La implementación de microservicios requiere mucho esfuerzo técnico para desarrollar la infraestructura, lo que obviamente no es realista para muchas empresas. No se preocupe, la industria ya cuenta con excelentes marcos de código abierto para nuestra referencia. Actualmente, los marcos de microservicios relativamente maduros en la industria incluyen Netflix, Spring Cloud y Dubbo de Alibaba. Spring Cloud es un marco completo para implementar microservicios basado en Spring Boot. Proporciona los componentes necesarios para desarrollar microservicios. Cuando se utiliza con Spring Boot, será muy conveniente desarrollar servicios en la nube con una arquitectura de microservicios. Spring Cloud contiene muchos submarcos, de los cuales Spring Cloud Netflix es uno de los marcos. En nuestro diseño de arquitectura de microservicios, se utilizan muchos componentes del marco Spring Cloud Netflix. El proyecto Spring Cloud Netflix no existe desde hace mucho tiempo y hay muy pocos documentos relevantes. El blogger estudió este marco y leyó muchos documentos en inglés, lo cual fue extremadamente doloroso. Para los estudiantes que recién comienzan a entrar en contacto con este marco, es posible que no sepan cómo comenzar a construir una arquitectura de aplicación de microservicio. A continuación, presentaremos nuestro proceso de construcción de arquitectura de microservicio y qué marcos o componentes se necesitan para admitir la arquitectura de microservicio.

Para mostrar directa y claramente la composición y los principios de la arquitectura de microservicios, se dibuja un diagrama de arquitectura del sistema de la siguiente manera:

Como se puede ver en la figura anterior, el La ruta aproximada de acceso al microservicio es: Solicitud externa → Equilibrio de carga → Puerta de enlace de servicio (GateWay) → Microservicio → Servicio de datos/servicio de mensajes. Las puertas de enlace de servicios y los microservicios utilizarán el registro y el descubrimiento de servicios para llamar a otros servicios dependientes. Cada grupo de servicios puede obtener información de configuración a través del servicio del centro de configuración.

Puerta de enlace de servicio (GateWay)

La puerta de enlace es una puerta entre los sistemas externos (como navegadores de clientes, dispositivos móviles, etc.) y el sistema interno de la empresa. Acceda a los servicios backend a través de la puerta de enlace. Para hacer frente a un alto acceso simultáneo, la puerta de enlace del servicio se implementa en forma de clúster, lo que significa que se requiere equilibrio de carga. Usamos Amazon EC2 como servidor de nube virtual y ELB (Elastic Load Balancing) para el equilibrio de carga. EC2 tiene una función de configuración automática de capacidad. Cuando el tráfico de usuarios alcanza un pico, EC2 puede agregar automáticamente más capacidad para mantener el rendimiento del host virtual. El equilibrio de carga elástico de ELB distribuye automáticamente el tráfico entrante de la aplicación entre varias instancias. Para garantizar la seguridad, las solicitudes de los clientes deben estar protegidas mediante cifrado https, lo que requiere que descarguemos SSL y usemos Nginx para descargar solicitudes cifradas. Las solicitudes externas se enrutan a un servicio GateWay en el clúster GateWay después del equilibrio de carga de ELB y el servicio GateWay las reenvía al microservicio. Como límite del sistema interno, la puerta de enlace de servicios tiene las siguientes capacidades básicas:

1. Enrutamiento dinámico: enruta dinámicamente las solicitudes al clúster de servicios de back-end requerido.

Aunque la estructura interna es una compleja estructura de malla de microservicios distribuidos, el sistema externo parece un servicio general desde la puerta de enlace, lo que protege la complejidad de los servicios back-end.

2. Limitación actual y tolerancia a fallas: asigne capacidad para cada tipo de solicitud, descarte las solicitudes externas cuando el número de solicitudes exceda el umbral, limite el tráfico y proteja los servicios en segundo plano para que no se vean abrumados por el tráfico intenso. servicios internos Cuando ocurre una falla, algunas respuestas se crean directamente en el límite y la tolerancia a fallas se centraliza en lugar de reenviar la solicitud al clúster interno para garantizar una buena experiencia de usuario.

3. Autenticación de identidad y control de seguridad: la autenticación del usuario se realiza para cada solicitud externa y las solicitudes que no pasan la autenticación se rechazan. También puede implementar funciones anti-rastreadores a través del análisis del modo de acceso.

4. Monitoreo: la puerta de enlace puede recopilar datos y estadísticas significativos para brindar soporte de datos para la optimización del servicio backend.

5. Registro de acceso: la puerta de enlace puede recopilar información del registro de acceso, como por ejemplo, ¿a qué servicio se accede? ¿Proceso de procesamiento (qué excepción ocurrió) y resultados? ¿Cuánto tiempo lleva? Al analizar el contenido del registro, el sistema en segundo plano se puede optimizar aún más.

Utilizamos Zuul, un componente de código abierto del marco Spring Cloud Netflix, para implementar el servicio de puerta de enlace. Zuul utiliza una serie de diferentes tipos de filtros (Filter). Al reescribir los filtros, podemos implementar de manera flexible varias funciones de la puerta de enlace (GateWay).

Si quieres aprender ingeniería, alto rendimiento y distribución de Java, explícalo de forma sencilla. Los amigos que estén interesados ​​en el análisis del código fuente de microservicios, Spring, MyBatis y Netty pueden unirse a mi intercambio avanzado de Java: 854630135. En el grupo, hay una transmisión en vivo de Alibaba Daniel que explica la tecnología, así como videos de la tecnología de Internet a gran escala de Java para comparte con todos de forma gratuita.

Registro y descubrimiento de servicios

Dado que la arquitectura de microservicios es una estructura de malla compuesta por una serie de servicios detallados con responsabilidades únicas, y los servicios se comunican a través de mecanismos livianos, este El problema de Se introduce el registro y descubrimiento de servicios. El proveedor de servicios debe registrar e informar la dirección del servicio, y la persona que llama al servicio debe poder descubrir el servicio de destino. Nuestra arquitectura de microservicio utiliza componentes Eureka para implementar el registro y el descubrimiento de servicios. Todos los microservicios (mediante la configuración de la información del servicio Eureka) se registran en el servidor Eureka y envían periódicamente latidos para realizar comprobaciones de estado. La configuración predeterminada de Eureka es enviar un latido una vez cada 30 segundos, lo que indica que el servicio todavía está activo. Se pueden pasar latidos Los parámetros de configuración de Eureka se configuran por sí mismos Después de recibir el último latido de la instancia de servicio, el servidor Eureka debe esperar 90 segundos (la configuración predeterminada es 90 segundos, que se puede modificar a través de los parámetros de configuración) antes de considerar que el El servicio ha muerto (es decir, no se ha utilizado durante 3 veces consecutivas y se recibe un latido), la información de registro del servicio se borrará cuando se desactive el modo de autoprotección de Eureka. El llamado modo de autoprotección significa que cuando se produce una partición de la red y Eureka pierde demasiados servicios en un corto período de tiempo, entrará en el modo de autoprotección, es decir, si un servicio no envía latidos durante un tiempo prolongado. tiempo, Eureka no lo borrará. El modo de autoprotección está activado de forma predeterminada y se puede desactivar mediante parámetros de configuración.

El servicio Eureka se implementa en un clúster (el método de implementación del clúster Eureka se presenta en detalle en otro artículo del blogger. Todos los nodos Eureka en el clúster sincronizarán automáticamente la información de registro del microservicio). a intervalos regulares Esto garantiza que toda la información de registro del servicio Eureka sea coherente. Entonces, en el clúster de Eureka, ¿cómo descubre el nodo de Eureka otros nodos? Establecemos la asociación de todos los nodos de Eureka a través del servidor DNS. Además de implementar el clúster de Eureka, también necesitamos construir un servidor DNS.

Cuando el servicio de puerta de enlace reenvía solicitudes externas o se llama entre sí entre microservicios en segundo plano, irá al servidor Eureka para encontrar la información de registro del servicio de destino, descubrirá el servicio de destino y lo llamará, formando así una registro del servicio y todo el proceso de descubrimiento. Eureka tiene una gran cantidad de parámetros de configuración, hasta cientos, y el blogger los explicará en detalle en otro artículo.

Implementación de microservicios

Los microservicios son una serie de servicios detallados con responsabilidades únicas. Dividen nuestro negocio en unidades de servicios independientes con buena escalabilidad y acoplamiento. Se pueden desarrollar diferentes microservicios. en diferentes idiomas, y cada servicio atiende un único negocio. Los microservicios se pueden dividir en servicios de front-end (también llamados servicios de borde) y servicios de back-end (también llamados servicios intermedios). Los servicios de front-end realizan la agregación y adaptación necesarias de los servicios de back-end y luego los exponen a diferentes. dispositivos externos (PC, teléfono, etc.), todos los servicios se registrarán en el servidor Eureka cuando se inicien y habrá dependencias complejas entre los servicios. Cuando el servicio de puerta de enlace reenvía una solicitud externa para llamar al servicio de front-end, puede encontrar el servicio de destino al que llamar consultando el registro del servicio. Lo mismo ocurre cuando el servicio de front-end llama al servicio de back-end. implican llamadas mutuas entre múltiples servicios. Dado que cada microservicio se implementa en forma de clúster, se requiere equilibrio de carga cuando los servicios se llaman entre sí. Por lo tanto, cada servicio tiene un componente LB para lograr el equilibrio de carga.

Los microservicios se ejecutan en contenedores Docker en forma de imágenes. La tecnología de contenedores Docker hace que la implementación de nuestros servicios sea simple y eficiente. El método de implementación tradicional requiere instalar el entorno operativo en cada servidor. Si tenemos una gran cantidad de servidores, instalar el entorno operativo en cada servidor será una tarea extremadamente ardua, una vez que el entorno operativo cambie, tendremos que reinstalarlo. esto es simplemente desastroso. Al utilizar la tecnología de contenedor Docker, solo necesitamos generar una nueva imagen a partir de la imagen básica requerida (jdk, etc.) y los microservicios, e implementar la imagen final para ejecutarla en el contenedor Docker. Este método es simple, eficiente y se puede implementar. servir rápidamente. Cada contenedor Docker puede ejecutar múltiples microservicios. Los contenedores Docker se implementan en un clúster y Docker Swarm se utiliza para administrar estos contenedores. Creamos un almacén espejo para almacenar todas las imágenes básicas y las imágenes de entrega finales generadas, y gestionamos todas las imágenes en el almacén espejo.

Tolerancia a fallas del servicio

Existen dependencias intrincadas entre los microservicios. Una solicitud puede depender de múltiples servicios de back-end. En la producción real, estos servicios pueden causar fallas o retrasos. -Sistema de tráfico, una vez que un servicio se retrasa, los recursos del sistema pueden agotarse en un corto período de tiempo y todo el sistema dejará de funcionar. Por lo tanto, si un servicio no puede aislar y tolerar fallas, será catastrófico en sí mismo. Los componentes de Hystrix se utilizan en nuestra arquitectura de microservicios para lograr tolerancia a fallas. Hystrix es un componente de código abierto de Netflix. Utiliza modo de disyuntor, modo de aislamiento, respaldo, limitación de corriente y otros mecanismos para proporcionar protección elástica de tolerancia a fallas para los servicios y garantizar la estabilidad del sistema.

1. Modo de soplado: El principio del modo de soplado es similar al de un fusible de circuito. Cuando se produce un cortocircuito en el circuito, el fusible se funde para proteger el circuito de pérdidas catastróficas. Cuando el servicio es anormal o tiene un gran retraso y se cumplen las condiciones del disyuntor, la persona que llama al servicio iniciará activamente el disyuntor, ejecutará la lógica de respaldo y regresará directamente, y no continuará llamando al servicio para desactivar aún más el sistema. El umbral de tasa de error de llamada de servicio configurado predeterminado del fusible es del 50%. Si se excede el umbral, el modo de fusible se activará automáticamente. Después de que el servicio esté aislado por un período de tiempo, el disyuntor entrará en un estado de semicircuito, lo que permitirá intentar una pequeña cantidad de solicitudes. Si la llamada aún falla, volverá al estado de disyuntor. La llamada es exitosa, el disyuntor apagará el modo de disyuntor.

2. Modo de aislamiento: Hystrix adopta el aislamiento de subprocesos de forma predeterminada. Diferentes servicios utilizan diferentes grupos de subprocesos y no se ven afectados entre sí. Cuando un servicio falla y agota los recursos del grupo de subprocesos, otros servicios no funcionan normalmente. afectados, logrando efecto de aislamiento. Por ejemplo, configuramos un servicio para usar un grupo de subprocesos llamado TestThreadPool a través de andThreadPoolKey para lograr el aislamiento de otros grupos de subprocesos con nombre.

3. Respaldo: el mecanismo de respaldo es en realidad un método tolerante a fallas cuando falla un servicio. El principio es similar al manejo de excepciones en Java.

Solo necesita heredar HystixCommand y reescribir el método getFallBack () y escribir la lógica de procesamiento en este método. Por ejemplo, puede generar excepciones directamente (falla rápida), devolver valores nulos o predeterminados, o devolver datos de respaldo, etc. Cuando ocurre una excepción en la llamada de servicio, se ejecutará getFallBack(). Las siguientes situaciones desencadenarán una reserva:

1) El programa genera una excepción que no es HystrixBadRequestExcepption Cuando se lanza una excepción HystrixBadRequestExcepption, el programa que realiza la llamada puede detectar la excepción y no se activa ninguna reserva cuando se lanzan otras excepciones. , activará el respaldo;

2) El programa se ejecuta durante el tiempo de espera

3) Se inicia el disyuntor

4) El grupo de subprocesos está lleno.

4. Limitación actual: la limitación actual se refiere a limitar la cantidad de accesos simultáneos a un servicio, establecer la cantidad de concurrencias por unidad de tiempo y rechazar solicitudes que excedan el límite y provocar un respaldo para evitar servicios en segundo plano. de sentirse abrumado.

Hystix utiliza el modo de comando HystrixCommand para envolver la lógica de llamadas dependientes, de modo que las llamadas relacionadas estén automáticamente bajo la protección elástica de tolerancia a fallas de Hystrix. El programa que llama debe heredar HystrixCommand y escribir la lógica de llamada en run (), y usar ejecutar () (bloqueo sincrónico) o cola () (sin bloqueo asíncrono) para activar la ejecución de run ().

Centro de configuración dinámica

Los microservicios tienen muchas configuraciones dependientes y es posible que sea necesario modificar dinámicamente algunos parámetros de configuración durante la operación del servicio, como ajustar dinámicamente el umbral del disyuntor en función del tráfico de acceso. El método tradicional de implementar la configuración de la información, como colocarla en xml, yml y otros archivos de configuración, y empaquetarla junto con la aplicación. Cada modificación requiere volver a enviar el código, empaquetarlo y compilarlo, generar una nueva imagen y reiniciar el servicio. Esto es demasiado ineficiente. Obviamente, no es razonable, por lo que necesitamos crear un servicio de centro de configuración dinámica para admitir la configuración dinámica de microservicios. Usamos el servicio configserver de Spring Cloud para ayudarnos a construir un centro de configuración dinámica. Los códigos de microservicio que desarrollamos se almacenan en el almacén privado del servidor git. Todos los archivos de configuración que deben configurarse dinámicamente se almacenan en el servicio configserver (centro de configuración, también un microservicio) en el servidor git. El contenedor es de El servidor git lee dinámicamente la información del archivo de configuración. Cuando el repositorio de git local modifica el código y lo envía al repositorio del servidor de git, los enlaces del servidor de git (post-recepción, llamados automáticamente después de que el servidor completa la actualización del código) detectan automáticamente si hay una actualización del archivo de configuración. El servidor git pasa la cola de mensajes Envíe un mensaje al centro de configuración (configserver, un microservicio implementado en un contenedor) para notificar al centro de configuración que actualice el archivo de configuración correspondiente. De esta manera, el microservicio puede obtener la información más reciente del archivo de configuración y realizar una configuración dinámica.

Los marcos o componentes anteriores son el núcleo para respaldar la implementación de la arquitectura de microservicios. En la producción real, también utilizaremos muchos otros componentes, como componentes de servicio de registro, componentes de servicio de mensajes, etc. necesidades comerciales Úselo a su propia discreción. En nuestro caso de implementación de arquitectura de microservicio, nos referimos a muchos componentes de código abierto del marco Spring Cloud Netflix, incluidos Zuul (puerta de enlace de servicio), Eureka (registro y descubrimiento de servicios), Hystrix (tolerancia a fallas de servicio), Ribbon (equilibrio de carga del cliente). esperar. Estos excelentes componentes de código abierto nos brindan un atajo para implementar la arquitectura de microservicios.

Si quieres aprender ingeniería, alto rendimiento y distribución de Java, explícalo de forma sencilla. Los amigos que estén interesados ​​en el análisis del código fuente de microservicios, Spring, MyBatis y Netty pueden unirse a mi intercambio avanzado de Java: 854630135. En el grupo, hay una transmisión en vivo de Alibaba Daniel que explica la tecnología, así como videos de la tecnología de Internet a gran escala de Java para comparte con todos de forma gratuita.