La arquitectura general de SAE
Proxy inverso de nivel 7: el proxy inverso HTTP, en la capa más externa, es responsable de responder a la solicitud HTTP del usuario, y lo reenvía al backend después del análisis. El grupo de servicios web del extremo proporciona equilibrio de carga, verificación de estado y otras funciones.
Enrutador de servicios: capa lógica, responsable del mapeo rápido (complejidad de tiempo O(1)) al grupo de servicios web correspondiente y la ruta de hardware correspondiente según el identificador único de la solicitud. Si se descubre que la relación de mapeo no existe o es incorrecta, se mostrará el mensaje de error correspondiente. Esta capa oculta mucha información de direcciones específicas a los usuarios, por lo que los desarrolladores no necesitan preocuparse por la distribución interna real del servicio.
Pool de servicios Web: Está formado por unos pools de servicios Web con diferentes características. En realidad, cada grupo de servicios web está compuesto por un grupo de Apache (PHP), y estos grupos proporcionan diferentes niveles de servicios según diferentes SLA. Cada proceso de servicio web en realidad maneja la solicitud HTTP del usuario. El proceso se ejecuta en el entorno limitado del servicio HTTP e incorpora un motor de análisis PHP que también se ejecuta en el entorno limitado SAE. El código del usuario finalmente llama a varios servicios a través de la interfaz.
Centro de estadísticas y centro de registros: responsable de las estadísticas y facturación de recursos de todos los servicios utilizados por los usuarios, y de establecer cuotas de minutos para determinar si existe un uso anormal. Las cuotas de minutos describen la velocidad a la que se consumen los recursos. Cuando la tasa de consumo de recursos alcanza el umbral de advertencia, el sistema de notificación SAE emitirá una advertencia al usuario con anticipación, recordándole que puede haber problemas con el uso de un determinado servicio que requieren atención o procesamiento. El sistema de cuotas es una de las medidas utilizadas por SAE para asegurar la estabilidad de toda la plataforma. El Centro de registros es responsable de recopilar y realizar copias de seguridad de los registros de todos los servicios de los usuarios y de proporcionar servicios de recuperación y consulta.
Varios servicios distribuidos: SAE proporciona una variedad de servicios que cubren aspectos importantes del desarrollo de aplicaciones web, y los usuarios pueden llamarlos fácilmente a través de StdLib (que puede entenderse como la versión SAE PHP de STL). Al mismo tiempo, debido a la diversidad de servicios web, los servicios estándar de SAE no pueden satisfacer las necesidades de todos los escenarios, por lo que SAE también acepta servicios de terceros (como segmentación de palabras y búsqueda de texto completo) a través del bus de servicios. proveedores de servicios externos para elegir a SAE como desarrolladores Proporcionar servicios.
El código de usuario real se ejecuta en el entorno operativo web proporcionado por SAE. Para brindar la seguridad única de la computación en la nube pública, SAE diseñó un entorno de pruebas multicapa para garantizar el aislamiento entre las aplicaciones de los usuarios. Consulte la imagen a continuación:
La capa más interna es el código de usuario. La mayoría del código PHP se puede ejecutar en la plataforma SAE sin ninguna modificación. Es necesario modificar una pequeña parte del código para adaptarlo a las características de la plataforma SAE. Esto se debe principalmente a que SAE ha deshabilitado la IO local por seguridad, por lo que funciones como fwrite deben modificarse para usar TmpFD para leer y escribir archivos temporales locales o leer y escribir directamente nuestro almacenamiento de archivos distribuido a través del servicio de almacenamiento.
PHP Zend es el intérprete PHP oficial estándar.
SAE Zend sandbox es un concepto lógico que proporciona un buen aislamiento para las operaciones de código de los usuarios. Aquí hay dos niveles:
1. A través del php.ini estándar, configuramos algunas funciones de configuración y deshabilitación especiales
2 para lograr lo que php.ini no puede lograr; Algunas capacidades de sandboxing, hicimos algunas mejoras al núcleo del intérprete Zend para aislar recursos por ID de usuario. Además, hemos integrado algunos servicios específicos de SAE en la capa Zend.
Apache es el servidor web Apache estándar. Sin embargo, desactivamos htaccess y proporcionamos nuestra propia alternativa, AppConfig.
Los usuarios pueden escribir AppConfig de forma similar al lenguaje natural, como -compress: if (out_header[content-length]>=500) compress significa iniciar condicionalmente la compresión de la página. AppConfig proporciona las siguientes funciones: página predeterminada del directorio, página de error personalizada, compresión, redirección de página, caducidad de la página, configuración del tipo de contenido del encabezado de respuesta y configuración de permisos de acceso a la página. Otra razón por la que elegimos implementar AppConfig nosotros mismos es que la eficiencia del htaccess tradicional de Apache no puede cumplir con los requisitos de SAE porque debe fusionar recursivamente archivos de configuración por directorio.
El entorno limitado del servidor HTTP proporciona una variedad de funciones de protección para el funcionamiento seguro y confiable de Apache, como evitar que un usuario ocupe conexiones maliciosamente y provocar que todo el servicio web se vuelva anormal.
La capa más externa es el entorno POSIX estándar y nuestros servicios se ejecutan en Linux.
Luego discutiremos en detalle las características de nuestro diseño arquitectónico.
Escalabilidad
La escalabilidad es uno de los dos propósitos principales de los sistemas distribuidos. Como computación en la nube pública, SAE también considera la escalabilidad del servicio como un indicador importante del diseño de la arquitectura, que requiere que los servicios puedan expandirse automáticamente cuando los usuarios crecen y aumenta la presión. De manera similar, cuando se reduce la presión, se pueden contratar servicios para ahorrar recursos y todo el proceso no requiere participación manual. SAE Workforce sólo necesita planificar y gestionar la capacidad. Hay dos formas principales de expandir la arquitectura de computación en la nube pública en el extranjero:
Expansión estática, donde los usuarios y los recursos tienen una fuerte relación vinculante. Los ejemplos más típicos son Heroku, la plataforma de computación en la nube EC2 de Amazon y Ruby. Existe una estricta correspondencia uno a uno entre los recursos aplicados por el usuario y el usuario. En otras palabras, antes de que el usuario A devuelva los recursos, el usuario B no puede utilizar la máquina virtual solicitada por el usuario A, incluso si la máquina virtual del usuario A está inactiva.
Expansión dinámica, no existe una relación vinculante fuerte entre usuarios y recursos. El ejemplo más típico es Google App Engine. No existe una correspondencia estricta uno a uno entre los recursos solicitados por el usuario y el usuario. En otras palabras, el proceso que maneja la solicitud del usuario A puede manejar la solicitud del usuario B inmediatamente después de manejarla.
Ambas extensiones tienen ventajas y desventajas. La ventaja de la extensión estática es que proporciona un buen aislamiento para la plataforma y los recursos se pueden asignar a un determinado usuario. La desventaja es que la utilización de recursos no es alta. La ventaja de la expansión dinámica es la alta utilización de recursos, por lo que el costo de toda la plataforma de computación en la nube será muy bajo. La desventaja es que requiere un alto aislamiento porque varios usuarios pueden utilizar los recursos en un corto período de tiempo. En comparación, en términos de seguridad, el umbral técnico de la expansión dinámica es más alto que el de la expansión estática.
En la plataforma SAE, utilizamos una combinación de expansión dinámica y expansión estática. En la capa del grupo de computación web, es una expansión dinámica típica. Ningún usuario tiene acceso exclusivo al proceso del servicio web, pero todos los usuarios utilizan el proceso del servicio web de una manera * * *. A través del almacenamiento en caché, los usuarios activos ocupan naturalmente más posiciones en la capa de caché. En algunos servicios SAE, la escalabilidad se expresa en forma de expansión estática, como el clúster de bases de datos distribuidas RDC (clúster de bases de datos relacionales). Cuando un usuario solicita el servicio MySQL, crearemos una base de datos maestro-esclavo para el usuario en el backend de RDC según el nivel SLA. Esta base de datos no será utilizada por otros hasta que el usuario la elimine explícitamente. Por supuesto, a través de RDC, ningún usuario necesita conocer la dirección real de la base de datos back-end y solo necesita acceder al host unificado y al puerto de RDC.
Alta confiabilidad
HA es otro propósito principal de los sistemas distribuidos. SAE también considera la alta confiabilidad de los servicios como un indicador importante del diseño arquitectónico. Hay dos formas principales de implementar HA: una es la garantía de hardware y la otra es el diseño de redundancia de arquitectura.
En la plataforma SAE, todos los servidores son equipos de hardware adquiridos según los estándares de Sina. Se ejecutan en las mejores salas de computación del país. La recuperación ante desastres se realiza en múltiples salas de computación, que disfrutan. el entorno de ancho de banda utilizado por el sitio web del portal.
Además, todo el equipo de hardware tiene un departamento de operación y mantenimiento dedicado, y la velocidad de respuesta a fallas es la misma que la del servicio interno de Sina.
En el diseño arquitectónico, SAE proporciona servicios de alta confiabilidad a través del diseño redundante de todos los servicios. Los servicios aquí se pueden dividir en dos categorías: informática y datos:
Para los programas informáticos, el diseño redundante significa que el programa se ejecuta en múltiples nodos. Sin embargo, esto provocará problemas de coherencia. El problema más importante es el problema de la elección, cómo seleccionar un nodo maestro entre varios nodos. Por ejemplo, Cron, un servicio de sincronización distribuida en SAE, adopta un modo de implementación multipunto. Varios nodos informáticos están aislados entre sí. Las tareas de sincronización establecidas por el usuario se activan al mismo tiempo a través del servicio de sincronización de reloj. un nodo es responsable de la ejecución. Para resolver este problema, SAE diseñó un algoritmo de bloqueo distribuido para brindar servicios electorales. Este algoritmo puede proporcionar una mayor confiabilidad que el algoritmo de Paxos a expensas de la coherencia bajo ciertas condiciones (incluso si ocurren tres fallas de máquina en dos máquinas cualesquiera, todo el proceso de elección seguirá siendo normal, mientras que el algoritmo de Paxos puede tolerar hasta 1 máquina). . En 2012,12, este algoritmo está pendiente de patente y se utiliza ampliamente en SAE.
Para los servicios basados en datos, SAE garantiza principalmente una alta confiabilidad de los servicios a través de la replicación. Los servicios de almacenamiento de datos en SAE generalmente utilizan replicación pasiva y replicación activa. Por ejemplo, la sincronización Binlog maestro-esclavo entre MySQL en SAE es una replicación pasiva típica, y servicios como TaskQueue y DeferredJob también usan replicación pasiva. La descripción de la tarea del usuario se escribirá en la cola principal a nivel de memoria, y la cola principal sincronizará la operación de escritura con la cola esclava mediante el uso de un subproceso en segundo plano. Una vez que la cola principal falla, la cola esclava cambiará rápidamente a la cola principal. Además, algunos servicios en SAE utilizan replicación activa (replicación de doble escritura) para garantizar HA, como Cron. Cuando el usuario establece una tarea programada a través del archivo de configuración del proyecto de la aplicación appconfig.yaml, la información de la tarea se escribirá en múltiples bases de datos persistentes en forma de doble escritura para prepararse para la activación posterior.
Además, al diseñar la arquitectura general, SAE consideró plenamente la "degradación elegante" entre servicios y trató de reducir el acoplamiento entre servicios. Solicitamos que ningún servicio asuma que otros servicios son confiables. No existe un diseño de punto único para todos los servicios en la plataforma SAE, y el HA promedio del servicio es 99,95, lo que significa que el tiempo promedio anual de indisponibilidad del servicio es de entre 4 y 5 horas.
Características de la línea
IP de exportación de plataforma:
220.181.129.126
220.181.129.121
220.181.136.229
220.181.136.230
La interfaz HTTP requiere autorización de IP para la configuración correspondiente.