Cómo APISIX facilita el despliegue localizado de la plataforma de redes sociales Beeto en Medio Oriente

Visión general

Desafíos

• La arquitectura de servicio monolítica resulta en altos costos de mantenimiento y operación
• Despliegue de arquitectura compleja y llamadas de servicio, y múltiples pilas tecnológicas

Resultados

• Unificación del tráfico norte-sur y este-oeste, ahorrando recursos y costos de mano de obra y permitiendo una gestión dinámica y unificada
• Simplificación de la arquitectura de despliegue, reduciendo así la interacción entre la puerta de enlace y los usuarios
• Los múltiples plugins de extensión de APISIX ayudaron a Beeto a gestionar eficientemente la verificación de permisos, la distribución de rutas y las funciones de verificación de salud de los servicios
• APISIX permite a Beeto lanzar y migrar servicios dinámicamente, lo que es amigable para los desarrolladores

Introducción a Beeto

Para el mercado de Oriente Medio, Beeto es una plataforma de redes sociales en árabe, con un diseño de producto y una arquitectura técnica localizados. Llegó a estar en el puesto número 4 de la lista Top del App Store de iOS en Arabia Saudita, superando al gigante de las redes sociales Facebook.

El desarrollo de Internet en Oriente Medio es maduro, con una penetración muy alta de usuarios activos en redes sociales. Especialmente en Arabia Saudita, donde el 90% de las personas usaban Internet en 2019. La tasa de penetración de usuarios activos en Arabia Saudita ocupó el noveno lugar en 2020.

La madurez del mercado de Internet resultó en la popularidad de software social internacional como WhatsApp, YouTube e Instagram. Sin embargo, no existe un software social localizado similar a Twitter. Por lo tanto, apuntando a la "madurez de Internet pero poca localización" de Oriente Medio, Beeto lanzó el desarrollo de productos localizados allí.

La localización es importante para Beeto

Comparado con aplicaciones de flujo de noticias como Twitter y Facebook, Beeto ha planeado un marco relativamente completo para desplegar su arquitectura de negocios en Oriente Medio. Por ejemplo, se comprometió a satisfacer la interacción de relaciones de atributos sociales, el consumo de contenido (texto, transmisión en vivo de video, publicidad local, etc.), así como varios negocios como recompensas, retiros, votaciones y sorteos de categorías financieras y de servicios, e incluso los requisitos de supervisión de la plataforma y revisiones de seguridad de contenido.

Como se indicó anteriormente, la madurez de Internet en el mercado de Oriente Medio requiere inevitablemente productos de alta calidad. Por lo tanto, la primera versión de la arquitectura de negocios de Beeto fue un producto completo que integraba todas las características que debería tener un software social principal. Mientras tanto, el objetivo de Beeto es convertirse en la mayor plataforma social en árabe y la mejor comunidad en árabe en Oriente Medio con "características de localización". Para lograr este objetivo, Beeto analizó los requisitos de localización como se muestra a continuación.

Puntos críticos en el diseño de la arquitectura de Beeto

La localización incluye las necesidades sociales locales existentes a nivel de negocio, y las operaciones de localización a nivel técnico, como el despliegue de servicios y el almacenamiento de datos. Aquellos familiarizados con Weibo o Twitter sabrán que se necesitan docenas o cientos de sistemas arquitectónicos para colaborar detrás de un producto de flujo de información tan grande. Los puntos críticos en la arquitectura de Beeto se muestran a continuación.

La arquitectura de servicio monolítica causa altos costos

Los servicios de Beeto se pueden dividir en ocho partes, como se muestra a continuación.

La implementación de estos negocios requiere un despliegue localizado en Oriente Medio. Cada servicio es una arquitectura monolítica separada si se divide cada negocio por servicio.

El diagrama de arquitectura monolítica anterior muestra una arquitectura de despliegue común. Tomemos como ejemplo el servicio de flujo de noticias de Beeto. Si queremos satisfacer la demanda del usuario de navegar por el flujo de noticias, debemos soportar el acceso a la red pública, es decir, el acceso al tráfico norte-sur; al mismo tiempo, el servicio de flujo de noticias también proporciona algunas llamadas internas en forma de negocio de temas, es decir, llamadas de tráfico este-oeste.

Por lo tanto, el servicio general soporta modos de llamada externa e interna. Después del balanceo de carga de la capa 7, el tráfico del usuario se distribuye a diferentes servidores, y luego se llaman diferentes recursos de almacenamiento. El tráfico este-oeste también es similar. El clúster de la capa 7 maneja el tráfico norte-sur y este-oeste, el balanceo de carga, la autenticación y el monitoreo de nodos.

Cuando se combinan los servicios de múltiples negocios, la arquitectura general puede ser:

Como se puede ver, los servicios existen en las capas de adaptación, negocio y servicio básico. La arquitectura de despliegue para cada uno de estos servicios tiene los detalles arquitectónicos monolíticos mencionados anteriormente, por lo que hay varios clústeres de la capa 7 en el medio, lo que es una arquitectura de sistema muy grande y compleja.

Sin embargo, dado que el producto Beeto está en la etapa de inicio y el producto se lanza en Oriente Medio, pero su equipo de I+D está en China, se requieren grandes costos de servidor y mantenimiento. Además, a medida que el negocio aumenta más adelante, el número de servicios monolíticos inevitablemente aumentará, lo que hará que sea más difícil controlar tanto los costos como las operaciones de mantenimiento.

Dificultad en el lanzamiento de múltiples servicios

Además de la complejidad del despliegue de la arquitectura, las llamadas entre servicios dentro del clúster también son muy complejas.

El tráfico norte-sur se distribuye a varios grupos de servicios, y el tráfico este-oeste también se entrelaza entre varios servicios, con las relaciones de llamada entre estos servicios entrelazadas.

Además, estas relaciones de llamada deben ser mantenidas por los servicios, lo que lleva a un seguimiento de llamadas poco claro y una mala gestión.

Además de las complejas relaciones de llamada, también hay diferencias en las pilas tecnológicas entre cada servicio. Por ejemplo, en el protocolo de llamada, algunos servicios proporcionan HTTP, mientras que otros proporcionan RPC; En términos del desarrollo de lenguajes de programación, hay una mezcla de Java, Go y otros lenguajes de programación.

Un sistema de arquitectura de múltiples servicios obviamente expondrá el problema de altos costos de despliegue y mantenimiento cuando se implemente localmente. Además, Beeto necesita invertir en costos de servidor en cada conjunto de servicios de la capa 7, mientras que la diferencia de tráfico de cada servicio conduce a un tráfico desequilibrado, lo que resulta en una baja tasa de utilización de recursos como servidores y desperdicio de recursos.

Dado que Beeto se centró más en las actualizaciones e iteraciones del negocio, la arquitectura está diseñada para facilitar el mantenimiento y la gestión unificada, por lo que ¿cómo lograr este objetivo?

La puerta de enlace APISIX potencia la arquitectura de Beeto

Para resolver los problemas de la gestión inconveniente de servicios y los altos costos y para beneficiarse del rendimiento dinámico de APISIX con etcd, que es más acorde con los requisitos del producto de Beeto, APISIX se introdujo como una puerta de enlace API en el despliegue de la arquitectura, y se construyó un clúster de puerta de enlace, como se muestra en la figura a continuación.

El clúster de puerta de enlace APISIX proporciona herramientas de extensión como un centro de registro, control de servicios, monitoreo de servicios, reenvío de protocolos y plugins para todos los servicios. Los clústeres de servicios pueden registrarse en la puerta de enlace, y se pueden agregar y eliminar nuevos servicios directamente a través de la puerta de enlace.

Después de la introducción de la puerta de enlace, el seguimiento de llamadas de todo el clúster fue más claro. El tráfico norte-sur es enrutado y reenviado por la puerta de enlace, y el tráfico este-oeste es por la puerta de enlace para servicios en la intranet. A nivel funcional, APISIX es responsable de mantener la autenticación llamada por este tráfico para que la capa de puerta de enlace pueda comprender claramente las diferencias de rendimiento y tráfico entre los servicios.

Por supuesto, dado que la puerta de enlace lleva todo el tráfico en esta arquitectura, el número de servicios aumentará más adelante a medida que el servicio se expanda, el costo de mantenimiento de la puerta de enlace aumentará y será necesario considerar nuevas soluciones. Sin embargo, en el contexto actual, la solución sigue siendo la mejor opción.

Prácticas después de aplicar APISIX

Apache APISIX, como una puerta de enlace API, puede manejar una variedad de políticas a nivel de puerta de enlace, como autenticación, reenvío de servicios y verificaciones de salud. Por lo tanto, Beeto ha hecho muchos intentos a nivel de práctica de negocio después de introducir APISIX.

Seguridad: Plugin de autenticación

Tráfico Norte-Sur: Cookie

Como mencionamos anteriormente, el tráfico de acceso de los usuarios de la red pública pasa por la puerta de enlace. La autenticación de los usuarios de la red pública es una solicitud de usuario basada en la autenticación de cookies. Cuando un usuario solicita llevar una cookie a la puerta de enlace, es verificada por el plugin de autenticación.

Como se muestra en el diagrama de flujo anterior, el plugin primero realizará una validación local y luego realizará una verificación de autenticación del servicio remoto según la política. Una vez que la solicitud es verificada por la cookie, se reenvía al servicio especificado.

Las ventajas de hacerlo son dos:

1. Se garantiza la seguridad de las cookies de los usuarios. Solo la capa de puerta de enlace puede recibir y procesar cookies durante la ejecución, ya que las cookies son datos sensibles. Esto evita problemas de seguridad causados por reglas de procesamiento de negocios inconsistentes y evita efectivamente la fuga de cookies causada por factores humanos e irregularidades.

2. Reducción de la complejidad de la autenticación de cookies para los servicios. Las cookies necesitan ser verificadas local o remotamente y requieren una actualización simultánea del servicio cuando las cookies se actualizan. APISIX gestiona y verifica de manera unificada, ahorrando el costo de verificación de los servicios de negocio e indicando los resultados, que pueden ser utilizados para el procesamiento de reglas de negocio, asegurando así que cada procesamiento de negocio se centre más en el negocio en sí.

Tráfico Este-Oeste: Token

En el diagrama a continuación, el Servicio A llama al Servicio B. Generalmente hablando, una API es todo lo que se necesita para llamarse mutuamente. Sin embargo, en el proceso interno, es necesario entender "quién llamó a la API, cómo se llamó, si es necesario verificar la autoridad, y si es necesario controlar al investigador", y así sucesivamente, lo que necesita ser manejado internamente.

Con la puerta de enlace APISIX, el proceso se vuelve mucho más simple. La llamada mutua de todos los servicios internos solo necesita registrarse en el servicio de autenticación Auth, y se emite una clave de App a cada servicio para indicar el ID de identidad del servicio. Al mismo tiempo, la llamada mutua de servicios internos también pasará por la puerta de enlace. Después de llevar el token a través de la puerta de enlace, la puerta de enlace autenticará el token a través de los plugins de token. Una vez que la autenticación es aprobada, el identificador de autenticación se pasa al servicio llamado. Durante todo el proceso, el sistema de servicios realizará el registro de autenticación y completará una llamada mutua.

Gracias a la regla de token de la clave de App, la operación anterior puede ser fácilmente rastreada hasta la fuente de la llamada, lo que puede ser utilizado para la resolución de problemas y el control de permisos, y también proporcionar un control efectivo sobre llamadas ilegales. Por lo tanto, la ventaja de la autenticación unificada es que, ya sea para el tráfico norte-sur o este-oeste, asegura la seguridad y uniformidad del clúster, lo que ayuda enormemente en el seguimiento de problemas y el control de llamadas.

Escalabilidad: Expansión y migración de servicios sin estado

La arquitectura de despliegue general del clúster de Beeto de arriba a abajo está compuesta por: clústeres de puerta de enlace APISIX - clústeres de servicios de negocio de servicios sin estado - clústeres de centros de datos de servicios con estado. Cuando se despliegan localmente en Oriente Medio, todos se despliegan en los principales clústeres en la nube. Según la escala de cobertura en la nube en Oriente Medio y los fabricantes de nube en diferentes regiones, es necesario considerar la expansión y migración de servicios en la nube al desplegar servicios.

En el proceso de migración, Beeto se centró en la migración de servicios sin estado. No es adecuado para el ajuste dinámico debido al costo limitado de migración del centro de datos; la mayoría de las solicitudes son llevadas por el servicio sin estado, por lo que es muy importante asegurar que el servicio sin estado tenga una buena escalabilidad.

En la arquitectura de Beeto, la escalabilidad del servicio se refleja principalmente en dos aspectos: escalabilidad de servicio monolítico y escalabilidad de clúster general. Por ejemplo, si un servicio monolítico se queda sin recursos y necesita expandirse, las puertas de enlace APISIX pueden agregar nodos dinámicamente para escalar. De manera similar, en situaciones de clúster cruzado o nube cruzada, la escalabilidad del clúster se puede lograr desplegando múltiples puertas de enlace APISIX y migrando diferentes servicios a diferentes nodos de puerta de enlace.

Para los servicios de negocio, la arquitectura general permanece sin cambios para que se pueda realizar la expansión y contracción dinámica de varios servicios y la migración de servicios en la capa de puerta de enlace. Todo el proceso tiene un plan y objetivo claros, y una vez que se involucran cambios, la arquitectura general no será inestable.

Extensibilidad funcional: Reenvío dinámico de servicios

Además de estos escenarios generales de puerta de enlace mencionados anteriormente, Apache APISIX también proporciona una asistencia significativa a Beeto en términos de reenvío dinámico de servicios.

Aquellos familiarizados con la UI y el backend de las APPs sabrán que diferentes páginas de productos son proporcionadas por diferentes servicios. Una página se compone de diferentes módulos, cuyo contenido es enviado desde la API. Cualquier dato que la API envíe al módulo se renderiza en los extremos. Esta es una especificación conjunta de renderización del lado del cliente para hacer que el proceso de renderización del lado del cliente sea más genérico y el procesamiento del negocio más flexible.

En la implementación de PageA en la figura anterior, por ejemplo, el cliente llama a la API del Servicio A, envía los datos del módulo correspondiente y completa la renderización de PageA. Esta operación causará problemas que el cliente necesita mantener cada página y API a cada servicio. Si el contenido cambia, es necesario resolverlo mediante publicación, lo que es muy poco amigable en términos de operabilidad y eficiencia.

La solución al problema anterior es implementar una distribución unificada de servicios en la arquitectura general. El cliente primero solicita la dirección de la API, reenvía todas las solicitudes de este tipo a una API, procesa los parámetros de solicitud y las reglas de URL para la dirección URL a nivel de puerta de enlace, y luego introduce el plugin de distribución. Finalmente, las solicitudes analizadas se reenvían directamente al servicio especificado en la capa de puerta de enlace según las reglas de configuración.

El cliente solo necesita determinar la especificación de renderización durante todo el proceso, no la fuente de los datos. La capa de puerta de enlace asume la responsabilidad de la distribución de servicios y reenvía el tráfico directamente. El archivo de configuración del plugin en APISIX puede actualizarse dinámicamente en tiempo real, y las reglas de reenvío pueden ajustarse dinámicamente, lo que es muy flexible. De hecho, para aplicaciones como la arquitectura BFF (Backend for Frontend), tales requisitos pueden resolverse en la capa de puerta de enlace.

Conclusión

Este artículo presenta las prácticas de aplicación de la introducción de Apache APISIX por parte de Beeto desde las perspectivas de pensamiento de diseño y negocios.

APISIX apoyó a Beeto en el control del costo de recursos y múltiples líneas de productos de negocio y ayudó a Beeto a realizar el despliegue localizado, la gestión unificada y operación, y escenarios amigables para el mantenimiento en Oriente Medio.