Service Mesh es un nuevo enfoque de microservicio popular en los últimos dos años, y también se han producido una gran cantidad de implementaciones de Service Mesh representadas por Istio.
image.png
Sobre la base de las necesidades comerciales reales, Weibo ha creado y abierto su propio Weibo Mesh, y ya ha implementado negocios clave internos a gran escala.
Este artículo explicará Weibo Mesh en detalle a partir de las siguientes partes, con la esperanza de brindarle algo de inspiración en la dirección del servicio y servir mejor a su propio negocio:
Desafío del servicio de Weibo
Nuevas ideas orientadas al servicio
Introducción a la solución Weibo Mesh
Práctica de producción
para resumir
Desafío del servicio de Weibo
image.png
En primer lugar, presentaré los desafíos que enfrenta Weibo como servicio. Weibo tiene una forma especial. Excepto por el alto tráfico en el mediodía / noche normal, los eventos calientes repentinos son más letales.
Cuando ocurre un evento caluroso, el tráfico se ha disparado en muy poco tiempo y, a menudo, el evento estalla sin ninguna señal. Esto ha traído grandes desafíos a la servitización y estabilidad de Weibo.
Si uno de los enlaces está inactivo y no se puede detectar y responder a tiempo, es muy probable que provoque un tiempo de inactividad por avalancha y que todo el sitio se cuelgue.
Entonces, ¿cómo solucionar este problema? En primer lugar, pienso en la construcción automática de expansión / reducción, pero ¿en qué confiamos para la toma de decisiones? ¿Cómo cumplir con los requisitos de observabilidad del sistema y cómo evaluar la disponibilidad y redundancia del sistema?
En esencia, la construcción de la gobernanza del servicio del sistema es muy importante y afectará directamente la disponibilidad del servicio. Sin embargo, la diversidad de las pilas de tecnología de Weibo ha causado dificultades en los microservicios y la gobernanza del servicio.
Desde una perspectiva técnica, la llamada de servicio típica de Weibo es aproximadamente como se muestra en la figura anterior. El sistema empresarial llamará a múltiples interfaces del sistema de la plataforma, como la obtención de contenido de Weibo a través de la interfaz de la plataforma.
El sistema de plataforma es principalmente la pila de tecnología Java, y hay muchas soluciones relacionadas con los microservicios. Además del tiempo de servicio inicial, el sistema de microservicio de la plataforma es relativamente completo. Al mismo tiempo, se han producido algunos marcos de código abierto excelentes, como el marco de microservicio de Motan. .
La pila de idiomas del lado comercial: diversificada, básicamente cubre todos los lenguajes principales, entre los cuales el tráfico del sistema relacionado con PHP representa una cantidad relativamente grande.
Enlace de llamada: normalmente, la empresa y la plataforma utilizan la API RestFul para interactuar. Una llamada de solicitud tiene que pasar por las capas 4 y 7 de programación. La estabilidad del servicio a menudo se ve afectada por la fluctuación de la red y la inestabilidad del DNS. El consumo en la capa intermedia no puede ignorarse.
Además, la amplia variedad de idiomas en los departamentos comerciales conduce indirectamente a una construcción desigual de los sistemas de microservicios en varios departamentos.
La respuesta a los picos de tráfico requiere la asistencia y la vinculación de todos los módulos comerciales de todos los departamentos. Prueba la solidez de todo el sitio. Necesitamos que todos los módulos tengan capacidades de gobierno de servicio de alto nivel. Por lo tanto, necesitamos resolver urgentemente el problema de los microservicios entre idiomas.
image.png
La figura de arriba es el diagrama de soporte del sistema de microservicio dentro de la plataforma Weibo. La plataforma implementa un sistema de gobernanza de microservicio con el marco de Motan como núcleo.
Además, también hay un centro de registro Vintage de desarrollo propio, una plataforma de programación flexible inteligente Open DCP y una plataforma de monitoreo en tiempo real Graphite. Se puede ver que la arquitectura de microservicio de la plataforma es totalmente compatible con DevOps.
La tendencia general en la industria es nativa de la nube. Como parte importante de la tecnología nativa de la nube, los microservicios son lo que debemos superar.
Nuevos pensamientos sobre el servicio Weibo
Intentos de gobernanza de servicios en varios idiomas
Para resolver el problema de la gobernanza del servicio en varios idiomas, presentaré brevemente las soluciones que hemos probado.
Aquí hay un gran trasfondo. Debido a que Motan es un marco excelente que se ha utilizado internamente para Weibo durante mucho tiempo, se ha sometido a pruebas importantes y ha sido de código abierto, ha acumulado mucha experiencia excelente en el gobierno del servicio, por lo que debemos considerar plenamente la existencia de Motan en la transformación de nuestro servicio.
Intentamos adaptar Motan al protocolo RPC de PHP como Yar. PHP puede comunicarse con Java en el lado del servidor, pero PHP no puede realizar el descubrimiento de servicios.
Así que agregamos un programa Daemon junto a PHP y también consideramos usar Nginx para el descubrimiento de servicios.
Por supuesto, el problema también es obvio. Tal transformación conducirá a una mayor intrusión comercial, mayores costos y menor escalabilidad. Además, no resuelve el problema de gobierno de servicios de PHP como servidor.
También hemos probado GRPC, por supuesto, las llamadas en varios idiomas se pueden resolver, pero hay varios problemas aquí, uno es cómo realizar la gobernanza del servicio y el otro es la serialización PB.
Debido a que la estructura de contenido de la escena de Weibo es muy grande y la eficiencia no es más alta que la de Json, los cambios comerciales conducen a cambios en los archivos PB que hacen que los costos de actualización y mantenimiento sean inaceptables, y los datos serializados encuentran problemas y la depuración se vuelve difícil.
Además, la diversidad de la pila tecnológica también provocará una serie de problemas. Incluso si resolvemos el problema de llamar desde PHP a Java. Pero la misma función de gobernanza no puede volver a realizarse en diferentes idiomas.
La experiencia de gobernanza del servicio acumulada por el marco de Motan es algo que debemos heredar y llevar adelante ¿Cómo equilibrar estos problemas y soluciones?
La naturaleza del servicio multilingüe
image.png
Creo que la esencia del servicio en varios idiomas se puede resumir en dos puntos:
Interacción de datos
Gobernanza del servicio
El diseño de interacción de datos debe considerar la neutralidad entre idiomas y protocolos, y el diseño de gobernanza del servicio debe ser flexible, completo y escalable.
image.png
En la figura anterior, enumeré las ventajas y desventajas del enfoque de servicio en varios idiomas:
El proxy HTTP tradicional puede resolver llamadas entre diferentes servicios. HTTP es una puerta de enlace tradicional, que es más fácil de implementar, pero debido a que todos tienen que agregar una puerta de enlace para llamadas internas, esto aumenta el enlace y da como resultado una baja escalabilidad.
Módulo RPC o Agente. Hay muchos frameworks RPC en la industria, la mayoría de las pilas de Java tienen funciones completas, pero el costo del mantenimiento entre lenguajes es muy alto.
Agente es una idea nueva. El costo de investigación y desarrollo, el costo de mantenimiento y el costo de uso del agente están relativamente comprometidos. Es decir, tenemos un agente independiente para resolver los problemas del servicio multilingüe.
De esa manera, no solo puede liberar la presión tradicional del gobierno del servicio del lado empresarial, sino que también hereda la esencia del marco de Motan, sin la necesidad de implementar una lógica de gobierno del servicio multilingüe, y permite que la empresa y el agente se desarrollen de forma independiente el uno del otro.
Esta idea finalmente evolucionó hasta convertirse en Weibo Mesh de hoy:
image.png
A partir de ahí, Weibo pasó a Service Mesh. El movimiento de Weibo hacia Service Mesh no se está poniendo al día ciegamente con las últimas tendencias tecnológicas.
Nos basamos en el status quo, en la resolución de problemas comerciales reales, y después de una exploración paso a paso, descubrimos que la solución final coincide con la idea de Service Mesh. Desde un lado, también verifica la racionalidad y la naturaleza prospectiva de Service Mesh para resolver el problema orientado al servicio.
image.png
En la figura anterior, podemos utilizar el método de descomposición ortogonal para comprender Service Mesh. Se puede ver que el microservicio original se divide en una capa de lógica empresarial y una capa de gestión de interacción de servicios. La capa de gestión de interacción de servicios se abstrae como Service Mesh.
Service Mesh desacopla la lógica de interacción y gobernanza entre los servicios del negocio, abstrayéndolo de forma independiente en un módulo de procesamiento especial.
Por lo general, el agente de malla se implementa localmente en forma de sidecar y servicios. El agente (en adelante, el agente de malla se denomina malla o agente) puede entenderse como la capa de infraestructura del servicio. La empresa no necesita preocuparse por los detalles de interacción / gobernanza entre los servicios, y todos son manejados por el agente.
Service Mesh trae un cambio en la idea de la arquitectura de microservicios, que aporta muchas ventajas arquitectónicas al desarrollo empresarial. El agente y la empresa pueden desarrollarse de forma independiente. Por lo general, el agente se entrega a la gestión de operaciones y mantenimiento, y el desarrollo empresarial se transfiere a la línea de negocio, por lo que el Puede lograr un desarrollo continuo y una integración continua.
La idea de Mesh no solo puede resolver el problema del servicio en varios idiomas, sino también resolver el problema del servicio de recursos, y estas transformaciones son básicamente transparentes para el lado empresarial.
Introducción a la solución Weibo Mesh
La siguiente es una introducción específica a la implementación de Weibo Mesh. La imagen de arriba es el diagrama de la arquitectura de la malla de Weibo. Además del agente de malla necesario, considerando la migración comercial y las necesidades reales de aterrizaje, se agrega un cliente entre el código comercial y la malla.
Este cliente es muy ligero y su función principal es encapsular las solicitudes de Mesh, lo que facilita que la empresa realice llamadas Mesh y minimice el costo de la migración empresarial.
De hecho, también implementamos algunas otras funciones favorables a los negocios en el Cliente y, al mismo tiempo, mejoramos la función de llamada Mesh.
Por ejemplo, puede realizar serialización en varios idiomas, conmutación por error de malla, múltiples solicitudes y control de tiempo de espera en el cliente.
Por supuesto, diferentes partes comerciales pueden personalizar funciones. El cliente está escrito en el mismo idioma que la empresa y su objetivo principal es ayudar a la migración empresarial sin problemas.
La capa Mesh implementa las funciones principales de Service Mesh, incluido el descubrimiento, la interacción, el enrutamiento y la gobernanza.
Weibo Mesh está implementado por Go, y Go también implementa la mayoría de los planos de datos Mesh de los principales fabricantes nacionales.
Go tiene un rendimiento excelente y facilidad de uso, y es un lenguaje muy respetado en la era de la nube. En el futuro, es muy probable que la capa Mesh se combine con el contenedor y se convierta en una capa de infraestructura del contenedor.
Plano de datos Weibo Mesh
Analizar un servicio Service Mesh, generalmente a través del plano de datos y el plano de control. Primero observe el rendimiento de Weibo Mesh en el plano de datos, que contiene cinco módulos principales:
Clúster (administración de clústeres), la administración abstracta de la lista de nodos descubierta a través del servicio bajo el grupo.
HA (estrategia de alta disponibilidad), LB (equilibrio de carga).
El punto final (abstracción del nodo de servicio) es esencialmente IP y puerto, pero desde el nivel de código, es una abstracción del nodo de servicio. Las llamadas directas se pueden realizar a través del punto final, que puede entenderse como una unidad de llamada.
Protocolo (Motan2 / Protocolo de transmisión + Protocolo simple / Serialización).
Estos módulos se presentan uno por uno a continuación.
①Módulo de clúster
La persona que llama solicita pasar a través de la malla local. En el procesamiento del módulo de clúster, primero pasa a través de una serie de cadenas de filtros granulares de clúster (cadena de filtros, incluida la métrica del clúster, fusible, interceptación, autenticación, conmutación de paquetes y otras funciones; se llevan a cabo en una estructura de cadena Organizar llamadas, admitir la expansión de la función de filtrado arbitrario).
Luego, mediante la estrategia de alta disponibilidad y la estrategia de balanceo de carga, se filtra un Endpoint disponible. En el Endpoint, se llevará a cabo una cadena de filtrado de granularidad de solicitudes (registros de registro de una sola máquina, métricas, etc.). La solicitud se serializa y ensambla de acuerdo con el protocolo de transmisión. Finalmente, la solicitud se envía a la malla en el extremo opuesto a través de Endpoint.
②Estrategia de alta disponibilidad
image.png
La estrategia de alta disponibilidad en Weibo Mesh admite estrategias comunes generales, como Failfast, Failover, etc., y el equilibrio de carga admite rondas ponderadas, según rondas de peso, aleatorias y otras estrategias comunes. Por supuesto, también puede personalizar su propia estrategia HA / LB.
La estrategia de alta disponibilidad recomendada en Weibo Mesh es la solicitud de copia de seguridad, también llamada envío dual. El doble disparo se hereda del marco de Motan y es un mecanismo más eficiente y confiable que hemos explorado. Puede resolver eficazmente el problema de la cola larga y, al mismo tiempo, mejorar el rendimiento del sistema.
La solución tradicional al problema del tiempo de espera de la interfaz puede ser reintentar, esperar un tiempo de espera especificado después de que se envía una solicitud y, si no regresa, solicitar otra vez. En el peor de los casos, consumirá 2 veces el tiempo de espera.
Este no es el caso del mecanismo de transmisión dual. Después de enviar una solicitud, espere P90 (el 90% de las solicitudes se pueden devolver dentro de T1, luego P90 = T1, generalmente el P90 del sistema es mucho menor que el tiempo de espera establecido por el programa).
Si la solicitud no regresa, envíe la solicitud nuevamente en este momento. Dentro del período de tiempo de espera, se selecciona la devolución más rápida de las dos solicitudes.
Por supuesto, aquí hay un mecanismo anti-avalancha. Si más de un cierto número de solicitudes (como el 15%) se emiten de forma dual, se considera que hay un problema con el servicio en su conjunto y el problema dual se detiene automáticamente. La práctica ha demostrado que el efecto de eliminación de la cola larga del mecanismo de doble motor es muy obvio.
③Abstracción de nodo
image.png
El punto final es la unidad que llama desde la malla de llamadas hasta la malla de pares. Cuando iniciamos Weibo Mesh, mientras inicializamos el clúster, también inicializaremos el punto final, enlazaremos la cadena de filtros y mantendremos un cierto número de enlaces largos para cada punto final para su selección.
Por supuesto, habrá algunos detalles aquí. Si un nodo no llama y el recuento excede un cierto umbral, el nodo se elimina automáticamente y se realiza una detección regular para esperar la disponibilidad y luego se vuelve a agregar a la lista de nodos disponibles.
④Protocolo de transmisión Motan2
Weibo Mesh sigue el diseño del protocolo de Motan en su conjunto y se ha actualizado.
Motan admite la serialización de Java. En ese momento, considerábamos la comunicación mutua entre Java. Sin embargo, considerando las necesidades de comunicación entre lenguajes y la expansión futura, dividimos el diseño del protocolo en protocolo de serialización y protocolo de transmisión. El protocolo de transmisión es responsable de transmitir los datos serializados, y el protocolo de serialización es la clave para los idiomas cruzados.
El protocolo de transmisión de Motan es un típico de tres etapas:
Encabezamiento
Metadatos
Cuerpo
El encabezado marcará el tipo de serialización y el tipo de mensaje (latido o solicitud normal), y puede definir su propia serialización PB o serialización simple desarrollada por usted mismo.
Habrá algunos nombres de métodos, nombres de atributos y parámetros de usuario en los metadatos; lo que se almacena en el cuerpo es el cuerpo de solicitud / respuesta serializado.
Serialización simple: el diseño simple es relativamente simple y práctico. Actualmente, la serialización simple admite tipos básicos, incluidos Bool, String, Int y Float. Por supuesto, también admite algunos tipos de combinación, como Map, Array, etc., combinados por String y Bool.
En el ejemplo anterior, el tipo es un tipo de datos de bytes, como Bool, String, luego la longitud del byte y luego el flujo de bytes UTF-8. El contenido se puede anidar. A continuación se muestra un ejemplo de anidación.
Proceso de conversión de protocolo: desde el nivel de protocolo, el flujo de solicitud de la malla de Weibo es que la persona que llama llama al cliente a través de una función, y luego pasa por el protocolo de transmisión Motan2 y la serialización simple, y luego pasa a través de la malla local y la capa de malla y luego la reenvía a la malla del extremo opuesto.
La capa superior de la malla de pares puede ser cualquier forma de servicio, como un servicio que no sea RPC, por lo que aquí tenemos un módulo de proveedor que puede proxy servicios de malla de servicio no estándar como HTTP / CGI. Puede exportar estos servicios a un protocolo Motan. Servicio RPC.
El protocolo real del servicio del lado del servidor se bloquea a través del Proveedor. El exterior del proveedor es el servicio de protocolo estándar de Motan, y el interior es el servicio del protocolo original, por lo que para el servidor, el costo de migrar a Weibo Mesh es extremadamente bajo.
Superficie de control de malla Weibo
La superficie de control se divide principalmente en dos aspectos:
① Expansión de la estrategia
Tanto Cluster como Endpoint tienen las correspondientes Cadenas de filtros e implementan estrategias de control de llamadas de diferentes latitudes o granularidades.
La cadena de filtros incluye registros de registro de acceso, métricas, fusiones, limitación de corriente, degradaciones, etc. Un compromiso entre la eficiencia de la llamada y el grado de acoplamiento, todos existen en Weibo Mesh en forma de complementos, y la estrategia de filtro y la secuencia de llamadas también se pueden personalizar libremente.
②Programación de flujo
La programación del tráfico de Weibo Mesh se basa en el registro. El registro no solo proporciona registro y descubrimiento de servicios para Mesh, sino que también proporciona distribución de la configuración del servicio.Cuando Mesh se suscribe al registro, también necesita suscribirse a elementos de configuración relacionados.
Por ejemplo, si enrutamos todo el tráfico desde la sala de computadoras A a la sala de computadoras B, solo necesitamos admitir este comando en Mesh.
Práctica de producción
Escena tipica
La imagen de arriba es el diagrama de distribución general de la puerta de enlace y la malla en la arquitectura de microservicios. Generalmente, la puerta de enlace se configura en el borde del servicio y el nodo de borde controla principalmente el problema de control de programación de flujo a nivel macro.
Internamente, Weibo Mesh se crea entre microservicios para mejorar de manera efectiva la calidad de la comunicación y los requisitos de observabilidad entre servicios.
Consideración del costo de la migración:
Al introducir Service Mesh en escenarios empresariales, es necesario considerar algunos problemas, como si el modelo de implementación empresarial no es de nube, de nube híbrida o nativo de la nube. Al igual que Weibo, es una nube híbrida, con distintos escenarios y por tanto distintas arquitecturas.
Weibo Mesh necesita adaptarse al registro.
Cada idioma debe adaptarse al Cliente. Actualmente, los lenguajes principales como PHP / C ++ / C / Python / Lua son compatibles y Java / Go es compatible de forma nativa.
Adaptarse a la construcción DevOps correspondiente. Necesita soporte de plataforma, como el monitoreo / estadísticas correspondientes, y cualquier transformación de arquitectura debe tener suficiente soporte de DevOps.
A continuación, presentaré la práctica de proxy directo e inverso de Weibo Mesh.
Malla delantera
La imagen de arriba es el proceso de proxy de reenvío en el escenario de Weibo Mesh. El servicio del lado del servidor se registra, la persona que llama se suscribe y la solicitud de la persona que llama pasa a través del Cliente, luego pasa a través de la malla local y finalmente llega a la malla del extremo opuesto. Cabe señalar que la línea punteada es el proceso de conmutación por error.
Si el agente de malla local cuelga, el cliente utilizará la instantánea de nodo devuelta por el servicio para seleccionar los nodos disponibles para llamar para lograr el propósito de la conmutación por error.
Malla inversa
La figura anterior es el proceso de proxy inverso en el escenario Weibo Mesh. Generalmente, nuestro tipo de servicio es HTTP / CGI u otros protocolos propietarios.
Lo más destacado de Reverse Mesh es que no requiere ninguna transformación estructural en el lado del servidor, solo construye Weibo Mesh directamente.
A través del Proveedor, el Agente de Malla exporta los servicios del protocolo original al protocolo Motan2 y lo expone al mundo exterior, solo necesita registrar el servicio exportado en el registro para brindar el servicio.
Al mismo tiempo, no afectará la prestación de servicios originales. Si necesita exportar el protocolo privado al servicio de protocolo Motan2, puede ampliarlo y desarrollarlo usted mismo. La exportación del servicio http / php-cgi es compatible de forma predeterminada.
Características de la malla inversa:
Proporcionar proveedor HTTP / cgi, extensión personalizable.
El marco HTTP se convierte automáticamente a RPC y la empresa no necesita desarrollar un nuevo marco RPC.
Mesh no tiene ninguna intromisión en la transformación del servidor.
para resumir
Diferencias en los modelos de gobernanza
Las llamadas de servicio tradicionales pueden pasar por una puerta de enlace o RPC en el medio. El gobierno del servicio solo puede existir en un extremo, y el gobierno del servicio generalmente se realiza en el lado del servidor.
Sin embargo, el servicio Mesh, debido a la implementación nativa del Agente, encapsula la administración del servicio, que puede realizar la administración bidireccional del lado del Cliente o del lado del Servidor, que es una característica importante del servicio Mesh.
Ventaja de Weibo Mesh
El efecto de combate real es el siguiente:
fd9d6be25a78429b3dd030351921a98a.png
Como puede ver en la figura anterior, la curva RT del lado del cliente del servicio Mesh está cerca de la RT del lado del servidor, lo que muestra que la llamada Mesh punto a punto no tiene pérdida de capa intermedia, junto con los métodos de administración de servicios apropiados, el rendimiento de ambos extremos es relativamente cercano. El servicio HTTP tiene más pérdidas de capa intermedia.
En la imagen de la derecha, puede ver que la curva p999 del lanzamiento dual es relativamente recta, lo que muestra que el lanzamiento dual de la función de corte de cola larga efectiva también mejora indirectamente el rendimiento del sistema.
Clúster de malla de Weibo
En la actualidad, las llamadas entre varias empresas principales en Weibo se han entrelazado y han experimentado eventos importantes y la prueba de la Gala del Festival de Primavera, y el flujo de soporte sigue siendo bastante grande.
Diferencia con Istio
Desde el nivel de control, Weibo Mesh coloca funciones similares a Mixer y CA en Istio en Filters en forma de complementos.
Los servicios de Istio deben descubrirse a través de Pilot, mientras que Weibo Mesh se realiza directamente a través del registro, Istio usa Envoy como Sidecar y hemos creado un nuevo Agent basado en Motan.
Istio tiene una función: cada uno de los módulos anteriores se puede entender como un microservicio, que se puede dividir e implementar de forma independiente.
Sin embargo, Weibo Mesh tiene más acoplamiento enchufable para mayor eficiencia y conveniencia interna, y el rendimiento general será mejor que Istio.
En la figura anterior, puede ver que Istio adapta varias API a través de la plataforma en la nube para el descubrimiento de servicios, y Weibo Mesh es el registro de adaptación.
Istio pone más énfasis en el descubrimiento a nivel de contenedor (yendo directamente a la nube nativa), mientras que Weibo Mesh puede admitir registros comunes como Consul, ZK, etc.
Weibo Mesh intercepta las solicitudes de Mesh a través del Cliente, acoplando modularmente algunas funciones. Cuando es altamente personalizado, el servicio no puede ser completamente transparente. E Istio logra una total inconsciencia empresarial mediante la interceptación del tráfico de IPtables.
WM en curso
Sabemos que a Mesh Agent no le importa qué servicio reenvía el agente, por lo que hay una nueva dirección, es decir, el servicio de recursos, para que también se pueda dar servicio a la capa de almacenamiento de recursos.
La idea de Weibo Mesh de resolver el servicio en varios idiomas también es aplicable al problema de las llamadas entre servicios y recursos. El servicio Weibo tiene muchas dependencias de recursos, como MC, Redis, MySQL, MCQ, etc.
Podemos configurar el Agente en la capa de recursos y también podemos lograr el recurso como servicio, es decir, pan-servicio. En la actualidad, ya tenemos escenarios de uso orientados a servicios de recursos basados en Weibo Mesh.
La dirección de desarrollo futuro de WM
Hay dos direcciones principales para Weibo Mesh en el futuro, una es continuar promoviendo la nube nativa y la otra es continuar puliendo su facilidad de uso.
Weibo Mesh abre la plataforma en la nube y el centro de registro para promover la nube nativa y combina la orquestación de contenedores para complementar las ventajas de cada uno en la gobernanza del servicio.
Además, trabajaremos activamente para integrar Mesh en la capa L5. Continuaremos explorando y resolviendo el acceso inconveniente del lado comercial, como métodos de interceptación de tráfico más convenientes; soporte de idiomas más amplio ...
Weibo Mesh siempre ha abogado por una implementación simple, funciones eficientes y confiables. Con la promoción a mayor escala de Mesh, las escenas se vuelven cada vez más extremas y los requisitos de rendimiento son cada vez más altos. Continuaremos puliendo en esta área. ¡Bienvenidos a todos a unirse a Weibo Mesh!