Arquitectura de Bitrix24

Autor: Adriana Sánchez

Última actualización: 24 de octubre de 2021

Antes de desarrollar Bitrix24, hemos creado los siguientes requisitos para la arquitectura de Bitrix24:

Hay cuentas en el plan gratuito Free, por lo que debemos mantener el costo inicial de estas cuentas lo más bajo posible.
Bitrix24 es una aplicación empresarial. Esto significa que la carga en los servidores será desigual, será mayor al mediodía y menor por la noche. Por lo tanto, debemos tener una arquitectura escalable y usar exactamente tantos recursos como sea necesario en un momento dado.
Al mismo tiempo, la confiabilidad es extremadamente importante para cualquier aplicación empresarial. Los datos deben estar seguros y disponibles en cualquier momento.
Empezamos a trabajar en tres mercados diferentes: Estados Unidos, Alemania, Rusia.

Todos estos requisitos han definido dos objetivos principales: formar una plataforma de desarrollo en la nube escalable y tolerante a fallas y seleccionar una plataforma tecnológica para la infraestructura del proyecto.

Bitrix24 está construido como un grupo de servidores web intercambiables. Si aumenta la carga en los servidores, se pueden agregar más servidores a un clúster en poco tiempo. Si algún servidor falla, los clientes no lo sentirán ya que todo sigue funcionando usando otros servidores del clúster.

El soporte de almacenamiento en la nube resuelve el problema de la sincronización del contenido estático. La replicación master-master en MySQL permite construir clústeres web distribuidos geográficamente.

Arquitectura tolerante a fallas

Usamos Amazon AWS, pero también se pueden usar otras plataformas.

Auto scaling

La aplicación (web) se escala horizontalmente (agregando nuevas máquinas), no verticalmente (aumentando la capacidad del servidor).

Para hacer eso, usamos Elastic Load Balancing + CloudWatch + Auto Scaling. ELB (Elastic Load Balancing) distribuye automáticamente el tráfico de aplicaciones entrante (HTTP y HTTPS). El aumento y la disminución de la carga se controlan a través de CloudWatch.

Cuando aumenta la carga, se encienden nuevos servidores. Si la carga disminuye, los servidores adicionales se apagan automáticamente. Por lo tanto, reducimos el costo principal (los servidores redundantes no funcionan inactivos).

Contenido estático

Cuando un cliente crea una nueva cuenta de Bitrix24, se crea una cuenta personal de Amazon S3 para ella, para almacenar los datos. Por lo tanto, los datos relacionados con cada cuenta de Bitrix24 están aislados entre sí. Además, el almacenamiento S3 en sí es completamente seguro.

Los datos de Amazon S3 se replican en varios puntos, además, en puntos distribuidos geográficamente (diferentes centros de datos). Cada uno de los dispositivos de almacenamiento se monitorea y se reemplaza rápidamente si se registra algún mal funcionamiento.

Cuando cargue archivos nuevos en el almacenamiento, recibirá una notificación sobre una carga exitosa solo cuando el archivo se guarde con éxito en varios puntos diferentes. Por lo general, los datos se replican en tres o más dispositivos para garantizar la tolerancia a fallas, incluso si dos de estos dispositivos han fallado.

La arquitectura S3 está diseñada para que Amazon esté listo para brindar disponibilidad al nivel de dos nueves después del punto decimal. Y la probabilidad de pérdida de datos es una mil millonésima parte de un porcentaje.

17 centros de datos y replicación master-master

Todo el proyecto está ubicado en 17 centros de datos diferentes ubicados en todo el mundo. Los datos del cliente se almacenan en aquellos países en los que la ley exige que se almacenen. Así, resolvemos dos problemas a la vez: distribuimos la carga de los servidores (por ejemplo, los usuarios alemanes trabajan en un centro de datos y los usuarios estadounidenses en otro), y reservamos todos los servicios: en caso de falla de uno de los centros de datos, simplemente cambiamos el tráfico al otro.

La base de datos de cada CC es maestra de otra CC esclava y, al mismo tiempo, es esclava de otra CC maestra.

Cada cuenta de Bitrix24 (todos los empleados registrados en ella) en un momento dado funciona con un solo centro de datos y una base de datos. La conmutación a otro centro de datos se realiza solo en caso de avería.

Las bases de datos en diferentes países son sincrónicas pero independientes entre sí. La conectividad entre los centros de datos se puede perder durante varias horas. En tales casos, los datos se sincronizan después de la recuperación de la conectividad.

También utilizamos la replicación master-master. Si el servidor de la base de datos falla o se reinicia, los clientes se cambian inmediatamente a otro servidor.

Fiabilidad y tolerancia a fallos

Una de las principales prioridades en Bitrix24 es la disponibilidad constante del servicio y su tolerancia a fallas.

Si hay un accidente en uno o varios nodos web, Load Balancing determina las máquinas que fallaron y, según los parámetros especificados (la cantidad mínima requerida de máquinas en ejecución), la cantidad requerida de instancias se restaura automáticamente.

Si se pierde la conectividad entre los centros de datos, cada centro de datos continúa sirviendo a su segmento de clientes. Una vez recuperada la conectividad, los datos de las bases de datos se sincronizan automáticamente.

Si el centro de datos falla por completo, todo el tráfico se cambia automáticamente a otro centro de datos.

Si provoca un aumento de la carga en las máquinas, CloudWatch determina la mayor utilización de la CPU y agrega la cantidad necesaria de máquinas en un centro de datos de acuerdo con las reglas de AutoScaling.

Al mismo tiempo, se detiene la replicación master-master. Después de realizar el trabajo necesario, vuelve a encender la base de datos y restaura la replicación.

Si todo va bien, el tráfico se distribuye entre los centros de datos. Si la carga promedio ha caído por debajo del valor umbral, las máquinas adicionales que se han encendido para manejar el aumento de carga se detienen automáticamente.

Para los servicios en la nube, es un gran problema actualizar la funcionalidad y el software del sistema. En ocasiones se ven obligados a desconectar temporalmente el servicio, advertir a los usuarios, realizar labores nocturnas. Nuestra arquitectura nos permite hacer eso para que los usuarios ni siquiera lo noten.

Tecnología WebRTC: llamadas, videollamadas, telefonía

Las videollamadas en Bitrix24 son privadas. Las conversaciones de video confiables dentro de la empresa se basan en la tecnología WebRTC. La conexión está encriptada, las llamadas se realizan entre usuarios como peer-to-peer, el proceso es casi transparente y se lleva a cabo "dentro" del navegador.

SIGNALING

SIGNALING realiza tres tareas sencillas:

Interconecta configuraciones de dos navegadores (flujos de audio / video, códecs, direcciones, puertos en formato SDP).
Intercambia contraseñas para establecer una conexión cifrada entre navegadores.
Inicia acciones: llamar a alguien (conectar el flujo del cliente A al flujo del cliente B en las devoluciones de llamada en js), finalizar la llamada, etc.

Con otras palabras, los navegadores se conectan entre sí mediante signaling, que le permite realizar videollamadas.

Llamar es fácil cuando ambos usuarios están en la misma red local. Pero cuando los usuarios están en diferentes redes y han configurado firewalls, los navegadores no pueden establecer una conexión sin la ayuda:

Para pasar los cortafuegos de la empresa, los usuarios acceden al servidor central mediante los protocolos STUN / TURN.
Si es imposible pasar el cortafuegos, los flujos de medios pasan por un servidor de terceros, no de peer-to-peer entre navegadores (en modo "relay").

Videoconferencias

Cuando se realiza una videollamada grupal, cada navegador contiene la transmisión de video de cada participante usando WebRTC.

WebRTC y telefonía

Bitrix24 se integra con "puertas de enlace" para realizar llamadas a números de teléfono regulares desde / hacia la empresa.

Sitio web compuesto

Bitrix24 utiliza una tecnología única para mejorar el rendimiento del servicio que une la carga de alta velocidad de datos estáticos y la preparación en segundo plano de datos dinámicos.

Las páginas se dividen en dos secciones: estática y dinámica. La parte estática se almacena en caché y se muestra inmediatamente. La parte dinámica se carga mediante procesamiento en segundo plano y se almacena en caché en el navegador.