Resumen: En la primera cumbre de la comunidad global IstioCon 2021, Zhang Chaomeng, arquitecto jefe de Huawei Cloud Application Service Grid, pronunció un discurso de apertura sobre "Mejores prácticas: de Spring Cloud a Istio", compartiendo casos prácticos de Istio utilizados en producción.
Haga clic en el enlace para ver la charla: https://events.istio.io/istiocon-2021/sessions/best-practice%EF%BC%9Afrom-spring-cloud-to-istio/
El siguiente es el texto completo del discurso.
Hola a todos, soy un ingeniero de Huawei Cloud. Me siento honrado de tener la oportunidad de compartir con ustedes los casos reales de Istio utilizados en producción.
HUAWEI Cloud Application Service Grid se lanzó en la nube pública en 2018. Como uno de los primeros servicios de red en el mundo, ha experimentado y presenciado el proceso desde la comprensión y prueba iniciales de la red hasta el uso actual a gran escala. Cada vez se atiende a más clientes y los escenarios son cada vez más complejos. La mayoría de las funciones generales se aportan a la comunidad de Istio como características, y la práctica a nivel de solución también espera comunicarse con usted a través de esta oportunidad.
El tema que elegí esta vez es Spring Cloud to Istio. El caso de combinación y migración del proyecto en la nube Spring e Istio de nuestro cliente.
El discurso consta principalmente de cuatro partes:
1) Introducción a los antecedentes
2) Problemas encontrados al usar el marco de microservicio de Spring Cloud
3) Solución
4) Describe los detalles prácticos del programa a través de ejemplos.
Introducción de antecedentes
Aún tomando los microservicios como punto de entrada, las muchas ventajas de los microservicios son muy obvias, pero la complejidad correspondiente a todo el sistema también es muy significativa. Después de que el sistema monolítico se distribuye, problemas de red, cómo el servicio encuentra y accede al extremo opuesto, problemas de descubrimiento del servicio, problemas de protección de acceso a la red tolerante a fallas, etc. Incluso la ubicación del problema más simple que se puede lograr a través de la pila de llamadas en el registro, los microservicios deben ser compatibles a través de una cadena de llamadas distribuida. ¿Cómo resolver estos desafíos que traen los microservicios?
El SDK de microservicio solía ser una solución común. Las capacidades universales de los microservicios están encapsuladas en un marco de desarrollo. Los desarrolladores usan este marco para desarrollar y escribir su propio código comercial, y los microservicios generados naturalmente tienen estas capacidades integradas. Durante un largo período de tiempo, este formulario es la configuración estándar de la gobernanza de microservicios, por lo que los principiantes piensan que solo estos SDK son microservicios.
La red de servicios proporciona capacidades de gobernanza de otra forma. A diferencia del enfoque SDK, las capacidades de gobernanza del servicio se proporcionan en un proceso de agente independiente, que está completamente desvinculado del desarrollo. Aunque la diferencia entre los dos es muy pequeña en la imagen, analizaremos la diferencia en los conceptos de diseño entre los dos de la arquitectura y los casos reales para entender que el primero es un marco de desarrollo y el segundo es una infraestructura.
En forma de SDK, Spring Cloud es el proyecto representativo más influyente. Spring Cloud proporciona un conjunto de herramientas de desarrollo para crear aplicaciones distribuidas, como se muestra en la lista. Entre ellos, la mayoría de los desarrolladores están familiarizados con proyectos relacionados con microservicios, como: descubrimiento de registro de servicios eureka, configuración de administración de configuración, cinta de equilibrio de carga, fusión de Hystrix tolerante a fallas, detective de punto enterrado de cadena de llamadas, gateway zuul o gateway de nube Spring y otros proyectos . La nube de Spring mencionada en este intercambio también se refiere específicamente al kit de desarrollo de microservicios de Spring Cloud.
En forma de cuadrícula, el proyecto más influyente es Istio. Este diagrama de arquitectura de Istio aparecerá con frecuencia en este discurso. Como trasfondo de este intercambio, solo necesitamos saber que la arquitectura consta de un plano de control y un plano de datos, el plano de control gestiona los servicios en la red y varias reglas para la configuración del servicio. En el plano de datos, el tráfico entrante y saliente entre cada servicio será interceptado por el proxy del plano de datos del mismo POD que el servicio y realizará acciones de gestión del tráfico.
Además de la arquitectura, como otra parte del fondo, elegimos dos funciones básicas para abrir un poco para ver las similitudes y diferencias en el diseño e implementación de las dos. El primero es el descubrimiento de servicios y el equilibrio de carga.
A la izquierda está la nube de Spring. Todos los microservicios se registrarán en el centro primero, generalmente Eureka realiza el registro del servicio, y luego, cuando se accede al servicio, el consumidor va al registro para el descubrimiento del servicio para obtener la lista de instancias del servicio de destino. para acceder y utiliza la cinta de equilibrio de carga del lado del cliente. Seleccione una instancia de servicio para iniciar el acceso.
Istio a la derecha no requiere el proceso de registro del servicio. Solo necesita obtener la relación entre el servicio y la instancia desde la plataforma en ejecución k8s. Cuando se accede al servicio, el proxy del plano de datos Envoy intercepta el tráfico y selecciona un destino instancia para enviar la solicitud. Se puede ver que el equilibrio de carga del cliente se basa en los datos de descubrimiento de servicios. La diferencia es que el origen de los datos de descubrimiento de servicios es diferente y el cuerpo de ejecución del equilibrio de carga es diferente.
Lo siguiente compara el fusible:
A la izquierda está el diagrama de transición de estado clásico de Hystrix. Si el número de errores consecutivos supera el umbral durante un período de tiempo, la instancia entra en el estado fusible y no acepta la solicitud; después de un período de aislamiento, migrará del estado fusible al estado semifusible. Si es normal, entrará en el estado de fusible desactivado y se podrá recibir la solicitud; si no es normal, todavía entrará en el estado de fusible abierto.
Aunque Istio no proporciona dicho diagrama de estado, todos los que estén familiarizados con las reglas y comportamientos de Istio deberían encontrar que las reglas de umbral de OutlierDection en Istio también están diseñadas de esta manera. La diferencia entre los dos es que el disyuntor de Spring Cloud lo ejecuta Hystrix en el SDK y el proxy del plano de datos en Istio. Hystrix permite a los usuarios realizar cierto control mediante la programación en el código comercial.
El análisis anterior muestra que las capacidades y los mecanismos de descubrimiento de servicios, equilibrio de carga y fusión son similares. Si ignora algunos detalles en el diagrama, el modelo de diagrama de bloques es exactamente el mismo a primera vista. Generalmente, solo hay un elemento en la tabla de comparación que indica que la posición de ejecución es diferente. Esta diferencia trae una gran diferencia en las aplicaciones prácticas.
Problemas encontrados al usar el marco de microservicio de Spring Cloud
El enfoque de este discurso es la práctica. Los siguientes son algunos de los problemas que nuestros clientes han encontrado en nuestro TOP, y analizamos qué problemas encuentran los usuarios al usar frameworks de microservicios tradicionales, la mayoría de ellos son las mayores motivaciones para que elijan grids.
1) Problemas multilingües
En el desarrollo de aplicaciones empresariales, es muy razonable y común que una empresa utilice un marco de desarrollo unificado. Para mejorar la eficiencia, muchos equipos de desarrollo suelen mantener el marco de desarrollo general de su propia empresa o equipo. Por supuesto, debido a que la mayoría de los sistemas comerciales se desarrollan en base a Java, el marco de desarrollo de la nube de Spring o varios marcos de desarrollo derivados de la nube de Spring son particularmente utilizados.
Pero en el escenario nativo de la nube, el negocio es generalmente más complejo y diverso, especialmente cuando se trata de muchos sistemas existentes. No podemos exigir que un conjunto de servicios maduros que se utilizarán para microservicios se reescriba con Spring Cloud. Los usuarios tienen muchas esperanzas de que haya una manera de administrar el acceso al servicio de la capa de aplicación sin tener que reescribir el sistema original.
2) La ejecución de microservicios en la nube de Spring en K8 tendrá una alta probabilidad de descubrimiento de servicios inoportuno
Como se mencionó anteriormente, el descubrimiento del servicio en la nube de Spring se implementa en función de los datos que cada microservicio registra primero en el registro. En el escenario tradicional de la nube de Spring, cuando el microservicio se implementa en la VM, los requisitos de cambio dinámico del servicio no son tan altos, en la mayoría de las instancias individuales no se están ejecutando correctamente y la verificación de estado a través del descubrimiento de servicios es suficiente. Pero en el escenario k8s, la migración dinámica de instancias de servicio es un escenario muy normal. Como se muestra en la figura, un determinado Pod del productor se ha migrado de un nodo a otro. En este momento, la instancia de productor del nuevo pod2 debe registrarse con eureka y la instancia anterior Pod1 debe registrarse.
Si esto sucede con frecuencia, los datos del centro de registro no se mantienen de manera oportuna, lo que da como resultado el descubrimiento de servicios y el equilibrio de carga en la instancia anterior pod1, lo que provocará fallas de acceso.
3) Actualice todas las aplicaciones para hacer frente a los cambios en los requisitos de gestión de servicios.
La tercera pregunta es una pregunta más típica. El cliente tiene un equipo público dedicado a mantener un conjunto de su propio marco de desarrollo basado en Spring Cloud. Cada vez que se actualiza el marco de desarrollo, el cliente debe solicitar al equipo comercial que actualice sus propios servicios. El SDK en sí a menudo se modifica y prueba sin mucha carga de trabajo, pero se requiere un plan de actualización a largo plazo para recompilar, empaquetar y actualizar miles de servicios desarrollados en base a este SDK y, a menudo, debe acompañar al equipo de negocios durante el cambio nocturno. Debido a que el equipo de negocios no ha realizado ningún cambio, considerando la carga de trabajo y los riesgos en línea provocados por esta actualización, generalmente no hay motivación.
4) Migración de una arquitectura monolítica a una arquitectura de microservicio
Este es un problema relativamente común, es decir, microservicios graduales. Martin Fowler también mencionó en su famoso artículo sobre la separación de monolíticos a microservicios (https://martinfowler.com/articles/break-monolith-into-microservices.html) cómo la iniciativa de microservicios progresivos puede ser Desde la perspectiva empresarial, una las grandes empresas se dividen, desacoplan y luego, gradualmente, se micro-servicios. Martin Fowler enfatizó que "el desacoplamiento es capacidad empresarial, no código". El gran dios dejó el desacoplamiento del código al desarrollador.
Pero desde la perspectiva de los desarrolladores, no es fácil hablar de microservicios progresivos. Tomando como ejemplo el desarrollo de microservicios basados en el marco de la nube de Spring, para poder realizar un descubrimiento de servicios unificados, balanceo de carga, consumo y ejecución de la misma estrategia de gobernanza entre todos los microservicios, es necesario requerir que todos los microservicios estén basados en el mismo o incluso una versión unificada del SDK para desarrollar.
Por supuesto, nuestros clientes también se adaptan en función del nivel de API en este caso, coexistiendo los originales no orientados a microservicios y orientados a microservicios.Utilizando este método similar de escala de grises, la operación real es muy problemática.
Una vez un cliente preguntó si no hay necesidad de molestarse en hacer dos conjuntos, si es posible transformar directamente algunos monómeros grandes en microservicios, y otros monómeros no se moverán en absoluto durante mucho tiempo, hasta que haya tiempo o cuando piensen es seguro moverlo.
solución
Para los cuatro problemas típicos del marco de microservicios que los clientes realmente encuentran, las soluciones que recomendamos son todas las redes de servicios. Echemos un vistazo a cómo resuelve Istio los problemas anteriores.
Primero, la cuestión del multilingüismo. Con base en la cuadrícula de servicios, los planos de datos empresariales y de gobierno no necesitan ejecutarse en el mismo proceso, ni necesitan compilarse juntos, por lo que no hay un lenguaje ni un marco vinculante. Independientemente del idioma en el que se desarrolle el servicio, siempre que exista un puerto en un determinado protocolo de aplicación al que se pueda acceder y administrar externamente, el grid puede administrarlo. A través del plano de control de la red unificada, las reglas de gobernanza unificada se envían al plano de datos de la red unificada para su ejecución y se llevan a cabo acciones de gobernanza unificadas, incluida la escala de grises, el tráfico, la seguridad, la observabilidad, etc.
Respecto al problema del registro y descubrimiento inoportunos del servicio original cuando el servicio en la nube de Spring se está ejecutando en Kubernetes. La causa principal es la inconsistencia causada por los dos conjuntos de descubrimiento de servicios, por lo que la solución es relativamente simple y el descubrimiento de servicios unificado es suficiente. Dado que K8s ha mantenido el servicio y los datos entre instancias al mismo tiempo que la programación del Pod, no es necesario crear un mecanismo de servicio de nombres por separado, y es necesario registrar laboriosamente el servicio y luego descubrirlo.
Al comparar la imagen encontrada por el registro de Spring Cloud, el centro de registro desapareció y las acciones de registro de servicio y descubrimiento de servicio basadas en el centro de registro ya no son necesarias. Istio usa directamente los datos de descubrimiento de servicio de k8s, pero también es mucho más simple en términos de arquitectura.
También hemos resumido que la mayoría de los escenarios que encontraron este problema se encontraron al migrar el marco de microservicio de VM a k8s. Un poco de usar el contenedor como la VM anterior, solo k8s se usó como plataforma para la implementación y operación del contenedor. Y el servicio k8s no se utiliza.
La solución al problema de que el propio SDK se ha actualizado para volver a actualizar todas las empresas es desacoplar las capacidades públicas de gobernanza de servicios de la empresa. En la red, después de hundir las capacidades de gobernanza en la infraestructura, el desarrollo empresarial, la implementación y las actualizaciones se desacoplan de la infraestructura de gobernanza del servicio. Los desarrolladores de negocios se enfocan en sus partes comerciales. Siempre que no se modifique el código comercial, no es necesario volver a compilarlo y conectarse en línea.
Cuando se actualiza la capacidad de gobierno, solo se requiere la actualización de la infraestructura, y la actualización de la infraestructura no tiene ningún impacto en el negocio del usuario. La mayoría de los proveedores de servicios de red como Huawei Cloud ASM pueden realizar actualizaciones con un solo clic, y los usuarios desconocen por completo este proceso.
En cuanto al problema de los microservicios progresivos, el uso de la malla de servicios Isito puede ser una solución perfecta. Istio gobierna el acceso entre servicios, siempre que un servicio sea accedido por otros servicios, se puede administrar a través de Istio, ya sea un microservicio o un monolito. Una vez que Istio se hace cargo del tráfico del servicio, tanto los monolitos como los microservicios pueden recibir reglas unificadas para una gestión unificada.
Como se muestra en la figura, en el proceso de microservicios, se puede priorizar una sola aplicación svc1 para microservicios basados en la división del negocio y dividirla en tres microservicios svc11, svc12 y svc13. Otra aplicación única de la que svc1 depende La aplicación del cuerpo svc2 puede administrarse como los otros tres microservicios cuando se ejecuta en la cuadrícula sin ningún cambio. Además, después de ejecutarse durante un período de tiempo, el servicio svc2 se puede micro-mantener de acuerdo con sus propias necesidades comerciales. Para evitar en la medida de lo posible la carga de trabajo y los riesgos de migración empresarial provocados por una refactorización importante, y lograr realmente la práctica de microservicios graduales propugnada por Martin Fuller.
práctica
Las anteriores son soluciones a varios problemas típicos de los clientes en el trabajo real. En la práctica, ¿cómo implementar estas soluciones? El siguiente es un resumen basado en casos reales de clientes para compartir prácticas específicas.
Nuestra idea principal es desacoplar y desinstalar. Desinstale las funciones no desarrolladas en el SDK original. El SDK solo proporciona funciones de desarrollo como marcos de código y protocolos de aplicación. Todo el contenido relacionado con la gobernanza de microservicios se descarga a la infraestructura.
Se puede ver en la figura que los desarrolladores están expuestos a la reducción del marco de desarrollo, y el costo de aprendizaje, uso y mantenimiento para los desarrolladores también se ha reducido en consecuencia. La infraestructura se ha vuelto más pesada. Además de completar las capacidades básicas de las operaciones de servicio que deben realizarse antes, también incluye capacidades de gobernanza de servicios no intrusivas. Cada vez más capacidades que antes se consideraban comerciales se perfeccionarán en capacidades generales, se entregarán a la infraestructura para hacerlo y se entregarán a los proveedores de la nube para que lo hagan. Los clientes pueden deshacerse de estas tediosas tareas no comerciales y dedicarse más tiempo y energía para el negocio Innovación y desarrollo. Bajo esta división del trabajo, el SDK realmente vuelve a la función fundamental del marco de desarrollo.
Para utilizar las capacidades de la cuadrícula, la premisa es que el tráfico de los microservicios puede ir al plano de datos de la cuadrícula. El trabajo de migración principal está en el llamador del servicio del microservicio. Recomendamos 3 pasos:
Paso 1: abandone el registro de microservicios original y use el servicio K8S.
Paso 2: cortocircuite la lógica del descubrimiento de servicios y el equilibrio de carga en el SDK, y use directamente el nombre del servicio y el puerto de k8s para acceder al servicio de destino;
Paso 3: de acuerdo con las necesidades de su propio proyecto, use gradualmente las capacidades de gobernanza en la cuadrícula para reemplazar las funciones correspondientes provistas en el SDK original. Por supuesto, este paso es opcional. Las funciones originales, como el punto de inserción de la cadena de llamadas, pueden También se puede utilizar para cumplir con los requisitos. Está reservado como función propia de la aplicación.
Para lograr la migración anterior, tenemos dos métodos para diferentes escenarios de usuario.
Una es solo modificar la configuración: además de admitir el descubrimiento de servicios en el servidor basado en Eureka, Spring Cloud también puede configurar una dirección de instancia de servicio estática para Ribbon. Utilice este mecanismo para configurar el nombre del servicio de Kubernetes y el puerto del servicio en la dirección de la instancia de back-end del microservicio correspondiente.
Cuando todavía se accede al nombre del microservicio del servidor original en el marco de la nube de Spring, la solicitud se reenviará al servicio y al puerto de k8s. De esta manera, el acceso será interceptado por la superficie de datos de la cuadrícula y llegará a la superficie de datos de la cuadrícula. El equilibrio de carga del descubrimiento de servicios y varias reglas de tráfico se pueden aplicar a las capacidades de la red.
Este método realmente conecta el enlace de acceso del SDK y el enlace de acceso del plano de datos de la cuadrícula con una modificación mínima. Cuando se usa en la plataforma, la herramienta de la línea de ensamblaje se puede usar para ayudar a reducir la carga de trabajo y los errores de operación de modificar directamente el archivo de configuración. Puede ver que en mi proyecto real, solo se modifica el archivo de configuración application.yaml del proyecto, y los otros códigos son todos cero modificaciones. Por supuesto, se puede utilizar la misma modificación semántica para la configuración basada en la anotación.
El método anterior tiene relativamente pocas modificaciones al proyecto original, pero las dependencias del proyecto de Spring Cloud todavía están ahí.
Algunos de nuestros clientes eligieron otro método más simple y directo Dado que el equilibrio de carga de descubrimiento de servicios en el SDK original, incluidas varias capacidades de gobierno de servicios, no es necesario, todas estas dependencias simplemente se eliminan. A juzgar por el tamaño del espejo final, el volumen de todo el proyecto también se ha reducido considerablemente. De esta manera, los clientes realizan varios ajustes de acuerdo con su uso real y, al final, la mayoría de ellos degeneran Spring Cloud en Spring Boot.
Hay otra parte especial de la migración, que es la puerta de enlace para el acceso externo a los microservicios.
Spring Cloud tiene dos puertas de enlace con funciones similares, Zuul y Spring Cloud Gateway. Según el descubrimiento de servicios de Eureka, los microservicios internos se asignan a servicios externos y se proporcionan capacidades como la seguridad y la distribución en la entrada. Al cambiar a k8s e Istio, al igual que los servicios internos, el descubrimiento de servicios de cada servicio en la entrada se migra a k8s.
La diferencia es que si los usuarios desarrollan muchos filtros privados relacionados con la empresa en Gateway, Gateway es en realidad el servicio de fachada de los microservicios. Para la continuidad del negocio, la solución puede tratarse directamente como microservicios ordinarios e implementarse en Internet. Gestión en el cuadrícula.
Pero en la mayoría de los casos, recomendamos usar la puerta de enlace de entrada de Istio para reemplazar directamente esta puerta de enlace de microservicio para proporcionar terminación TLS externa, limitación de corriente y capacidades de segmentación de tráfico de una manera no intrusiva.
Después de las simples transformaciones anteriores, los servicios desarrollados en varios lenguajes y varios marcos de desarrollo se pueden administrar de manera uniforme a través de Istio siempre que los protocolos comerciales estén conectados, puedan acceder entre sí y el protocolo de acceso pueda ser administrado por la red.
Las reglas de administración de servicios unificadas se pueden configurar en la superficie de control. En el lado de los datos, Envoy se utiliza de manera uniforme para el descubrimiento de servicios, el equilibrio de carga y otro tráfico, seguridad, observabilidad y otras capacidades relacionadas. Los servicios en el plano de datos pueden ejecutarse en contenedores o en máquinas virtuales. Y puede ejecutarse en varios clústeres de k8s.
Por supuesto, en medio del proceso de migración, también apoyamos la retención por fases del registro del marco de microservicio original, de modo que Istio se pueda combinar con otro descubrimiento de servicios para usar el estado intermedio, de modo que los servicios en la red puedan acceder a los servicios del registro de microservicios.
A continuación, se muestra un ejemplo de un servicio desarrollado por Spring Cloud que se ejecuta en la cuadrícula de servicios de Istio para la publicación en escala de grises. El registro anterior es el registro de la persona que llama al servicio Sidecar. Puede ver que la cuadrícula distribuye el tráfico a diferentes backends de servicio. La siguiente captura de pantalla usa la función de escala de grises del servicio Huawei Cloud ASM. Puede ver que este servicio en la nube Spring distribuye el 30% del tráfico a la versión en escala de grises a través de la estrategia de derivación configurada por la cuadrícula.
El siguiente ejemplo es un servicio desarrollado por Spring Cloud que utiliza la función de disyuntor de Istio. Este proceso es la práctica del diagrama de transición de estado de Hystrix en la sección de principio anterior, la diferencia es que esta implementación se basa en Istio. Basado en la red de servicios, no importa en qué idioma o marco se desarrolle el servicio, el acceso puede protegerse mediante fusibles.
La captura de pantalla del efecto aquí es de la topología de la aplicación de Huawei Cloud Application Service Grid ASM. Puede ver el nivel de servicio, los cambios de tráfico del nivel de instancia de servicio y el estado de salud del servicio y la instancia de servicio de manera muy refrescante, lo que muestra que la nube de Spring falló instancia está aislada Todo el proceso. En el diagrama de topología, se puede ver que una instancia alcanza el umbral del fusible de manera anormal y el fusible se dispara. Los datos de la red distribuyen el tráfico a esta instancia defectuosa disminuyendo gradualmente hasta que no hay tráfico en absoluto, es decir, la instancia defectuosa es aislado. A través de esta protección de fusible, se garantiza la tasa de éxito del acceso al servicio general.
Las siguientes tres topologías de tráfico demuestran el proceso de recuperación de fallas.
puede ser visto:
- En el estado inicial, esta instancia de falla está aislada y no hay tráfico;
- Cuando la instancia en sí es normal, el plano de datos de la cuadrícula intenta asignarle tráfico nuevamente después de aislarla durante el intervalo configurado. Cuando se cumplen los requisitos del umbral, la instancia se considerará como una instancia normal y puede recibir solicitudes como las otras dos instancias.
- Por último, puede ver solicitudes de procesamiento equilibradas en las tres instancias.
- Es decir, se logra la recuperación de fallas.
Finalmente, resuma el contenido de hoy a través de los diagramas de relación de microservicios, contenedores, k8s e Istio:
- Tanto los microservicios como los contenedores tienen las mismas características de ligereza y agilidad, y los contenedores son un entorno operativo muy adecuado para los microservicios;
- En el escenario nativo de la nube, en el escenario de microservicios, los contenedores nunca existen de forma independiente, y ya es un estándar de facto usar k8 para organizar contenedores;
- La estrecha integración de Istio y k8s en escenarios de arquitectura y aplicación juntos proporciona una plataforma de gobierno y operación de microservicio de extremo a extremo.
- También es nuestra solución recomendada El uso de Istio para la gobernanza de microservicios se está convirtiendo en una opción tecnológica para cada vez más usuarios.
Las cuatro relaciones anteriores se combinan en el sentido de las agujas del reloj para construir un ciclo cerrado completo para nuestra solución.
Adjunto
Ya en 2018, HUAWEI CLOUD tomó la iniciativa en el lanzamiento del primer servicio comercial de Istio-Application Service Mesh (ASM) del mundo. HUAWEI CLOUD Application Service Mesh es una red de servicio totalmente administrada, de alto rendimiento y muy confiable y fácil de usar admite múltiples infraestructuras, como máquinas virtuales y contenedores, y admite la gestión unificada de servicios de múltiples clústeres y múltiples nubes entre regiones. Proporcione a los usuarios gestión del flujo de servicios, supervisión de la operación del servicio, seguridad de acceso al servicio y capacidades de publicación de servicios en forma de infraestructura.
En la actualidad, Huawei Cloud Application Service Grid ha prestado servicios a casi mil clientes en múltiples industrias como Internet, automóviles, manufactura, logística y gobierno, satisfaciendo las demandas comerciales de clientes en diferentes industrias. HUAWEI CLOUD convertirá la rica experiencia acumulada en este proceso en código y contribuirá a la comunidad de Istio, que ha promovido en gran medida la madurez de la tecnología Istio y el rápido desarrollo de la comunidad. Al mismo tiempo, Huawei Cloud también ha invertido mucho en la evangelización técnica de las redes de servicios y ha promovido la difusión y popularización de la tecnología de las redes de servicios a través de varios métodos, como foros comunitarios, conferencias técnicas, transmisiones de video en vivo y libros profesionales.
Haga clic para seguir y conocer la nueva tecnología de Huawei Cloud por primera vez ~