¡Abandona Spring Cloud Gateway! Cómo Huanbei, una aplicación Fintech, utiliza Apache APISIX

Amor y odio por Java

¿Por qué los sistemas financieros prefieren Java?

Java siempre ha sido popular y preferido por muchos desarrolladores desde su lanzamiento debido a sus ventajas como lenguaje y su enorme ecosistema.

En los últimos 15 a 20 años, muchos sistemas financieros han elegido Java como su pila tecnológica principal. Después de algunas investigaciones, hemos concluido las siguientes ventajas de Java:

Debido a las razones anteriores, Java gana el favor de los sistemas de software financiero.

El estado actual de Java en la era de la nube nativa

Con el rápido desarrollo de la tecnología, la industria abandonará pronto la arquitectura monolítica, y los microservicios y la nube nativa se convertirán en la corriente principal. Sin embargo, en el entorno tecnológico de los últimos años, Java ha comenzado a perder su papel dominante en algunos escenarios comerciales.

Primero, Java tiene un rendimiento débil; entenderías por qué digo esto al comparar Java con la pila tecnológica relacionada con C.

Segundo, Java se ejecuta en máquinas virtuales, y estas se encargan de la gestión de memoria de Java. Por lo tanto, Java se vuelve menos competitivo cuando se necesita alto rendimiento o cambios dinámicos.

Además, Java necesita muchos más recursos. Es fácil construir un marco sin preocuparse por el costo. Sin embargo, dado que los cálculos se han vuelto mucho más detallados y granulares en la era de la nube nativa, los recursos se han vuelto más preciosos que nunca. Además, Java consumiría enormes recursos para ejecutarse porque es pesado y necesita reiniciarse de vez en cuando. Como resultado, Java tendría problemas con una alta demanda de QPS y continuidad del negocio.

Por último, pero no menos importante, el problema del puntero también vale la pena discutir. El puntero es un buen recurso para aquellos desarrolladores familiarizados con C/C++. Sin embargo, Java se ejecuta en una máquina virtual, lo que significa que la gestión de memoria la maneja el GC (Recolección de Basura) en lugar de los desarrolladores. En ese caso, el rendimiento de Java podría no ser suficiente en algunas circunstancias cuando hay una demanda estricta de alta concurrencia, tráfico y rendimiento.

¿Por qué HuanBei eligió APISIX?

Shuhe Group es una plataforma de tecnología financiera que proporciona servicios eficientes e inteligentes para empresas y personas en los negocios; tiene productos como HuanBei, EnjoyPay, etc. HuanBei es una plataforma que ofrece un servicio de cuotas que sirve a múltiples escenas de consumo. Al trabajar con instituciones financieras autorizadas, HuanBei también proporciona servicios de préstamos personales y ofrece fondos de préstamos para startups. HuanBei siempre ha utilizado una pila tecnológica de Java para desarrollar sus productos en el negocio.

Spring Cloud Gateway es una puerta de enlace que tiene como objetivo gestionar mejor los microservicios bajo el ecosistema de Spring Cloud. Spring Cloud Gateway es una puerta de enlace API decente para empresas que utilizan Java como su lenguaje de desarrollo principal. Sin embargo, en la reciente actualización de la puerta de enlace API, HuanBei abandonó el Spring Cloud Gateway, que había utilizado durante mucho tiempo, y comenzó a usar Apache APISIX.

Diferencias arquitectónicas entre Spring Cloud Gateway y APISIX

HuanBei utilizó tres sistemas diferentes de puertas de enlace API antes de adaptar APISIX. HuanBei utilizó Spring Cloud Gateway como puerta de enlace de sus sistemas de operación y salida, y OpenResty como puerta de enlace de su sistema de negocio.

HuanBei utilizó Spring Cloud Gateway como puerta de enlace de sus sistemas de operación y salida inicialmente debido a que Spring Cloud Gateway tiene un enorme ecosistema y un sistema de desarrollo distribuido fácil de implementar y mantener. Para construir rápidamente modelos de negocio, HuanBei utilizó todos los servicios proporcionados por Spring Cloud cuando se construyó la base del negocio.

Con el desarrollo del negocio, la puerta de enlace comenzó a tener algunos problemas de estabilidad en la arquitectura original, como desbordamiento de memoria, alto uso de CPU, etc. Por lo tanto, HuanBei utiliza Apache APISIX como la única puerta de enlace en la arquitectura para mejorar el rendimiento de la puerta de enlace y gestionar uniformemente múltiples puertas de enlace.

En el nuevo marco de la puerta de enlace, la puerta de enlace transferiría directamente el tráfico de solicitudes al sistema de negocio mediante el descubrimiento de servicios. Sin embargo, si la aplicación backend no admite el descubrimiento de servicios o no tiene un Pod saludable en Consul, el sistema redirigirá el tráfico al anterior Ingress de la intranet K8s.

La aplicación práctica de APISIX

Huanbei tiene que modificar la configuración de APISIX en escenarios comerciales reales, ya que no puede usar Apache APISIX directamente debido a sus múltiples marcos de puerta de enlace internos.

Construcción e implementación de APISIX

Durante el desarrollo interno, HuanBei colocó los códigos fuente de la puerta de enlace APISIX y los códigos personalizados en diferentes rutas y los hizo cooperar e iterar de forma independiente. HuanBei utilizó una imagen de Docker para implementar la puerta de enlace. Primero, crearía una imagen predeterminada basada en una versión específica de APISIX, y luego usó códigos personalizados para envolverla en una nueva imagen.

El envoltorio de códigos personalizados no utilizó lua_package_path para especificar el directorio de código; en su lugar, cubrió directamente la imagen predeterminada apisix bajo el directorio de códigos fuente si existía un archivo con el mismo nombre. El Dockerfile se muestra a continuación:

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

El registro de APISIX se almacena localmente (podría ser recopilado por Syslog u otros complementos); podríamos modificar la plantilla de configuración de NGINX y verificar el Perfil utilizado para decidir si queremos almacenar los registros localmente o almacenarlos en FLUENTD a través de Syslog. También necesitamos reemplazar la variable FLUENTD_HOST al construir las imágenes, como se muestra a continuación:

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

En la plantilla de configuración de NGINX, HuanBei no solo modificó el almacenamiento de registros, sino que también agregó variables de entorno ENV y configuraciones lua_shared_dicts en bucles y corrigió algunos parámetros de optimización de NGINX.

HuanBei separa el tráfico según las diferentes necesidades comerciales y crea múltiples puertas de enlace con funcionalidades similares. Por lo tanto, HuanBei utiliza internamente un plan de "único código fuente pero múltiples aplicaciones de puerta de enlace". Primero, HuanBei configura el archivo config-xxx.yaml de cada puerta de enlace utilizando la función de Perfil, y luego puede construir las imágenes de Docker de diferentes puertas de enlace basándose en el nombre de la aplicación mientras construye las imágenes a través de la plataforma DevOps.

Complementos personalizados a nivel empresarial

Al visitar el sistema de operación internamente, el sistema llamaría a muchas API backend para obtener datos, y estas API deben incluirse en la lista blanca de la configuración de la puerta de enlace API. El sistema de permisos debe mantener una lista relacionada de API, ya que la página ofrecería diferentes rangos de API según el rol de cada usuario que inicie sesión en el sistema de operación. Cada vez que hay una nueva llamada API desde la página, los desarrolladores necesitan agregar configuraciones dos veces en la puerta de enlace y el sistema de permisos, lo cual es redundante y repetitivo.

Para lograrlo, HuanBei elimina la barrera entre la configuración de la puerta de enlace y la configuración del sistema de permisos, y solo mantiene la entrada del sistema de permisos. El sistema de gestión de configuración de la puerta de enlace obtendría periódicamente la API de permisos y luego la convertiría en la configuración de la lista blanca de API de la puerta de enlace. Este comportamiento omitiría una acción de configuración innecesaria y ayudaría al sistema de permisos a realizar el control de permisos. Además, garantiza que la API backend llamada en la página de operación exista en la configuración del sistema de permisos.

En escenarios comerciales, siempre hay algunas necesidades que los complementos nativos no pueden satisfacer, lo que requiere desarrollo personalizado. APISIX proporciona muchas herramientas que podrían ayudar a personalizar fácilmente los complementos nativos. La siguiente tabla enumera algunos complementos personalizados desarrollados basados en APISIX dentro de HuanBei:

Lanzamiento Canario de la Puerta de Enlace

Anteriormente, HuanBei utilizó OpenShift como sus contenedores K8s (actualmente ha actualizado al clúster ACK), y el Ingress se construyó con Haproxy.

Debido a que el Haproxy del Ingress de K8s de la red pública no podía dividir el tráfico de un solo dominio en dos rutas de Namespace diferentes, necesitamos considerar implementar la nueva puerta de enlace en el mismo Namespace en lugar de la puerta de enlace anterior. En otras palabras, cada ruta de dominio tendría múltiples servicios, y podríamos controlar el tráfico de la nueva y la antigua puerta de enlace asignando diferentes porciones del tráfico total.

El flujo de implementación real se muestra a continuación, agregaría los grupos c y d para implementar una nueva puerta de enlace bajo el Namespace de la puerta de enlace anterior, y podría controlar la proporción de tráfico de las nuevas y antiguas puertas de enlace.

Factores de la Puerta de Enlace Relacionados con Java

Muchos desarrolladores de Java elegirían Spring Cloud en la arquitectura de microservicios, ya que Spring Cloud podría soportar Java sin problemas, y embebe bibliotecas de clases en los códigos fuente. Sin embargo, en la práctica aparecen situaciones difíciles de actualización. Por ejemplo, si el equipo necesita mantener múltiples bibliotecas de clases, y hay 10 lenguajes diferentes con 10 versiones diferentes, entonces este equipo necesita mantener 100 bibliotecas de clases diferentes.

Ahora, podríamos usar fácilmente un proxy (puerta de enlace API) para resolver problemas de múltiples versiones y múltiples lenguajes. Entonces, ¿cuáles son los beneficios para las empresas que usan una pila tecnológica de Java y eligen APISIX como su puerta de enlace API? Concluimos basándonos en dos aspectos de la experiencia práctica de HuanBei.

Para la Empresa

1. Gran Funcionalidad y Rendimiento

El QPS de APISIX podría alcanzar 80k si HuanBei usa máquinas virtuales de 4 núcleos sin ningún complemento para realizar pruebas de estrés en APISIX. Además, APISIX resuelve perfectamente el problema de rendimiento de Spring Cloud Gateway al recibir el tráfico del consumidor, y su rendimiento mejora en un 30% en el entorno de producción en comparación con las puertas de enlace anteriores.

Además, APISIX podría cumplir con todos los requisitos de la empresa bajo las pruebas reales, como autenticación e identificación, observabilidad, descubrimiento de servicios, limitación de tasa y transferencia de tráfico de capa cuatro y siete. En cuanto a la extensión de características, APISIX soporta más de 70 complementos, y la mayoría de los negocios pueden usar sus complementos nativos, lo que reduce una enorme cantidad de trabajo de desarrollo.

2. Reducir el Costo del Negocio

Antes de usar APISIX, las empresas debían aumentar el número de servidores para resolver problemas de rendimiento, lo que aumentaba significativamente los costos de hardware.

HuanBei ha calculado el costo y encuentra que el costo de los servidores se ha reducido en aproximadamente un 60% después de usar APISIX. Además, después de unificar la pila tecnológica, el negocio podría extender diferentes características rápidamente basándose en la arquitectura nativa de APISIX, reducir los gastos de desarrollo y acelerar el tiempo de lanzamiento del producto.

Para los Desarrolladores

1. Cumplir con los Requisitos del Negocio

Todo el software o tecnología utilizada en el negocio debe servir a las necesidades. Sin embargo, según los resultados de las pruebas prácticas y la investigación, APISIX tiene mejor estabilidad, observabilidad y extensibilidad.

El software tiene como objetivo servir al negocio. Por lo tanto, si un requisito comercial podría ayudar a la empresa a ahorrar recursos, sin importar qué pila tecnológica use esta empresa, también debería usar los componentes que coincidan con la empresa.

2. Reducir los Costos de Mantenimiento

En comparación con el OpenResty utilizado anteriormente, APISIX tiene un menor costo de aprendizaje y es más fácil de mantener. Mientras tanto, los ricos complementos de APISIX simplifican la implementación y el desarrollo de algunas características estándar, reduciendo el tiempo de lanzamiento del producto.

Además, las poderosas funciones de registro y depuración dinámica de APISIX ayudan a detectar los puntos de falla en el negocio para que podamos localizar rápidamente el error y ahorrar tiempo.

Conclusión: Tendencias del Desarrollo de la Industria Financiera

En la etapa de crecimiento brutal, lo único que importa es la eficiencia. Por lo tanto, el director preferiría su lenguaje familiar para construir el sistema y elegir diferentes pilas tecnológicas durante las selecciones de marco de bajo nivel para lanzar los modelos de negocio más rápidamente. Diferentes directores elegirían otras pilas tecnológicas, lo que causaría muchos problemas futuros. Sin embargo, la mayoría de las empresas financieras activas y las compañías de servicios financieros enfrentarían el mismo problema técnico: el problema de múltiples pilas tecnológicas. Cuando ocurre este problema, necesitan combinar sus pilas tecnológicas en una.

Cuando el negocio de la empresa funciona correctamente, es hora de que la empresa divida su sistema verticalmente. La empresa necesita convertir su arquitectura de silos de información en una arquitectura de tres capas que consiste en un front-end, un middle-end y un back-end. Luego, cuando el sistema opera de manera estable, es hora de que las empresas implementen componentes de bajo nivel por sí mismas.

El objetivo final de construir un sistema es compartir. El sistema tiene menores gastos de mantenimiento si tiene una mayor repetibilidad. Por lo tanto, cuando la operación del negocio se estabiliza, muchas empresas comienzan a dividir verticalmente o implementar los componentes fundamentales de bajo nivel para controlar los gastos de mantenimiento.

Para las empresas, el gasto siempre es el principio más importante a considerar. En la etapa de crecimiento brutal, las empresas solo necesitan lanzar y hacer que los negocios operen lo más rápido posible. Aún así, el gasto debería tener la máxima prioridad bajo el presupuesto en este gran entorno. En ese caso, tenemos que elegir entre eficiencia y costo. Por lo tanto, las empresas no usarían tecnología de vanguardia si el presupuesto es limitado. Del mismo modo, el personal técnico no consideraría las siguientes preguntas al elegir la pila tecnológica: ¿Cómo afectaría esta nueva tecnología al equipo? ¿Cuántos beneficios podría traer esta nueva tecnología a la infraestructura actual?

El personal técnico solo consideraría el gasto de esta nueva tecnología.