Por qué Beike, la popular plataforma de vivienda, elige Apache APISIX

Hola, soy Hui Wang, responsable del desarrollo del sistema de puerta de enlace API en Ke Holdings (Beike), una plataforma líder integrada en línea y fuera de línea para transacciones y servicios de vivienda en China. Beike utiliza Apache APISIX como puerta de enlace API en el sistema de producción. Como una empresa impulsada por datos, millones de tráficos de producción pasan diariamente por la puerta de enlace API, y Apache APISIX puede proporcionar un rendimiento estable y sobresaliente. Recientemente, Apache APISIX se unió al incubador de Apache, y me gustaría aprovechar esta oportunidad para compartir la razón por la que elegimos Apache APISIX desde el principio y algunas experiencias mientras lo usamos.

Kong o Apache APISIX

Para los requisitos técnicos de la puerta de enlace, en primer lugar, la puerta de enlace debe tener un rendimiento excelente y la capacidad de soportar el acceso de un tráfico significativo. Además, también debe ser estable, con una tasa de error cero.

El principio de selección de proveedores es reconstruir una versión más estable basada o aprendida de otros proyectos de código abierto para acceder a un tráfico considerable. Después de evaluar los pros y los contras, discutí esta idea con mi supervisor y decidimos iniciar este proyecto. La primera opción que me vino a la mente fue Kong, otra famosa puerta de enlace de código abierto.

Después de navegar por el sitio web oficial de Kong y leer algunos artículos relacionados, pensé que Kong era una opción adecuada, ya que podía satisfacer la mayoría de las necesidades de los usuarios, y el rendimiento también era muy estable. Inmediatamente cloné el código y comencé a leerlo. Sin embargo, me sentí bastante confundido incluso después de varios días de investigación. Supongo que descubrí la razón por la que Kong tiene una base de código tan grande, que es que necesita proporcionar toneladas de funcionalidades.

De repente, varias preguntas rondaron en mi mente. ¿Cuánto tiempo puedo entender completamente Kong? ¿Cuánto tiempo lleva construir un proyecto que cumpla con todos los requisitos? ¿Necesito todas estas funcionalidades que proporciona Kong?

Unos días antes, se lanzó la versión 0.5 de la puerta de enlace API Apache APISIX. Con una actitud de aprendizaje, rápidamente eché un vistazo a este proyecto de código abierto y, sorprendentemente, descubrí que Yuansheng Wang y Ming Wen, dos expertos en el campo de las API, lo desarrollaron juntos. No pude rechazar este producto basado en el respaldo de estos expertos.

Como el proyecto de código abierto nació hace poco, las funcionalidades admitidas por Apache APISIX también son bastante limitadas. Sin embargo, todas las funciones esenciales, como el balanceo de carga dinámico, el cortocircuito, la autenticación de identidad y la limitación de tasa, ya han sido implementadas. Mientras tanto, una base de código relativamente pequeña también reduce el costo de aprendizaje. En comparación con Kong, pude anunciar la victoria de Apache APISIX. Apache APISIX es más adecuado para mi situación actual, ya que podría cumplir con mi plan de características inicial sin preocupaciones por funcionalidades innecesarias.

Sin embargo, el problema más crítico es que el rendimiento de Apache APISIX podría ser un punto débil debido a su tiempo limitado de código abierto. Comparé los resultados de las pruebas de estrés con Kong en el mismo entorno de prueba, y Apache APISIX finalmente venció a Kong. Sin embargo, no es justo para Kong, ya que Kong es mucho más pesado y complejo. Por otro lado, no hay diferencia en mi caso de uso, ya que todas las funcionalidades necesarias están proporcionadas en Apache APISIX. Según el informe de prueba de rendimiento de Apache APISIX, una CPU de un solo núcleo puede alcanzar 24k QPS, mientras que la latencia es de solo 0.7 milisegundos.

En resumen, elegí Apache APISIX por las siguientes razones:

• En la premisa de que puede satisfacer todas las necesidades del proyecto, el costo de aprendizaje de Apache APISIX es bajo
• Kong tiene una base de código grande, lo que dificulta el mantenimiento del código
• Los autores de Apache APISIX son más activos en la comunidad de OpenResty, lo que podría proporcionar una mejor calidad de código
• Lo más importante es resolver rápidamente cualquier pregunta comunicándose directamente con los autores

Las razones para APISIX proporcionadas por el sitio web oficial se muestran en la siguiente figura:

¿Qué capacidades puede proporcionar Apache APISIX?

• Actualizaciones en caliente y complementos en caliente
• Balanceo de carga dinámico
• Verificación de salud activa y pasiva
• Cortocircuito
• Autenticación
• Limitador de tasa
• Conversión de protocolo gRPC
• Broker dinámico TCP/UDP, gRPC, WebSocket, MQTT
• Panel de control
• Lista de prohibidos y permitidos
• Serverless

Apache APISIX ha sido lanzado en casi diez versiones, admitiendo muchas más funcionalidades que las enumeradas. El diagrama de arquitectura se dibuja según la situación del negocio, como sigue:

La historia de cómo integramos APISIX

Después de unos días de lectura de código, tengo una comprensión básica de Apache APISIX, pero surgió una pregunta: nunca he desarrollado ningún proyecto de código abierto. ¿Cómo podría lograrlo? Creé tres ramas diferentes localmente, una rama de Apache APISIX apunta al repositorio de código abierto upstream, otra rama dev se usa para la iteración regular del negocio, y la última rama principal se usa para actualizaciones en línea.

Después de dos semanas de trabajo duro, mi proyecto finalmente tiene algunas estructuras fundamentales. Es hora de examinar el resultado; así es como comenzamos la etapa de prueba de estrés. El servicio se implementa en Tencent Cloud con servidores de 8 núcleos y 32 GB de memoria, y el upstream es un entorno de producción en la nube regular, por lo que no se puede probar demasiado duro. El informe de rendimiento es el siguiente:

Resumen del informe de rendimiento: El tiempo de consumo de la interfaz se reduce en un 47%, no se generan errores y la estabilidad mejora. El valor máximo de TPS aumenta en un 82%, no se generan errores y la estabilidad mejora.

El entorno de desarrollo está listo, y comenzamos a estudiar la implementación en la nube. Apache APISIX admite muchos métodos de instalación: Docker, paquete RPM, Luarocks y códigos fuente. La mala noticia es que no se permite instalar nada en el entorno de la nube, y el código fuente solo se puede colocar en una ruta de ruta fija. Por lo tanto, muchas características de Apache APISIX no serían admitidas, ya que se desarrollan basadas en OpenResty 1.15.8. ¿Qué podría hacer? Los archivos compilados se generan en el repositorio de código, tiene que compilarse bajo algún directorio especificado, y no se puede usar el enlace estático de PCRE, lo que nos costó 1-2 días. Finalmente, ajustamos el lanzamiento gris; el tráfico aumentó del 2% al volumen total en varias semanas. Afortunadamente, todo salió bien al final.

Después de varias semanas de monitoreo, el servicio en línea es relativamente estable. Muchas funcionalidades de Apache APISIX 0.5 tienen que implementarse a través de llamadas a la interfaz API. Los parámetros de solicitud son propensos a errores de sintaxis, y no hay una página intuitiva y conveniente. Aparte de eso, nuestro escenario de negocio necesita tener la funcionalidad de exploración de servicios upstream. Es una coincidencia que la versión 0.7 de Apache APISIX acaba de ser lanzada, y la versión 0.7 admite la consola y la exploración de servicios upstream, que es exactamente lo que necesitamos ahora. ¡Qué gran noticia! ¡Tenemos que actualizar!

La rama de Apache APISIX es fácil de actualizar a 0.7, pero ¿cómo podríamos fusionar el código? Los cambios de código entre estas dos versiones son enormes. Intento fusionarlos primero, pero hay demasiados conflictos, y estamos en un ritmo tan peligroso. El método estándar de resolución de conflictos es poco realista, lo que podría causar toneladas de errores ocultos. ¿Hay alguna solución eficiente? Busqué en línea y encontré los métodos abreviados: git checkout –ours y git checkout –theirs (por favor, búsquelo si no lo ha usado), y completé la actualización de APISIX 0.5 a 0.7 en unos minutos. Por supuesto, también debería agradecer la robustez del código de APISIX, que me permite solo agregar complementos de negocio sin ningún acoplamiento.

Dado que la versión 0.7 de Apache APISIX proporciona una consola, ya no es necesario escribir JSON. Rápidamente examiné la verificación de salud, y no hubo problemas inicialmente, y pude percibir el estado del servicio upstream. Sin embargo, cuando revisé los registros del servicio upstream, descubrí que después de varios reinicios, la frecuencia de la verificación de salud seguía aumentando. Supongo que podría haber un error en la verificación de salud. Después de leer el código fuente, descubrí que el verificador para cada enrutador no es globalmente único. En cambio, cada trabajo tiene un verificador. Podríamos resolver este problema usando el mismo nombre para todos los trabajos creados. Incluso si es una corrección menor, es necesario un PR de corrección en caliente.

Actualicé el negocio en línea de APISIX a 0.7 y monitoreé el uso de recursos del servicio. Después de todo, fue un cambio de versión significativo, y no sentí nada durante las primeras horas, similar al último cambio de 0.5. Lo revisaré nuevamente cuando salga del trabajo. Parece que el uso de memoria no es correcto. La versión 0.5 ha sido relativamente estable, pero la versión 0.7 parece tener fugas de memoria. Dado que el uso de memoria está creciendo muy lentamente, decidí monitorearlo durante toda la noche. Al día siguiente, comparé los datos monitoreados, determiné que había una fuga de memoria y rápidamente volví a la versión anterior. Después de que todo estuvo hecho, proporcioné comentarios a Yuan Sheng sobre este problema. Según el escenario que describí, encontré el problema a través de pruebas de estrés. Era un problema con el árbol radix. El mismo problema nunca ocurrió después de que actualicé las dependencias, ya que Yuan Sheng lanzó la nueva versión del árbol radix.

Después de relanzar el proyecto, la versión 0.7 de Apache APISIX todavía podía darme sorpresas de vez en cuando. La dependencia de enrutamiento utilizada en la versión 0.5 de Apache APISIX era libr3, mientras que Apache APISIX 0.7 usaba el árbol radix, que tiene un mejor rendimiento. Los porcentajes de uso de CPU y memoria disminuyeron. En Apache APISIX 0.5, el uso de CPU es del 1-10%, y la memoria es del 0.1%. En Apache APISIX 0.7, el uso de CPU se reduce al 1-2%, y la memoria es inferior al 0.1%, lo cual es excelente.

Plan futuro

Apache APISIX ha sido lanzado durante dos meses, y no ha habido fallas ni errores. Esto es solo el comienzo, y podemos hacer mucho más en el futuro para mostrar más capacidades a los proveedores de servicios. La puerta de enlace proporciona un proxy inverso y ayuda a algunos equipos que no tienen tiempo para desarrollar funciones para garantizar la estabilidad del servicio, incluyendo servicios como limitación de tasa, cortocircuito, monitoreo y plataformas de acceso.

Finalmente, me gustaría agradecer a Yuan Sheng y Wen Ming por proporcionar productos tan excelentes y a la comunidad de Apache APISIX por las funcionalidades iterativas contribuidas. Ahora el tráfico diario de la puerta de enlace ha superado los 100 millones, y no hay problemas de rendimiento. ¡Gracias por su tiempo y atención!