Autor: Zen y el arte de la programación informática
1. Introducción
WebSocket (nombre completo: Web Sockets) es un protocolo de comunicación bidireccional en una única conexión TCP, que permite al servidor enviar datos activamente al cliente. Con el auge de la computación en la nube, los big data, el Internet de las cosas, el Internet móvil y otras tecnologías, cada vez existen más aplicaciones basadas en WebSocket, como salas de chat, videoconferencias, terminales inteligentes, transmisiones en vivo de juegos, simulación de negociación de acciones y otras. escenarios.
La arquitectura de servidor tradicional basada en HTTP requiere la compra de equipos o marcos de equilibrio de carga para admitir WebSocket, mientras que la arquitectura sin servidor no requiere una arquitectura tan compleja. Este artículo explicará en detalle cómo utilizar la arquitectura sin servidor para crear un sistema de procesamiento de mensajes que admita la comunicación WebSocket.
El contenido principal del artículo es el siguiente:
- ¿Qué es sin servidor?
- ¿Por qué utilizar la arquitectura Serverless?
- Ventajas y desventajas de la arquitectura sin servidor
- Combinando WebSocket y Serverless en la práctica
- Apéndice Preguntas frecuentes
- Repositorio de código fuente y enlaces de código de muestra
1. ¿Qué es sin servidor?
La arquitectura sin servidor es un modelo de programación que crea aplicaciones sin preocuparse por la infraestructura del servidor. Los desarrolladores solo necesitan centrarse en la lógica empresarial e implementar funciones de la aplicación a través de llamadas API, activadores de eventos u otras formas de ejecución directa proporcionadas por herramientas o plataformas. La arquitectura sin servidor se ha utilizado ampliamente, como Amazon AWS Lambda, Microsoft Azure Functions, Google Cloud Functions, etc.
La arquitectura sin servidor no solo puede reducir los costos de operación y mantenimiento, sino que también ayuda a los usuarios a iniciar rápidamente sus aplicaciones porque elimina la complejidad de la inversión en hardware, la administración y configuración del servidor. La arquitectura sin servidor favorece la reducción de los costos de desarrollo y operación, por lo que permite a las empresas lograr una iteración rápida, acortar los ciclos de entrega y aumentar el valor del producto.
2. ¿Por qué utilizar la arquitectura sin servidor?
Dado que la arquitectura Serverless no requiere administración de servidores, es muy sencillo implementar aplicaciones y ampliar recursos. Cuando el tráfico de la aplicación aumenta a un cierto nivel, la cantidad de servidores se puede aumentar para manejar más solicitudes; cuando el tráfico disminuye, la cantidad de servidores también se puede reducir para ahorrar recursos. Para empresas emergentes, proyectos personales y equipos pequeños, las aplicaciones se pueden implementar de manera muy conveniente. Al mismo tiempo, la arquitectura sin servidor puede adaptarse bien a diversos cambios y ahorrar a los usuarios gastos como servidores y ancho de banda.
Aunque la arquitectura sin servidor es simple y fácil de usar, también tiene algunas limitaciones. En primer lugar, la arquitectura sin servidor no puede reemplazar por completo las funciones del lado del servidor. Por ejemplo, cuando se trata de conexiones largas, llamadas entre servicios, etc., aún necesita escribir servicios en segundo plano para manejar las tareas. En segundo lugar, la arquitectura sin servidor debe depender de complementos o servicios proporcionados por terceros fabricantes, lo que también resulta problemático.
En aplicaciones reales, se pueden seleccionar diferentes patrones arquitectónicos según las necesidades, como arquitectura de microservicios, arquitectura en contenedores, etc.
3. Ventajas y desventajas de la arquitectura sin servidor
3.1 Ventajas
- La arquitectura sin servidor de pago por uso permite a las empresas pagar sólo por los recursos que utilizan, lo que reduce considerablemente los costos. Además, los usuarios sólo deben pagar por el tiempo de ejecución de la función, no por el tiempo de ejecución de cada servidor.
- Escalado automático Durante los períodos de mayor tráfico, la arquitectura sin servidor puede expandirse automáticamente para responder a las solicitudes de los usuarios y reducirse automáticamente durante los períodos de poco tráfico. Esto puede ahorrar recursos de manera efectiva y mejorar la eficiencia.
- Los usuarios del entorno sin servidor solo necesitan cargar el código fuente y la plataforma de arquitectura sin servidor puede asignar recursos automáticamente para ejecutar funciones. Bajo esta arquitectura, no hay necesidad de administrar servidores ni configuraciones de servidores, y no hay desperdicio de recursos.
- Flexible y elástico Debido a que la plataforma no ocupa demasiados recursos, la asignación de recursos se puede ajustar dinámicamente según el uso de la aplicación. Esto también garantiza una escalabilidad elástica.
- Operación eficiente Dado que no es necesario administrar servidores, la arquitectura sin servidor puede completar solicitudes altamente concurrentes en poco tiempo, lo que es más eficiente que las arquitecturas tradicionales.
- Reducción de los costos operativos: no es necesario mantener servidores ni preocuparse por fallas de los dispositivos de hardware, lo que reduce los costos operativos.
- Las tarifas de uso del servicio de pago por uso se pueden cobrar en función del tiempo de ejecución de la función, que es más flexible que el modelo de tarifa fija de la arquitectura tradicional.
3.2 Desventajas
- Latencia Debido al uso de una arquitectura asíncrona, las llamadas a funciones pueden provocar retrasos. Sin embargo, esto se puede aliviar mediante el procesamiento simultáneo.
- Disponibilidad Si ocurre un error en una función, puede afectar la disponibilidad de todo el servicio.
- Los entornos en ejecución de las funciones de aislamiento son independientes entre sí y no pueden acceder a recursos compartidos, lo que puede generar problemas de seguridad de los datos.
- Velocidad de ejecución Debido al uso de arquitectura asíncrona, la velocidad de ejecución de la función puede ser limitada. Si una función tarda mucho en ejecutarse, es posible que los resultados de su ejecución deban esperar mucho tiempo.
4. Combinando WebSocket y Serverless en la práctica
Basado en la arquitectura sin servidor mencionada anteriormente y combinada con la tecnología WebSocket, se puede construir un sistema de procesamiento de mensajes que admita la comunicación WebSocket. Este sistema puede recibir solicitudes de WebSocket de front-end, analizar el contenido del mensaje y llamar a la interfaz de servicio de back-end correspondiente para su procesamiento.
El diagrama de arquitectura es el siguiente:
- El front-end envía una solicitud de WebSocket a la API de WebSocket para establecer una conexión.
- La API de WebSocket llama a la plataforma Serverless y solicita el establecimiento de un canal de red virtual para el WebSocket front-end.
- La plataforma crea un canal de red virtual WebSocket en segundo plano.
- La interfaz envía un mensaje a la API WebSocket y la API pasa el mensaje a la cola de mensajes del servidor.
- La cola de mensajes en el lado del servidor obtiene el mensaje y llama a la interfaz de servicio en segundo plano correspondiente para procesar el mensaje.
- La interfaz de servicio en segundo plano del servidor termina de procesar el mensaje y devuelve el resultado a la cola de mensajes.
- La cola de mensajes reenvía los resultados al front-end.
- La API WebSocket envía mensajes al front-end.
Las ventajas de utilizar la arquitectura Serverless para implementar la comunicación WebSocket incluyen:
- Los usuarios no necesitan comprar servidores por adelantado y solo deben concentrarse en la implementación de la lógica empresarial.
- La plataforma puede ampliar automáticamente su capacidad y manejar el tráfico repentino rápidamente.
- El código de procesamiento de mensajes en el lado del servidor se puede optimizar en gran medida para evitar problemas como la congestión de la red.
- Los usuarios no necesitan preocuparse por cuestiones como la estructura de red subyacente y el ancho de banda.
5. Preguntas frecuentes
5.1 ¿Encontrará problemas entre dominios?
Las plataformas de arquitectura sin servidor generalmente brindan acceso a diferentes nombres de dominio, por lo que las solicitudes de WebSocket bajo diferentes nombres de dominio se considerarán solicitudes diferentes, lo que significa que el campo Origen en el encabezado de la solicitud también cambiará. Por razones de seguridad, los navegadores bloquean las solicitudes entre dominios de forma predeterminada, por lo que la conexión no se puede establecer correctamente. Sin embargo, los problemas entre dominios se pueden manejar a través de algunas soluciones entre dominios, como CORS (Cross Origin Resource Sharing).
5.2 ¿Necesito configurar permisos de roles por separado para cada función?
En la arquitectura sin servidor, cada función tiene su propio entorno de ejecución independiente y se pueden utilizar roles de IAM (gestión de identidad y acceso) para controlar los permisos de acceso. Por tanto, no es necesario configurar permisos individualmente para cada función.
5.3 ¿Cuáles son los motivos del fracaso de la solicitud?
- La API WebSocket no se crea. La creación de una API de WebSocket requiere el uso de AWS API Gateway; de lo contrario, deberá comprar recursos de nube adicionales.
- No autorizado para acceder a la API de WebSocket. Es necesario configurar el método de llamada relevante en API Gateway y otorgar los permisos correspondientes.
- Hay un problema con el servicio en segundo plano en el lado del servidor. Compruebe si el código del servidor es correcto y la información de salida del registro del servidor.
- Se agotó el tiempo de espera de la llamada a la API de WebSocket. Estos problemas pueden deberse a fluctuaciones de la red y otros motivos. Puede intentarlo nuevamente o actualizar a la última versión del software.
5.4 ¿Se computará como tráfico?
En el proceso de uso de WebSocket, la solicitud del usuario no se contará como tráfico, pero el establecimiento y cierre de la conexión WebSocket se contará como tráfico.
5.5 ¿Cómo monitorear el estado de WebSocket?
Puede utilizar AWS CloudWatch para monitorear el estado de WebSocket, incluida la cantidad de conexiones, la duración de la conexión, etc.