Directorio de artículos
- fondo
- ¿Qué es una malla de servicios?
- Servicio malla producto estrella Istio
- Evolución ecológica de la malla de servicios de Nacos
- La ecología de la red de servicios de Nacos se ha implementado a gran escala en Ali
fondo
- Kubernetes realiza la implementación automática de la infraestructura y la gestión de recursos, reduce los costos de operación y mantenimiento y mejora la elasticidad del negocio.
- Kubernetes tiene grandes ventajas en la implementación y la elasticidad de las aplicaciones, pero carece de soporte para la gobernanza del servicio, las puertas de enlace, la autenticación y la observabilidad.
- Muchos productos y middleware tradicional se reforman para compensar las deficiencias de Kubernetes y migran a la nube nativa y Kubernetes.
- Service Grid es la próxima generación de gobernanza de microservicios, que se sumerge en la capa de infraestructura para la gobernanza general y admite sistemas heterogéneos.
- La malla de servicios se basa en la orquestación de contenedores de Kubernetes desde la teoría hasta la práctica, y ha recibido una atención y un uso de producción generalizados.
- Istio es la red de servicios más popular y proporciona una API declarativa estándar que abstrae la infraestructura como Kubernetes.
- Nacos integra profundamente la ecología de Spring y Dubbo, y ahora integra Istio, lo que permite a los usuarios usarlo en varios escenarios.
- Nacos se mantiene al día con la tendencia tecnológica y no pierde los dividendos de Kubernetes y Service Mesh.
- Kubernetes ha cambiado la forma de administrar los recursos y la operación y el mantenimiento de la implementación, y Nacos también está evolucionando para adaptarse a las nuevas tecnologías.
- Kubernetes reduce los costos de operación y mantenimiento y mejora la flexibilidad empresarial. Service mesh y Nacos brindan a los usuarios una mejor experiencia técnica.
- La tecnología nativa de la nube Kubernetes y la red de servicios han provocado cambios industriales, y Nacos está conectado a su ecosistema para brindar valor a los usuarios.
¿Qué es una malla de servicios?
Para comprender profundamente el concepto de Service Grid, aclarar los problemas que debe resolver Service Grid y darse cuenta del valor comercial que brinda Service Grid, es necesario comenzar desde el principio con la evolución y el desarrollo de la arquitectura de la aplicación.
La evolución de la arquitectura monolítica a la arquitectura de microservicios
En los últimos años, con el continuo desarrollo y expansión del sistema empresarial, la aplicación monolítica ha completado la transformación a la arquitectura de microservicio. La aplicación se divide en servicios según la dimensión funcional y el dominio comercial. Los diferentes equipos comerciales se centran en los servicios de los que son responsables. Cada microservicio itera de forma independiente y no se afecta entre sí. Esta idea de dividir los dominios comerciales no solo acelera el desarrollo comercial, sino que también brinda una experiencia de desarrollo más ágil.
Todo tiene dos caras: si bien los microservicios mejoran la velocidad iterativa y la agilidad de las aplicaciones comerciales, también plantean más desafíos para la gobernanza de servicios . Originalmente era una aplicación monolítica y todos los servicios estaban en un solo proceso. Las llamadas entre servicios eran llamadas de método y todo el flujo de procesamiento de solicitudes estaba en el subproceso actual, lo cual es muy conveniente para la depuración y la resolución de problemas. Después de transformarse en una arquitectura de microservicios, los servicios en el monómero original se implementan y ejecutan de forma independiente, y las llamadas a métodos se convierten en llamadas remotas.
descubrimiento de servicios
El primer problema a resolver es el problema de descubrimiento de servicios , cómo el servicio del consumidor descubre el servicio del proveedor en tiempo de ejecución, y la dirección IP del nodo de servicio implementado de forma independiente no es fija, lo que significa que se requiere una capacidad de descubrimiento dinámico. El surgimiento del centro de registro es para resolver el problema del descubrimiento de servicios en la arquitectura de microservicio. Cada microservicio registrará su IP de red de nodo con el centro de registro cuando se implemente y libere , y también cerrará la sesión del centro de registro a tiempo cuando se desconecta _ Al mismo tiempo, cada microservicio también se suscribirá al centro de registro para la información de nodo de otros microservicios de los que depende Cuando cambie la información de nodo del microservicio suscrito, puede recibir y actualizar el conjunto de conexiones locales en tiempo real.
balanceo de carga
Después de resolver el problema de cómo descubrir entre servicios, el servicio de Consumidor puede seleccionar una dirección IP de la lista de información de nodo obtenida del centro de registro para iniciar una llamada de red al servicio de Proveedor al procesar la solicitud. Para maximizar la utilización de los recursos y minimizar el RT de la solicitud , es necesario seleccionar un nodo óptimo del grupo de nodos , que es el equilibrio de carga . Si los recursos de hardware ocupados por las copias de microservicios son diferentes, se debe dar más tráfico a los nodos con suficientes recursos de hardware. Si las copias del microservicio están ubicadas en diferentes regiones, es necesario acceder preferentemente al nodo en la misma región que la persona que llama. Si la empresa requiere permanencia en la sesión, las solicitudes del mismo usuario siempre deben acceder al mismo nodo. Si es necesario calentar el microservicio después del inicio, el tráfico debe desviarse gradualmente a este nodo
Límite de corriente del fusible
En el proceso actual de toda la cadena de llamadas en una sola aplicación , ante un pico de tráfico repentino , solo necesitamos fusionar y limitar el flujo en la entrada de la aplicación . En la arquitectura de microservicios, cada microservicio se implementa de forma independiente y el número de copias varía según la importancia de sus funciones. Ante solicitudes de tráfico concurrentes elevadas, los umbrales para la interrupción del circuito y la limitación de cada servicio deben ser diferentes. Además, la arquitectura de microservicio aumenta la cantidad de saltos de red en toda la cadena de procesamiento de solicitudes , cualquiera de los servicios ascendentes puede arrastrar hacia abajo los servicios descendentes e incluso hacer que el sistema en su conjunto no esté disponible .
Observable (supervisión y alerta)
En términos de observabilidad , la arquitectura de microservicios se basa principalmente en tres medios:
- Rastreo : Rastreo de enlaces distribuidos, utilizado para localizar el nodo específico donde ocurrió la falla. Debido a que el enlace de invocación de la solicitud del microservicio es complejo, es necesario conocer el enlace de acceso de toda la solicitud a través de algún medio.
- Registro : registros de registro, utilizados para localizar la causa específica de la falla. Se usa junto con Rastreo para registrar información de metadatos de solicitud en cada servicio para ayudar a solucionar problemas.
- Métricas : establezca las reglas de alarma para la cantidad de conexiones, la cantidad de solicitudes, la tasa de éxito y otros indicadores de cada servicio para encontrar problemas y mejorar la estabilidad del sistema.
Autenticación
En la arquitectura de microservicios, para proteger la seguridad de los servicios confidenciales , los mecanismos de autenticación y autenticación generalmente se usan para restringir el acceso de solo clientes específicos a los servicios confidenciales. El método específico es:
- Se introduce un sistema de autorización centralizado para autorizar qué clientes pueden acceder a cada servicio sensible.
- Cuando el cliente inicia una llamada de solicitud, primero obtiene información de credenciales del sistema de autorización.
- Llevar información de credenciales al acceder a servicios confidenciales.
- Los servicios confidenciales verifican la información de credenciales y los permisos de todas las solicitudes recibidas, y solo procesan la solicitud si pasa la verificación; de lo contrario, la rechazan.
Esto puede evitar el problema del acceso aleatorio a servicios confidenciales por parte de cualquier cliente que pueda obtener información del nodo de servicio bajo la arquitectura de microservicio.
otro…
Publicación de servicios, seguridad de las comunicaciones, enrutamiento dinámico...
resumen
Los desafíos y las soluciones que presenta la arquitectura de microservicios se analizan en detalle anteriormente a través de algunos escenarios comerciales reales, que básicamente cubren varias áreas importantes de gobierno de servicios, descubrimiento de servicios, equilibrio de carga, ruptura de circuitos y limitación de corriente, monitoreo y alarmas, y autenticación y autenticación . .
Podemos usar la siguiente figura para cubrir varias áreas importantes involucradas en la arquitectura de microservicios.
Soluciones tradicionales para arquitectura de microservicios
En resumen, los principales impulsores de la evolución empresarial hacia la arquitectura de microservicios son:
- El aumento en la dificultad de la colaboración y la necesidad de frecuencia de lanzamiento provocada por el crecimiento de la escala comercial, el desarrollo independiente y la implementación de cada servicio bajo la arquitectura de microservicio reduce la dificultad de la colaboración en equipo y satisface las necesidades de iteraciones frecuentes.
- Con la rápida evolución del negocio de Internet, la división de servicios es inminente. Las principales empresas responden a los cambios comerciales a través de la división de servicios y marcos de microservicios.
- El marco de microservicios de código abierto (Spring Cloud, Dubbo, Gin, etc.) implementa varias funciones de comunicación de sistemas distribuidos y gobierno de servicios (equilibrio de carga, descubrimiento de servicios, fusión, etc.), simplifica el desarrollo de microservicios y permite a los desarrolladores centrarse en el negocio. .
- El nuevo negocio elige la arquitectura de microservicios y realiza un desarrollo ágil con la ayuda del marco.
- Estos marcos son amigables para los desarrolladores de negocios, protegen los detalles subyacentes, permiten a los desarrolladores concentrarse en el negocio y desarrollar sistemas distribuidos sólidos con una pequeña cantidad de código de marco.
En resumen, el desarrollo comercial y el progreso tecnológico han promovido conjuntamente la popularidad de la arquitectura de microservicios. Los marcos de código abierto simplifican el desarrollo de microservicios y lo hacen más práctico, lo que también acelera el proceso. La arquitectura de microservicio resuelve eficazmente los desafíos de colaboración y entrega que plantea el desarrollo distribuido a gran escala y satisface mejor las necesidades comerciales en rápida evolución.
La siguiente figura muestra la llamada entre servicios en el escenario de microservicio. El desarrollador de negocios solo necesita iniciar una llamada al servicio B en el código comercial del servicio A, y no necesita preocuparse por cómo se implementa la capa inferior de la llamada de solicitud. , por ejemplo, cómo encontrar la dirección del servicio B, cómo equilibrar la carga del servicio B, cómo realizar el control de flujo, la codificación y decodificación en la capa de protocolo y la comunicación confiable de la red subyacente.
Esta arquitectura de modelo de microservicio parece perfecta, pero hay algunos problemas esenciales:
- El alto costo de aprendizaje del marco en sí . Los desarrolladores necesitan gastar más energía para dominar y administrar marcos complejos, y también es difícil resolver problemas de marcos.
- El negocio está estrechamente relacionado con el marco . El marco está vinculado con el servicio en forma de biblioteca, los problemas de compatibilidad y actualización de versiones son complicados, y la actualización del marco afectará la estabilidad del servicio.
- Limite la pila de tecnología empresarial . Los marcos generalmente solo admiten ciertos idiomas, por lo que las empresas solo pueden elegir idiomas y middleware que sean compatibles con el marco. Un lenguaje sin soporte de marco es difícil de integrar en una arquitectura de microservicios. Es difícil implementar diferentes módulos del sistema de microservicios en varios idiomas.
Por lo tanto, aunque el marco de microservicio simplifica el desarrollo, también trae los problemas anteriores. Cuando la empresa selecciona y utiliza el marco de microservicios, debe sopesar estos problemas y hacer un buen trabajo en la gestión y el control de riesgos.
En aplicaciones prácticas, puede elegir un marco simple y estable, o personalizar el marco de desarrollo, o no usar ningún marco, y enfrentar directamente varios problemas causados por la distribución. Para elegir la mejor solución de acuerdo con la situación real del negocio
Arquitectura de microservicios de próxima generación - Service Mesh
Para resolver las tres limitaciones anteriores de la arquitectura de microservicio tradicional, surgió el modo proxy (modo sidecar) representado por Istio y NginxMesh. Esta es la tecnología de red de servicio caliente en el campo de la arquitectura de microservicio: Service Mesh, que capa de comunicación de servicios distribuidos en una capa separada, en la que se realizan las funciones requeridas por los sistemas distribuidos, como equilibrio de carga, descubrimiento de servicios, autenticación y autorización, monitoreo y seguimiento, y control de flujo .
Desde un punto de vista macro, el método de implementación consiste en introducir un servicio de proxy, que se implementa junto con cada servicio comercial en forma de Sidecar (modo sidecar), y el servicio de proxy se hace cargo de todo el tráfico entrante y saliente del servicio. . Como el cerebro de control central, el plano de control realiza un control y una gestión de tráfico unificados en todos los servicios de proxy empresarial (Sidecar) .
Desde un punto de vista microscópico, este servicio de proxy completa indirectamente las solicitudes de comunicación entre servicios a través de la comunicación de tráfico entre los servicios comerciales de proxy, y todo el gobierno de servicios involucrado en el sistema distribuido se completa en el servicio de proxy. A través de una capa de gobernanza de servicios desvinculada del negocio, los tres problemas mencionados anteriormente se pueden resolver fácilmente.
Capa de Gobernanza del Servicio
Servicio malla producto estrella Istio
Istio es griego, significa "zarpar" y hace eco de "kubernetes (timonel)". Es una infraestructura de supervisión, protección y gestión de microservicios de código abierto. Istio se pronuncia "Istio".
¿Qué es Istio?
Istio es un proyecto de código abierto desarrollado conjuntamente por los equipos de Google, IBM y Lyft para conectar, proteger, controlar y observar los servicios implementados en clústeres.
Una de las tecnologías nativas de la nube más populares, ServiceMesh, se implementa mediante Istio + Envoy .
Como proxy, Envoy se implementa junto con los servicios de aplicaciones en forma de SideCar, intercepta de forma transparente todo el tráfico de entrada y el tráfico entrante y saliente de los servicios de aplicaciones, y ejecuta algunas políticas de control adicionales antes de reenviar el tráfico. Estas operaciones son transparentes para los servicios comerciales sin percepción. de . De esta forma, si hundimos las funciones del SDK relacionado con la gobernanza del servicio junto con las aplicaciones comerciales en SideCar, entonces el código comercial se desvinculará del código de gobernanza del servicio y podrá desarrollarse en paralelo y de forma iterativa.
Desde esta perspectiva, ServiceMesh proporciona la capa de infraestructura de comunicación de red a nivel de aplicación y ejecuta políticas de gobierno configuradas por el usuario sobre el tráfico en ella. El rol de definición y emisión de estas políticas de gobierno es Istio.
Todos sabemos que K8s ha cambiado la forma tradicional de implementación y lanzamiento de aplicaciones, brindando servicios de aplicaciones en contenedores con arreglos de contenedores flexibles y convenientes, programación de contenedores y un mecanismo simple de descubrimiento de servicios, pero carece de capacidades de gobierno de servicios más ricas y detalladas. La aparición de Istio es precisamente para suplir la falta de K8 en el gobierno de servicios, define un conjunto de API estándar para definir estrategias de gobierno comunes.
K8s e Istio son complementarios y juntos determinan el comportamiento de implementación, lanzamiento y tiempo de ejecución de las aplicaciones empresariales.
La puerta de enlace está en el borde del clúster y controla el tráfico entrante y saliente del clúster. Se puede considerar como una implementación independiente del proxy Envoy, que actúa como proxy de todo el clúster.
Enviado
Envoy es un proxy de borde nativo de la nube de código abierto (proxy de borde) y un bus de comunicación desarrollado y mantenido por Lyft. El papel principal de Envoy es como un proxy en la arquitectura de microservicios, proporcionando las siguientes funciones:
- Descubrimiento de servicios: Envoy integra una variedad de mecanismos de descubrimiento de servicios, que pueden descubrir dinámicamente servidores back-end.
- Equilibrio de carga: Envoy admite una variedad de algoritmos de equilibrio de carga y puede realizar el equilibrio de carga en función de la lista de backends descubiertos por el servicio.
- Inyección de fallas y fusibles: Envoy admite el modo de fusible, que puede devolver directamente un error cuando el servicio de back-end no logra evitar la propagación de fallas. También es compatible con la inyección de fallas, que se utiliza para probar la capacidad de recuperación ante desastres de la aplicación.
- Supervisión y telemetría: Envoy expone métricas en formato Prometheus, lo que facilita el uso de Prometheus y otros sistemas para la supervisión y la telemetría de servicios.
- Publicación en escala de grises: Envoy admite la separación del tráfico basada en encabezados HTTP, cookies, etc., y puede realizar la publicación de microservicios en escala de grises.
- Seguridad: Envoy admite mTLS de autenticación de identidad mutua basada en SSL/TLS, que puede cifrar y autenticar la comunicación entre microservicios.
- Observabilidad: Envoy genera varias estadísticas, registros y seguimientos para monitorear el tráfico y depurar aplicaciones.
Por lo tanto, la función principal de Envoy es actuar como un agente en la arquitectura de microservicios, proporcionar funciones ricas de observabilidad y gobernanza de servicios, y ayudar a construir un sistema de microservicios estable y confiable. Protege una gran cantidad de detalles complejos en la comunicación del sistema distribuido, para que los desarrolladores de servicios puedan concentrarse en el negocio del dominio.
Envoy ha sido utilizado por muchas empresas conocidas, como Lyft, Airbnb, Pinterest, Expedia, Aral, etc. En China, Ali, Didi y otras empresas también han utilizado Envoy
Enviado e Istio
Tanto Envoy como Istio son proyectos de código abierto para arquitecturas de microservicios, pero con un enfoque ligeramente diferente:
Envoy:
- Envoy es un proxy de borde de código abierto (proxy de borde), que implementa principalmente funciones como el descubrimiento de servicios, el equilibrio de carga, la ruptura de circuitos, el monitoreo y la publicación en escala de grises.
- Envoy crea una capa de proxy distribuido mediante la implementación de varias instancias de proxy para lograr las funciones anteriores. Las solicitudes de los clientes para cada servicio pasarán primero por el proxy perimetral de Envoy y luego se reenviarán al servicio de backend.
- Envoy es solo un proxy, de naturaleza relativamente liviana y desvinculado del marco de servicio específico. Un servicio que se puede utilizar para cualquier desarrollo de lenguaje/marco.
- Envoy no puede implementar funciones de gobernanza de servicios más avanzadas, como seguridad (mTLS entre servicios), gestión de tráfico, etc.
istio:- Istio es un marco de malla de servicios. Además de las funciones de proxy, también proporciona funciones de gobernanza de servicios más completas, como seguridad, gestión del tráfico y observabilidad.
- Istio se basa en el proxy Envoy, pero está construido sobre Envoy, y proporciona detección de servicios, seguridad, gestión del tráfico y otras funciones de control para controlar toda la red de servicios.
- Istio debe usarse en combinación con un marco de servicio específico (como Kubernetes) y está altamente acoplado con el marco de servicio.
- Istio tiene capacidades de gobierno de servicios más avanzadas, pero también es más pesado y difícil de implementar y mantener.
Por lo tanto, Envoy es un proxy de servicio ligero de código abierto que proporciona principalmente funciones básicas de gobierno de servicios. Istio es un conjunto completo de soluciones de red de servicios, basado en Envoy pero que proporciona funciones más ricas, que es una solución más pesada.
Según sus necesidades, puede optar por utilizar Envoy o Istio, o una combinación de ambos. Envoy también se puede utilizar independientemente de Istio.
La arquitectura básica de Istio
El proyecto Istio es una nueva generación de marco de gobernanza de servicios nativos de la nube construido sobre la plataforma de operación y mantenimiento de Kubernetes.
Su diagrama de arquitectura es el siguiente, tomado del sitio web oficial de Istio ( https://istio.io )
Implica principalmente el servicio de proxy Proxy en el plano de datos, la puerta de enlace de entrada del clúster Ingress, la puerta de enlace de salida del clúster Egress y el plano de control central Istiod .
Las funciones de cada componente son las siguientes:
- El servicio de proxy Proxy utiliza el proxy de red C++ de alto rendimiento de código abierto de Lyft, Envoy, para interceptar todo el tráfico entrante y saliente de la empresa.
- La puerta de enlace de ingreso, como entrada de acceso del clúster, controla cómo se exponen de manera segura los servicios internos del clúster y realiza un control y una observación unificados de todo el tráfico de ingreso.
- La puerta de enlace de salida, como salida de acceso del clúster, controla cómo los servicios internos del clúster pueden acceder de forma segura a los servicios externos.
- El plano de control central Istio es responsable de entregar información de detección de servicios, configuración de gestión de tráfico y certificados TLS para la autenticación mutua entre servicios a todos los servicios de proxy en el plano de datos (incluidas las puertas de enlace de entrada y salida).
Se puede ver que Istiod es un maestro en el campo de los microservicios, que abarca el descubrimiento de servicios, el gobierno de servicios, la autenticación y la autenticación y la observabilidad, y propone nuevas soluciones para el negocio de la arquitectura de microservicios en la era nativa de la nube de una manera no invasiva. forma.
Evolución ecológica de la malla de servicios de Nacos
Para integrarse en la ecología de la red de servicios, Nacos completó una evolución de la arquitectura de microservicio 1.0 a la arquitectura de red de servicios.
Nacos bajo la arquitectura tradicional de microservicios
Para Nacos bajo la arquitectura tradicional de microservicios, su tráfico ingresa desde Tengine (Nginx), pasa a través de la puerta de enlace de microservicios y luego ingresa al sistema de microservicios.
La razón por la que se divide en dos capas de puertas de enlace es porque
- La primera capa de Tegine (Nginx) es responsable del acceso al tráfico. Las capacidades principales son anti-tráfico grande, protección de seguridad y soporte para certificados https, y la búsqueda de versatilidad, estabilidad y alto rendimiento.
- La segunda capa es la puerta de enlace de microservicios. Esta capa de puerta de enlace se centra en las capacidades relacionadas con los microservicios, como la autenticación y la autenticación, el control de servicios, la conversión de protocolos y el enrutamiento dinámico. Por ejemplo, Spring Cloudgateway de código abierto y zuul son puertas de enlace de microservicios.
Después de que el tráfico ingrese al sistema de microservicios, realizará llamadas entre servicios a través del marco de microservicios, como hsf/dubbo, spring cloud, etc., luego, el papel principal que desempeña Nacos aquí es la capacidad de descubrimiento de servicios, por ejemplo, Cousumer primero obtendrá el proveedor de Nacos La dirección de la lista de servicios y luego iniciará una llamada, y la puerta de enlace de microservicio también obtendrá la lista de servicios ascendentes a través de Nacos. Estas capacidades se proporcionan principalmente a través del SDK , y también se agregarán al SDK algunas estrategias de equilibrio de carga y protección de recuperación ante desastres .
Nacos bajo la arquitectura de microservicio tradicional tiene los siguientes problemas:
- Tengine no es compatible con la configuración dinámica, incluido el Nginx de código abierto de forma nativa Ali realiza internamente los cambios de configuración al recargar las configuraciones periódicamente, lo que conduce a la incapacidad de cambiar las configuraciones de manera oportuna y afecta la eficiencia de I + D;
- En el modo Fat SDK, las lógicas como el gobierno de servicios y el descubrimiento de servicios están fuertemente acoplados con el SDK. Si es necesario cambiar la lógica, el SDK debe modificarse para promover la actualización del lado comercial;
- Los SDK en diferentes idiomas deben mantenerse en varios idiomas, lo que es costoso y difícil de unificar las estrategias de gobierno del servicio;
Nacos en la era de la red de servicios
Con el desarrollo de la tecnología nativa de la nube y la introducción de la arquitectura de microservicios 2.0, muchas empresas están tratando de resolver los problemas de la arquitectura de microservicios 1.0 a través de la tecnología de red de servicios. En la arquitectura de microservicios 2.0, se accede al tráfico a través de la puerta de enlace de entrada y entra en el sistema de microservicios. La diferencia con la arquitectura 1.0 es que se introducen Envoy en el plano de datos e Istio en el plano de control . Envoy se implementa en el mismo Pod que la aplicación en modo Sidecar. En la arquitectura, el tráfico entrante y saliente de la aplicación será secuestrado, y luego la configuración XDS entregada por el plano de control Istio se puede usar para realizar control de tráfico, seguridad y observabilidad. La mayoría de las capacidades del SDK se eliminan y se sumergen en Sidecar, que también realiza la gestión unificada de diferentes idiomas.
La tecnología Service Mesh tiene muchas ventajas, pero la introducción de una nueva arquitectura también traerá nuevos problemas, especialmente para las empresas con grandes cargas técnicas, tales como: problemas de rendimiento del sidecar, problemas de soporte de protocolo privado, sistemas de arquitectura nuevos y antiguos. Cómo migrar sin problemas, etc. en.
Concéntrese principalmente en el tema de la migración sin problemas de los sistemas de arquitectura antiguos y nuevos. La migración sin problemas inevitablemente enfrentará dos problemas sobre el descubrimiento de servicios:
Cómo los sistemas de arquitectura antigua y nueva pueden descubrirse entre sí , porque el proceso de migración inevitablemente tendrá la coexistencia de los dos sistemas, y las aplicaciones deben llamarse entre sí; Cómo el centro
de registro admite la ecología de la red de microservicios , porque istio actualmente es compatible con el mecanismo de descubrimiento de servicios de K8s de forma predeterminada;
Entonces, ¿cómo resolver estos problemas en la ecología de la red de servicios de Nacos? Observe el siguiente diagrama de arquitectura, el tráfico proviene de la puerta de enlace nativa de la nube (la puerta de enlace nativa de la nube, que tiene las características de ser compatible con la arquitectura de microservicio, no solo es compatible con la puerta de enlace de microservicio, sino que también se ajusta a la nube -arquitectura nativa, y admite la puerta de enlace de entrada estándar K8s) entran y luego ingresan al sistema de microservicio, donde coexisten las aplicaciones 1.0 (aplicaciones que no son de malla) y las aplicaciones en malla.
La figura anterior explica cómo una aplicación que no es de malla accede a una aplicación de malla. A partir de este diagrama de arquitectura, podemos ver que las aplicaciones que no son de malla todavía se registran o se suscriben a los servicios de Nacos a través del SDK, y los proveedores que se han mallado también se registrarán en Nacos , de modo que las aplicaciones que no son de malla también pueden obtener aplicaciones en malla. Para la información del servicio de la aplicación, el servicio de registro del proveedor generalmente se realiza a través del método SDK, porque el Envoy de código abierto no es compatible con la función de registro de proxy. Por supuesto, cuando Ali lo implementó internamente, la capacidad de registro del servicio en realidad se redujo al sidecar. .
Otra pregunta es cómo hacer el descubrimiento de servicios para aplicaciones en malla. Podemos ver la parte inferior del diagrama de arquitectura. Nacos ya ha admitido la capacidad del servidor MCP. Istio obtiene una lista completa de información de servicio de Nacos a través del protocolo MCP, y luego la convierte en una configuración XDS y la envía a Envoy , que admite la malla El descubrimiento de servicios dentro de la aplicación también puede acceder a servicios que no son de malla Durante el proceso de malla, el descubrimiento de servicios se puede migrar sin problemas sin ninguna modificación.
protocolo MCP
El protocolo MCP es un protocolo de sincronización de configuración entre componentes propuesto por la comunidad de Istio. Este protocolo ha sido abandonado después de la 1.8. La alternativa es el protocolo MCP sobre XDS. Nacos es compatible con ambos protocolos.
Además del esquema de sincronización del protocolo MCP, también existen otros esquemas para sincronizar los datos de servicio del centro de registro al sistema ServiceMesh, estos esquemas se comparan, como se muestra en la siguiente figura:
La ecología de la red de servicios de Nacos se ha implementado a gran escala en Ali
Esta imagen resume generalmente los dos escenarios donde aterrizó Ali.
Escenario 1:
el escenario en el que Dingding Cloud se comunica con el grupo es esencialmente la interoperabilidad de la aplicación en el escenario de la nube híbrida. Usamos una puerta de enlace para conectar los dos entornos. Dingding VPC (Alibaba Cloud Deployment) usa MSE Para la puerta de enlace nativa de la nube, el grupo usa la puerta de enlace Envoy. Usan el protocolo triple Dubbo3.0 para realizar la comunicación de red. El plano de control de la puerta de enlace usa Istio, e Istio sincronizará los datos de la lista de servicios de Nacos a través del protocolo MCP.
El uso de esta arquitectura resuelve dos problemas:
- Problemas de seguridad de la comunicación de la red de la nube privada y la nube pública, porque la comunicación cifrada mtls se utiliza entre las puertas de enlace;
- Admite sin problemas la arquitectura de microservicios, porque la aplicación llama a la puerta de enlace a través del protocolo Triple, no se requieren cambios de código para el negocio y el descubrimiento del servicio es para sincronizar datos a través de Nacos mcp;
Esta arquitectura también se usa en el escenario de intercomunicación de Ant Group, que se encuentra en el lado izquierdo de esta imagen.La puerta de enlace de Ant usa la arquitectura de Mosn onEnvoy
Escena dos:
El escenario de malla de microservicio del grupo corresponde a la parte media e inferior de esta imagen. La diferencia entre la implementación interna y la comunidad es que Envoy está conectado directamente al centro de registro de Nacos. La razón principal para usar esta solución es considerar el rendimiento. Algunas de nuestras aplicaciones tendrán varios Si la IP de instancia de decenas de miles se envía a través de EDS, debido a que el volumen de datos es demasiado grande, causará problemas como Istio OOM o CPU alta en el plano de datos de Envoy.
