Hogar › Teléfono › ¿Por qué necesitamos escalas horizontales y verticales? Escalabilidad del sistema. Escalado horizontal de servidores de bases de datos para sistemas OLTP, o lo que hay en el mercado

¿Por qué necesitamos escalas horizontales y verticales? Escalabilidad del sistema. Escalado horizontal de servidores de bases de datos para sistemas OLTP, o lo que hay en el mercado

Número de visitantes en constante crecimiento: siempre gran logro para desarrolladores y administradores. Por supuesto, con la excepción de aquellas situaciones en las que el tráfico aumenta tanto que bloquea el servidor web u otro software. Las interrupciones constantes del sitio web siempre resultan muy costosas para la empresa.

Sin embargo, esto se puede solucionar. Y si ahora estás pensando en escalar, estás en el camino correcto.

En pocas palabras, la escalabilidad es la capacidad de un sistema para manejar un gran volumen de tráfico y adaptarse a su crecimiento manteniendo la UX deseada. Hay dos métodos de escalado:

Vertical (también llamado ampliación de escala): aumentar recursos del sistema, como agregar memoria y potencia informática. Este método le permite resolver rápidamente problemas con el procesamiento del tráfico, pero sus recursos pueden agotarse rápidamente.
Horizontal (o escalable): agregar servidores al clúster. Echemos un vistazo más de cerca a este método.

¿Qué es la escala horizontal?

En pocas palabras, un clúster es un grupo de servidores. Un balanceador de carga es un servidor que distribuye carga de trabajo entre servidores en un cluster. En cualquier momento, puede agregar un servidor web a un clúster existente para manejar más tráfico. Ésta es la esencia del escalamiento horizontal.

El equilibrador de carga solo es responsable de decidir qué servidor del clúster procesará la solicitud recibida. Básicamente, funciona como un proxy inverso.

Escalado horizontal- sin duda más método confiable aumentando el rendimiento de la aplicación, pero es más difícil de configurar que escalado vertical. La tarea principal y más difícil en este caso es mantener constantemente actualizados y sincronizados todos los nodos de la aplicación. Digamos que el usuario A envía una solicitud a midominio.com, después de lo cual el equilibrador pasa la solicitud al servidor 1. Luego, la solicitud del usuario B será procesada por el servidor 2.

¿Qué sucede si el usuario A realiza cambios en la aplicación (por ejemplo, carga un archivo o actualiza el contenido de la base de datos)? ¿Cómo se puede transmitir este cambio al resto de servidores del cluster?

La respuesta a estas y otras preguntas se puede encontrar en este artículo.

Separación de servidores

La preparación del sistema para la ampliación requiere separar los servidores; Es muy importante que los servidores con menos recursos tengan menos responsabilidades que los servidores más grandes. Además, dividir la aplicación en dichas "partes" le permitirá identificar rápidamente sus elementos críticos.

Digamos que tiene una aplicación PHP que le permite autenticarse y cargar fotos. La aplicación se basa en la pila LAMP. Las fotos se guardan en el disco y los enlaces a ellas se almacenan en la base de datos. El desafío aquí es admitir la sincronización entre múltiples servidores de aplicaciones que comparten estos datos (archivos cargados y sesiones de usuario).

Para escalar esta aplicación, necesita separar el servidor web y el servidor de base de datos. Así, aparecerán nodos en el clúster que comparten el servidor de base de datos. Esto aumentará el rendimiento de la aplicación al reducir la carga en el servidor web.

En el futuro, podrás configurar el equilibrio de carga; Puedes leer sobre esto en el manual ""

Coherencia de la sesión

Con el servidor web y la base de datos separados, debe concentrarse en manejar las sesiones de los usuarios.

Bases de datos relacionales y sistemas de archivos en red.

Los datos de la sesión a menudo se almacenan en bases de datos relacionales datos (como MySQL), porque dichas bases de datos son fáciles de configurar.

Sin embargo, esta solución no es la más fiable, porque en este caso la carga aumenta. El servidor debe ingresar en la base de datos cada operación de lectura y escritura para cada solicitud separada, y en caso de un aumento repentino del tráfico, la base de datos tiende a fallar antes que otros componentes.

Los sistemas de archivos en red son otra forma sencilla de almacenar datos; no es necesario realizar cambios en la base de datos textos fuente, sin embargo sistemas de red Procesar las operaciones de E/S muy lentamente y esto puede tener un impacto. impacto negativo sobre el rendimiento de la aplicación.

sesiones pegajosas

Las sesiones fijas se implementan en el equilibrador de carga y no requieren ningún cambio en los nodos de la aplicación. Este es el método más conveniente para manejar las sesiones de los usuarios. El equilibrador de carga siempre dirigirá al usuario al mismo servidor, eliminando la necesidad de distribuir datos de sesión entre los nodos restantes del clúster.

Sin embargo, esta solución también tiene un serio inconveniente. Ahora el equilibrador no sólo distribuye la carga, sino que también tiene tarea adicional. Esto puede afectar su rendimiento y provocar que falle.

Servidores Memcached y Redis

También puedes configurar uno o más servidores adicionales para procesar sesiones. Esto es lo mas manera confiable Resolver problemas relacionados con el procesamiento de sesiones.

Acciones finales

Escalar horizontalmente una aplicación parece una solución muy complicada y confusa al principio, pero ayuda a eliminar problemas serios con el tráfico. Lo principal es aprender a trabajar con un equilibrador de carga para comprender qué componentes requieren configuración adicional.

El escalado y el rendimiento de las aplicaciones están muy relacionados. Por supuesto, no todas las aplicaciones y sitios necesitan escalarse. Sin embargo, es mejor pensar en esto con antelación, preferiblemente en la etapa de desarrollo de la aplicación.

Etiquetas: ,

Escalabilidad: la capacidad de un dispositivo para aumentar su
posibilidades
aumentando el número de bloques funcionales,
actuar solo y
las mismas tareas.
Glosario.ru

Generalmente la gente empieza a pensar en escalar cuando uno
el servidor no puede hacer frente al trabajo que se le asigna. ¿Con qué exactamente no está?
¿afrontar? El trabajo de cualquier servidor web se reduce en gran medida a lo básico.
La ocupación de las computadoras es el procesamiento de datos. Respuesta a una solicitud HTTP (o cualquier otra)
Implica realizar algunas operaciones sobre algunos datos. Respectivamente,
Tenemos dos entidades principales: datos (caracterizados por su volumen) y
cálculos (caracterizados por la complejidad). Es posible que el servidor no pueda hacer frente a su
funciona debido a la gran cantidad de datos (es posible que no quepan físicamente en
servidor), o debido a una gran carga informática. La charla aquí es
por supuesto, sobre la carga total: la complejidad de procesar una solicitud puede ser
es pequeño, pero un gran número de ellos puede saturar el servidor.

Hablaremos principalmente de escalado usando un ejemplo.
proyecto web en crecimiento típico, pero los principios descritos aquí también son adecuados para
otras áreas de aplicación. Primero veremos la arquitectura del proyecto y los simples.
su distribucion componentes a varios servidores, y luego hablaremos de
escalar la informática y los datos.

Arquitectura típica del sitio

La vida de un sitio web típico comienza con una arquitectura muy simple.
- este es un servidor web (normalmente Apache desempeña su función),
que maneja todo el trabajo de atender solicitudes HTTP,
recibido de los visitantes. Ofrece a los clientes lo que llama "estática", luego
hay archivos en el disco del servidor que no requieren procesamiento: imágenes (gif,
jpg, png), hojas de estilo (css), scripts de cliente (js, swf). Mismo servidor
responde consultas que requieren cálculos, generalmente formando
páginas html, aunque a veces las imágenes y otros documentos se crean sobre la marcha.
La mayoría de las veces, las respuestas a dichas solicitudes se generan mediante scripts escritos en PHP,
Perl u otros lenguajes.

La desventaja de un esquema de trabajo tan simple es que diferentes
naturaleza de las solicitudes (carga de archivos desde el disco y trabajo computacional guiones)
procesado por el mismo servidor web. Las consultas computacionales requieren
mantener mucha información en la memoria del servidor (intérprete de lenguaje de escritura,
los propios scripts, los datos con los que trabajan) y pueden ocupar mucho
recursos computacionales. La emisión de datos estáticos, por el contrario, requiere pocos recursos.
procesador, pero puede ocupar por mucho tiempo, si el cliente tiene baja
velocidad de comunicación. Estructura interna servidor apache supone que cada
la conexión se maneja mediante un proceso separado. Esto es conveniente para ejecutar scripts,
sin embargo no es óptimo para el procesamiento consultas simples. Resulta que pesado (de
scripts y otros datos) Los procesos de Apache pasan mucho tiempo esperando (primero cuando reciben
solicitud, luego al enviar una respuesta), desperdiciando memoria del servidor.

La solución a este problema es distribuir el trabajo de procesamiento.
solicitudes entre dos diferentes programas- es decir. división en frontend y
backend Un servidor frontend liviano realiza las tareas de servir contenido estático y el resto
las solicitudes se redirigen (proxy) al backend, donde se realiza la formación
páginas. La interfaz también se encarga de la espera de clientes lentos, y si utiliza
multiplexación (cuando un proceso sirve a varios clientes, por lo que
funciona, por ejemplo, nginx o lighttpd), entonces la espera es prácticamente nada
costos.

Entre otros componentes del sitio, cabe destacar la base de datos, en
que generalmente almacena los datos principales del sistema; los más populares aquí son
DBMS MySQL y PostgreSQL gratuitos. El almacenamiento a menudo se asigna por separado
archivos binarios, que contiene imágenes (por ejemplo, ilustraciones para artículos
sitio, avatares y fotos de usuarios) u otros archivos.

Por lo tanto, recibimos un diagrama de arquitectura que consta de
varios componentes.

Normalmente, al comienzo de la vida de un sitio, todos los componentes de la arquitectura
ubicado en el mismo servidor. Si deja de hacer frente a la carga, entonces
hay una solución simple: mover las partes que se separan más fácilmente a otra
servidor. La forma más sencilla de comenzar con una base de datos es moverla a un servidor separado y
cambiar los detalles de acceso en los scripts. Por cierto, en este momento nos enfrentamos a
La importancia de una arquitectura adecuada. código de programa. Si trabaja con una base de datos
presentado a módulo separado, común para todo el sitio; luego corrija los parámetros
las conexiones serán fáciles.

Las formas de separar aún más los componentes también son claras; por ejemplo, puede mover la interfaz a un servidor separado. Pero normalmente la interfaz
requiere pocos recursos del sistema y en esta etapa su eliminación no proporcionará significativa
ganancias de productividad. La mayoría de las veces, el sitio está limitado por el rendimiento.
scripts: generar una respuesta (página html) requiere demasiado por mucho tiempo.
Por lo tanto, el siguiente paso suele ser escalar el servidor backend.

Distribución de cálculo

Una situación típica de un sitio en crecimiento: la base de datos ya está
movido a una máquina separada, se completa la división en frontend y backend,
sin embargo, el tráfico continúa aumentando y el backend no tiene tiempo para procesar
solicitudes. Esto significa que necesitamos distribuir los cálculos entre varios
servidores. Esto es fácil de hacer: simplemente compre un segundo servidor e instálelo en
Contiene programas y scripts necesarios para que funcione el backend.
Después de esto, debe asegurarse de que las solicitudes de los usuarios se distribuyan
(equilibrado) entre los servidores recibidos. ACERCA DE de diferentes maneras equilibrio
Se discutirá a continuación, pero por ahora observamos que esto generalmente lo hace la interfaz,
que está configurado para distribuir uniformemente las solicitudes entre
servidores.

Es importante que todos los servidores backend sean capaces de ejecutar correctamente
responder a las solicitudes. Esto generalmente requiere que cada uno de ellos trabaje con
el mismo conjunto de datos actualizados. Si almacenamos toda la información en un solo
base de datos, entonces el propio DBMS proporcionará intercambio y coherencia de los datos.
Si algunos datos se almacenan localmente en el servidor (por ejemplo, sesiones php
cliente), entonces deberías pensar en transferirlos a almacenamiento compartido, o sobre más
Algoritmo complejo de distribución de solicitudes.

No sólo el trabajo se puede distribuir entre varios servidores
scripts, sino también cálculos realizados por la base de datos. Si el DBMS funciona mucho
consultas complejas, que consumen tiempo de CPU del servidor, puede crear varias
copias de la base de datos en diferentes servidores. Esto plantea el problema de la sincronización.
datos cuando cambian, y varios enfoques son aplicables aquí.

Sincronización a nivel de aplicación. En este caso nuestro
Los scripts escriben cambios de forma independiente en todas las copias de la base de datos (y ellos mismos llevan
responsabilidad por la veracidad de los datos). esto no es mejor opción porque el
requiere cuidado en la implementación y es altamente tolerante a errores.
Replicación- es decir, replicación automática
Los cambios realizados en un servidor afectan a todos los demás servidores. Generalmente cuando
Cuando se utiliza la replicación, los cambios siempre se escriben en el mismo servidor: se llama maestro y las copias restantes se llaman esclavas. La mayoría de los DBMS tienen
incorporado o fondos externos para organizar la replicación. Distinguir
replicación sincrónica: en este caso, una solicitud para cambiar datos esperará
hasta que los datos se copien a todos los servidores, y solo entonces se completará exitosamente - y de forma asincrónica - en este caso, los cambios se copian a los servidores esclavos desde
retraso, pero la solicitud de escritura se completa más rápido.
multimaestro replicación. Este enfoque es similar
el anterior, pero aquí podemos cambiar los datos sin acceder
un servidor específico, sino a cualquier copia de la base de datos. Al mismo tiempo, cambios
de forma sincrónica o asincrónica se transferirá a otras copias. A veces este esquema se llama
el término "clúster de bases de datos".

Posible diferentes opciones Distribución del sistema entre servidores.
Por ejemplo, podemos tener un servidor de base de datos y varios backends (muy
esquema típico), o viceversa: un backend y varias bases de datos. ¿Y si escalamos?
tanto el servidor backend como la base de datos, luego puede combinar el backend y una copia de la base de datos en
un auto. En cualquier caso, en cuanto tengamos varios ejemplares
cualquier servidor, surge la pregunta de cómo distribuir correctamente entre ellos
carga.

Métodos de equilibrio

Creemos varios servidores (para cualquier propósito: http, base de datos, etc.), cada uno de los cuales puede procesar solicitudes. Antes
Nos enfrentamos a la tarea de cómo distribuir el trabajo entre ellos, cómo saber qué
¿El servidor envía una solicitud? Hay dos formas principales de distribuir solicitudes.

Unidad de equilibrio. En este caso, el cliente envía una solicitud a uno
un servidor fijo conocido por él, y ya redirige la solicitud a uno de
servidores en funcionamiento. Un ejemplo típico es un sitio con una interfaz y varios
Servidores backend a los que se envían las solicitudes. Sin embargo, el "cliente" puede
estar dentro de nuestro sistema; por ejemplo, un script puede enviar una solicitud a
a un servidor proxy de base de datos que pasará la solicitud a uno de los servidores DBMS.
El nodo de equilibrio en sí puede funcionar tanto en un servidor separado como en uno
de servidores en funcionamiento.
Las ventajas de este enfoque son
que el cliente no necesita saber nada estructura interna sistemas - sobre cantidad
servidores, sobre sus direcciones y características - sólo el
balancín Sin embargo, la desventaja es que la unidad de equilibrio es una sola
punto de falla del sistema: si falla, todo el sistema será destruido.
inoperante. Además, cuando carga pesada el equilibrador puede simplemente detenerse
hacer frente a su trabajo, por lo que este enfoque no siempre es aplicable.
Equilibrio del lado del cliente. Si queremos evitar
existe un único punto de falla opción alternativa- confiar la selección del servidor
al propio cliente. En este caso, el cliente debe conocer la estructura interna de nuestro
sistemas para poder elegir correctamente con qué servidor contactar.
Una ventaja indudable es la ausencia de un punto de fallo: si uno de los
servidores el cliente podrá contactar con otros. Sin embargo, el precio por esto es
Lógica de cliente más compleja y menos flexibilidad de equilibrio.

Por supuesto, también existen combinaciones de estos enfoques. Por ejemplo,
semejante método conocido El equilibrio de carga, al igual que el equilibrio de DNS, se basa en
que al determinar la dirección IP de un sitio, se le da al cliente
la dirección de uno de varios servidores idénticos. Así, el DNS actúa como
el papel del nodo de equilibrio del que el cliente recibe la “distribución”. Sin embargo
La estructura misma de los servidores DNS implica la ausencia de un punto de falla debido a
duplicación, es decir, se combinan las ventajas de dos enfoques. Por supuesto, este
El método de equilibrio también tiene desventajas; por ejemplo, un sistema de este tipo es difícil de equilibrar dinámicamente.
reconstruir.

Por lo general, trabajar con un sitio no se limita a una sola solicitud.
Por lo tanto, al diseñar, es importante comprender si las consultas secuenciales pueden
El cliente debe ser procesado correctamente por diferentes servidores, o el cliente debe ser
vinculado a un servidor mientras trabaja con el sitio. Esto es especialmente importante si
el sitio almacena información temporal sobre la sesión del usuario (en este caso
En este caso también es posible la distribución gratuita, pero entonces es necesario almacenar
sesiones (almacenamiento común a todos los servidores). “Atar” al visitante a
puede especificar un servidor específico por su dirección IP (que, sin embargo, puede cambiar),
o mediante cookie (en la que queda pregrabado el identificador del servidor), o incluso
simplemente redirigiéndolo al dominio deseado.

Por otro lado, es posible que los servidores informáticos no tengan los mismos derechos.
En algunos casos, es ventajoso hacer lo contrario, asignar un servidor separado para
procesar solicitudes de un tipo y obtener una división vertical
funciones. Luego, el cliente o el nodo de equilibrio seleccionará el servidor en
dependiendo del tipo de solicitud recibida. Este enfoque nos permite separar
Solicitudes importantes (o viceversa, no críticas, pero sí difíciles) de otros.

Distribución de datos

Hemos aprendido a distribuir cálculos, por lo que una gran cantidad
La asistencia no es un problema para nosotros. Sin embargo, los volúmenes de datos siguen creciendo,
almacenarlos y procesarlos es cada vez más difícil, lo que significa que es hora de construir
almacenamiento de datos distribuidos. En este caso ya no tendremos uno o
varios servidores que contienen copia completa bases de datos. En cambio, los datos
se distribuirá según diferentes servidores. ¿Qué esquemas de distribución son posibles?

Distribución vertical(partición vertical) - en el caso más simple
representa la transferencia de tablas de bases de datos individuales a otro servidor. En
En este caso, necesitaremos cambiar los scripts para acceder a diferentes servidores para
datos diferentes. Como límite, podemos almacenar cada tabla en un servidor separado.
(aunque en la práctica es poco probable que esto resulte beneficioso). Obviamente con esto
distribución, perdemos la capacidad de realizar consultas SQL que combinen datos de
dos mesas ubicadas en diferentes servidores. Si es necesario, puede implementar
fusionar lógica en la aplicación, pero no será tan eficiente como en un DBMS.
Por lo tanto, al particionar una base de datos, es necesario analizar las relaciones entre tablas,
distribuir tablas lo más independientes posible.
Caso más complejo
La distribución de base vertical es una descomposición de una tabla cuando parte
algunas de sus columnas terminan en un servidor y otras terminan en otro. esta técnica
es menos común, pero se puede utilizar, por ejemplo, para separar pequeñas
y datos actualizados con frecuencia a partir de un gran volumen de datos que rara vez se utilizan.
Distribución horizontal(partición horizontal) - consta de
distribuir datos de una tabla en varios servidores. De hecho, en
cada servidor crea una tabla de la misma estructura y almacena
un determinado dato. Puede distribuir datos entre servidores de diferentes maneras
criterios: por rango (registros con id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
A, el resto, al servidor B) o por el valor hash de un determinado campo
archivos. La partición horizontal de datos le permite almacenar datos ilimitados
el número de registros, sin embargo, complica la selección. La forma más efectiva de elegir.
registros sólo cuando se sabe en qué servidor están almacenados.

Para la selección esquema correcto la distribución de datos es necesaria
Analice cuidadosamente la estructura de la base de datos. Tablas existentes (y posiblemente
campos individuales) se pueden clasificar según la frecuencia de acceso a los registros, según la frecuencia
actualizaciones y relaciones (la necesidad de hacer selecciones entre varios
tablas).

Como se mencionó anteriormente, además de una base de datos, un sitio a menudo necesita
Almacenamiento de archivos binarios. Sistemas distribuidos almacenamiento de archivos
(en realidad, sistemas de archivos) se pueden dividir en dos clases.

Laboral en el nivel Sistema operativo . Además, para
Las aplicaciones que trabajan con archivos en un sistema de este tipo no son diferentes de trabajo regular Con
archivos. El intercambio de información entre servidores lo gestiona el sistema operativo.
Ejemplos de tales sistemas de archivos incluyen el conocido desde hace mucho tiempo
Familia NFS o menos conocida, pero más sistema moderno Lustre.
Implementado a nivel de aplicación repartido
Los repositorios implican que el trabajo de intercambio de información lo realiza él mismo.
solicitud. Por lo general, las funciones para trabajar con el almacenamiento se colocan en
biblioteca separada. Uno de los ejemplos sorprendentes de este tipo de almacenamiento es MogileFS, desarrollado por
por los creadores de LiveJournal. Otro ejemplo común es el uso
Protocolo WebDAV y su almacenamiento compatible.

Cabe señalar que la distribución de datos decide no sólo
una cuestión de almacenamiento, pero también, en parte, de distribución de la carga, en cada
el servidor se convierte menos entradas, y por tanto se procesan más rápido.
La combinación de métodos para distribuir cálculos y datos permite construir
arquitectura potencialmente escalable ilimitadamente capaz de trabajar con
cualquier cantidad de datos y cualquier carga.

Conclusiones

Para resumir lo dicho, formulemos conclusiones en forma de breves tesis.

Los dos desafíos de escalamiento principales (y relacionados) son la distribución informática y la distribución de datos.
La arquitectura típica de un sitio implica la separación de roles y
Incluye frontend, backend, base de datos y, a veces, almacenamiento de archivos.
Si no grandes volúmenes datos y cargas pesadas aplicar
Duplicación de bases de datos: replicación sincrónica o asincrónica.
Para grandes cantidades de datos, es necesario distribuir la base de datos: dividir
es vertical u horizontal
Los binarios se almacenan en sistemas de archivos distribuidos
(implementado a nivel del sistema operativo o en la aplicación)
El equilibrio (distribución de solicitudes) puede ser uniforme o
dividido por funcionalidad; con un nodo de equilibrio, o en el lado del cliente
La combinación correcta de métodos le permitirá soportar cualquier carga;)

Campo de golf

Puedes seguir estudiando este tema en interesantes sitios y blogs en inglés.

¡Hola! Soy Alexander Makarov y quizás me conozcas por el marco Yii: soy uno de sus desarrolladores. También tengo un trabajo de tiempo completo (y esto ya no es una startup): Stay.com, que se ocupa de viajes.

Hoy hablaré de escalamiento horizontal, pero en términos muy, muy generales.

¿Qué es escalar? Esta es una oportunidad para aumentar la productividad del proyecto para tiempo minimo añadiendo recursos.

Normalmente, escalar no implica reescribir código, sino agregar servidores o aumentar los recursos de uno existente. Este tipo incluye escalado vertical y horizontal.

Vertical es cuando se agrega más RAM, discos, etc. ya encendido servidor existente, y horizontal es cuando ponen más servidores a los centros de datos, y los servidores allí ya interactúan de alguna manera.

La mejor pregunta que hacen es: ¿por qué es necesario si todo funciona bien para mí en un servidor? De hecho, necesitamos comprobar qué sucederá. Es decir, funciona ahora, pero ¿qué pasará después? Hay dos utilidades maravillosas: ab y siege, que parecen alcanzar a una nube de usuarios de la competencia que comienzan a dañar el servidor, intentan solicitar páginas y enviar algunas solicitudes. Tienes que decirles qué hacer y las utilidades generan informes como este:

Los dos parámetros principales: n - el número de solicitudes que deben realizarse, c - el número de solicitudes simultáneas. De esta manera controlan la competencia.

En la salida obtenemos RPS, es decir la cantidad de solicitudes por segundo que el servidor es capaz de procesar, a partir de lo cual quedará claro cuántos usuarios puede manejar. Todo, por supuesto, depende del proyecto, varía, pero normalmente requiere atención.

Hay un parámetro más, el tiempo de respuesta, el tiempo de respuesta durante el cual el servidor sirvió una página en promedio. Varía, pero se sabe que unos 300 ms es la norma, y algo superior no es muy bueno, porque estos 300 ms los procesa el servidor, y a esto se le suman otros 300-600 ms, que son procesados por el cliente. , es decir. Mientras todo se carga (estilos, imágenes y demás) el tiempo también pasa.

Sucede que, de hecho, todavía no hay necesidad de preocuparse por la escala: vamos al servidor, actualizamos PHP, obtenemos un aumento del 40% en el rendimiento y todo está bien. A continuación, configuramos Opcache y lo ajustamos. Opcache, por cierto, está configurado de la misma manera que APC, con un script que se puede encontrar en el repositorio de Rasmus Lerdorf y que muestra aciertos y errores, dónde son cuántos aciertos. veces PHP fue al efectivo, y misa - cuantas veces fue al sistema de archivos obtener archivos. Si ejecutamos todo el sitio, o ejecutamos algún tipo de rastreador en los enlaces, o lo pinchamos manualmente, tendremos estadísticas sobre estos aciertos y errores. Si hay 100% de aciertos y 0% de fallos, entonces todo está bien, pero si hay fallos, entonces debes resaltar más memoria para que todo nuestro código encaje en Opcache. Este error común, lo cual admiten: parece que Opcache está ahí, pero algo no funciona...

También suelen empezar a escalar, pero no se fijan en ello en absoluto, por lo que todo funciona lentamente. La mayoría de las veces vamos a la base de datos, miramos, no hay índices, ponemos índices, todo funciona de inmediato, suficiente para otros 2 años, ¡belleza!

Bueno, también necesitas habilitar el caché, reemplazar apache con nginx y php-fpm para ahorrar memoria. Todo será genial.

Todo lo anterior es bastante simple y le da tiempo. Hay tiempo para que algún día esto no sea suficiente, y debemos prepararnos para ello ahora.

¿Cómo, en general, se puede entender cuál es el problema? O ya tiene una carga alta, y esto no es necesariamente una gran cantidad de solicitudes, etc., es cuando su proyecto no puede hacer frente a la carga y esto ya no se puede resolver de manera trivial. Necesitas crecer más o más. Hay que hacer algo y, muy probablemente, hay poco tiempo para ello;

La primera regla es que nunca debes hacer nada a ciegas, es decir. Necesitamos un seguimiento excelente. Primero, ganamos tiempo en algunas optimizaciones obvias, como habilitar un caché o almacenar en caché la página de inicio, etc. Luego configuramos el monitoreo, nos muestra lo que falta. Y todo esto se repite muchas veces: nunca se puede dejar de monitorear y mejorar.

¿Qué puede mostrar el seguimiento? Podemos apoyarnos contra el disco, es decir. al sistema de archivos, a la memoria, al procesador, a la red… Y puede que todo parezca más o menos, pero aparezcan algunos errores. Todo esto se resuelve de diferentes maneras. Puede resolver un problema con, por ejemplo, un disco agregando un disco nuevo al mismo servidor, o puede instalar un segundo servidor que se ocupe únicamente de archivos.

¿A qué debería prestar atención en este momento durante el seguimiento? Este:

accesibilidad, es decir si el servidor está vivo o no;
falta de recursos de disco, procesador, etc.;
errores.

¿Cómo monitorear todo esto?

Aquí hay una lista de excelentes herramientas que le permiten monitorear recursos y mostrar los resultados de una manera muy conveniente:

Las primeras 4 herramientas se pueden instalar en el servidor, son potentes y geniales. Y ServerDensity está alojado por alguien, es decir. Pagamos dinero por ello y puede recopilar todos los datos de los servidores y mostrarlos para su análisis.

Hay dos buenos servicios para el seguimiento de errores:

Por lo general, monitoreamos errores como este: o escribimos todo en el registro y luego lo miramos, o además comenzamos a enviar correos electrónicos o SMS a los desarrolladores. Todo esto es normal, pero tan pronto como tenemos una multitud de personas. viene al servicio, y hay algún tipo de error, comienza a repetirse muy gran número Una vez, el correo electrónico comienza a enviar spam con locura, o se llena por completo, o el desarrollador pierde completamente la atención y comienza a ignorar los correos electrónicos. Los servicios anteriores toman y recopilan errores del mismo tipo en un paquete grande, además cuentan cuántas veces ocurrieron los errores durante últimamente y todo el asunto se plantea automáticamente en las prioridades.

Sentry se puede instalar en su servidor, hay un código fuente, pero Rollbar no, pero Rollbar es mejor porque cobra dinero por la cantidad de errores, es decir. les anima a corregirlos.

En cuanto a las notificaciones, repito que no debes hacer spam, ya que se perderá tu atención.

¿Qué es, en general, necesario analizar?

RPS y tiempo de respuesta: si nuestro tiempo de respuesta comienza a disminuir, entonces debemos hacer algo.

La cantidad de procesos, subprocesos y tamaños de colas: si todo comienza a multiplicarse, obstruirse, etc., entonces algo anda mal aquí nuevamente, debemos analizarlo con más detalle y cambiar de alguna manera la infraestructura.

También vale la pena mirar el análisis empresarial. Google Analytics Es excelente para tipos de sitios web y mixpanel es excelente para registrar eventos. Funciona en aplicaciones de escritorio, aplicaciones móviles y la web. Puedes escribir basándose en algunos de tus propios datos, pero te aconsejaría servicios listos para usar. El punto es que nuestro monitoreo puede mostrar que el servicio está activo, que todo está funcionando, que el tiempo de respuesta general es normal, pero cuando, digamos, comenzamos a rastrear registros en mixpanel, muestra que de alguna manera no hay suficientes. En este caso, es necesario observar qué tan rápido se procesan ciertos eventos y páginas, y cuáles son los problemas. El proyecto siempre debe estar "colgado" del análisis para saber siempre lo que está sucediendo y no trabajar a ciegas.

La carga, en general, surge planificada o no, puede surgir de forma paulatina o no de forma paulatina:

¿Cómo lidiar con la carga? Las empresas lo deciden todo y sólo importa el precio de la emisión. Importante:

para que el servicio funcione,
para que no sea muy caro y no arruine la empresa.

El resto no es muy importante.

Si es más barato crear perfiles, optimizar, escribir en caché, corregir algunas configuraciones, entonces esto debe hacerse sin pensar en escalar o comprar hardware adicional, etc. Pero sucede que el hardware resulta más barato que el trabajo de un programador, especialmente si los programadores son muy expertos. En este caso, el escalado ya comienza.

En la imagen, lo azul es Internet de donde provienen las solicitudes. Se instala un equilibrador, cuya única tarea es distribuir solicitudes a servidores front-end separados, aceptar respuestas de ellos y enviarlas al cliente. El punto aquí es que 3 servidores pueden procesar (idealmente) 3 veces más solicitudes, excluyendo los costos generales de la red y el trabajo del propio equilibrador.

¿Qué nos aporta esto? La capacidad mencionada anteriormente para procesar más solicitudes, así como la confiabilidad. Si en el esquema tradicional nginx o una aplicación falla, o el disco tiene problemas, etc., entonces todo se detiene. Aquí, si una interfaz se ha caído, entonces está bien, lo más probable es que el equilibrador comprenda esto y envíe solicitudes a los 2 servidores restantes. Puede que sea un poco más lento, pero eso no es gran cosa.

En general, PHP es excelente para escalar porque sigue el principio No compartir nada de forma predeterminada. Esto significa que si tomamos, digamos, Java para la web, entonces la aplicación se inicia allí, lee todo el código, escribe la mayor cantidad de datos posible en la memoria del programa, todo gira allí, funciona, se dedica muy poco tiempo a la solicitud. , muy poco recursos adicionales. Sin embargo, hay una emboscada, porque. La aplicación está escrita de tal manera que debe ejecutarse en una instancia, almacenarse en caché, leerse desde su propia memoria y luego no obtendrá nada bueno al escalar. Pero en PHP no hay nada común por defecto, y eso es bueno. Todo lo que queremos compartir lo ponemos en Memcached, y Memcached se puede leer desde varios servidores, por lo que todo es fantástico. Aquellos. Se logra un acoplamiento flexible para la capa del servidor de aplicaciones. Esto es maravilloso.

¿Cómo equilibrar la carga en general?

La mayoría de las veces esto lo hacía Squid o HAProxy, pero eso fue antes. Ahora el autor de nginx tomó y dividió el balanceador de nginx+ en nginx, por lo que ahora puede hacer todo lo que solían hacer Squid o HAProxy. Si comienza a fallar, puede instalar algún costoso equilibrador de hardware.

Los problemas que resuelve el balanceador son ¿cómo elegir un servidor y cómo almacenar las sesiones? El segundo problema es puramente PHP, y los servidores se pueden seleccionar uno por uno de la lista, o según la geografía de algunas IP, o según algunas estadísticas (nginx admite menos conexiones, es decir, qué servidor tiene menos conexiones, arrojará sobre él). Podemos escribir un código para el equilibrador que elegirá cómo debería funcionar.

¿Y si chocamos con un equilibrador?

Existe el DNS Round Robin: este es un truco maravilloso que nos permite no gastar dinero en un equilibrador de hardware. ¿Qué estamos haciendo? Tomamos un servidor DNS (normalmente nadie aloja un servidor DNS, es caro, no muy confiable, si falla, no saldrá nada bueno, todos usan algún tipo de empresa), registramos más de un servidor en el registro A. , pero unos pocos. Estos serán registros A de diferentes balanceadores. Cuando el navegador va allí (de hecho, no hay garantías, pero todo navegadores modernos así es como funcionan), selecciona una dirección IP de los registros A y termina en un equilibrador o en el segundo. Por supuesto, es posible que la carga no se distribuya uniformemente, pero al menos se distribuye y el equilibrador puede soportar un poco más.

¿Qué hacer con las sesiones?

Las sesiones están en nuestros archivos de forma predeterminada. Este no es el caso, porque cada uno de nuestros servidores front-end mantendrá sesiones en su propio sistema de archivos, y el usuario puede ir primero a uno, luego al segundo, luego al tercero, es decir. perderá sesiones cada vez.

Existe un deseo obvio de crear un sistema de archivos común y conectar NFS. Pero no es necesario que hagas eso: es terriblemente lento.

Puedes escribirlo en la base de datos, pero tampoco vale la pena, porque La base de datos no es óptima para este trabajo, pero si no tiene otra opción, en principio servirá.

Puedes escribir en Memcached, pero con mucho, mucho cuidado, porque Memcached es, después de todo, un caché y tiende a borrarse tan pronto como tiene pocos recursos, o no hay ningún lugar para escribir nuevas claves, entonces comienza a perderse. Los viejos sin previo aviso, las sesiones comienzan a perderse. Debe monitorear esto o elegir el mismo Redis.

Redis - solución normal. El punto es que tenemos Redis en un servidor separado, y todas nuestras interfaces se apresuran allí y comienzan a leer sus sesiones desde Redis, pero Redis tiene un solo subproceso y, tarde o temprano, podemos meternos en problemas. Se instala el mismo nginx y se le informa que necesita realizar una sesión para que cuando el usuario acceda al servidor y reciba una cookie de sesión, posteriormente acceda únicamente a este servidor. En la mayoría de los casos, esto se realiza mediante hash de IP. Resulta que si Redis está en cada instancia, habrá sesiones allí y el rendimiento de lectura y escritura será mucho mejor.

¿Qué tal las galletas? Puede escribir en cookies, no habrá almacenamiento, todo está bien, pero, en primer lugar, todavía necesitamos colocar los datos de la sesión en algún lugar, y si comenzamos a escribir en cookies, es posible que crezca y no quepa en el almacenamiento, pero, en segundo lugar, solo puede almacenar ID en cookies y aún tendremos que comunicarnos con la base de datos para obtener algunos datos de la sesión. En principio esto es normal, soluciona el problema.

Hay algo interesante: un proxy para Memcached y Redis:

Parecen admitir la paralelización desde el primer momento, pero lo hacen de una manera que no diría que sea muy óptima. Pero esta cosa, twemproxy, funciona aproximadamente como nginx con PHP, es decir. en cuanto recibe la respuesta inmediatamente envía los datos y cierra la conexión en segundo plano, resulta más rápido y consume menos recursos. Muy bueno.

Muy a menudo, este error de “ciclismo” ocurre cuando comienzan a escribir, como “¡No necesito sesiones! Ahora haré una maravillosa ficha que será transferida de un lado a otro”... Pero, si lo piensas bien, esto es nuevamente una sesión.

PHP tiene un mecanismo como un controlador de sesión, es decir. podemos poner nuestro propio controlador y escribir en cookies, en la base de datos, en Redis, en cualquier lugar, y todo esto funcionará con el inicio de sesión estándar, etc.

Las sesiones deben cerrarse utilizando este maravilloso método.

En cuanto hayamos leído todo de la sesión, no vamos a escribir ahí, hay que cerrarla, porque muchas veces la sesión está bloqueada. De hecho, debería bloquearse, porque sin bloqueo habrá problemas con la competencia. Esto es inmediatamente visible en los archivos; en otros almacenamientos, los bloqueadores no están disponibles para todo el archivo a la vez, y esto es un poco más fácil.

¿Qué hacer con los archivos?

Puedes lidiar con ellos de dos maneras:

Alguna solución especializada que proporciona una abstracción y trabajamos con archivos como un sistema de archivos. Es algo así como NFS, pero no es necesario.
“fragmentar” usando PHP.

Las soluciones especializadas de las que realmente funcionan son GlusterFS. Esto es algo que puedes configurar tú mismo. Funciona, es rápido, ofrece la misma interfaz que NFS, sólo que funciona a una velocidad normal tolerable.

Y Amazon S3 es, si estás en la nube de Amazon, también un buen sistema de archivos.

Si está implementando desde el lado de PHP, hay una maravillosa biblioteca Flysystem, cubierta con excelentes pruebas, que puede usarse para trabajar con todo tipo de sistemas de archivos, lo cual es muy conveniente. Si escribe inmediatamente todo el trabajo con archivos con esta biblioteca, la transferencia desde el sistema de archivos local a Amazon S3 u otros será simple: reescriba la línea en la configuración.

¿Cómo funciona esto? Un usuario descarga un archivo desde un navegador, puede ir al frontend y desde allí distribuirse entre servidores de archivos, o en cada servidor de archivos Se crea un script de carga y el archivo se carga directamente al sistema de archivos. Bueno, en paralelo, se escribe en la base de datos qué archivo está en qué servidor, y podemos leerlo directamente desde allí.

Es mejor distribuir archivos con nginx o Varnish, pero es mejor hacer todo con nginx, porque a todos nos encanta y lo usamos; puede manejarlo, es bueno.

¿Qué está pasando con nuestra base de datos?

Si todo se reduce al código PHP, creamos un montón de interfaces y aun así recurrimos a una base de datos; funcionará durante bastante tiempo. Si la carga no es terrible, entonces la base de datos funciona bien. Por ejemplo, hicimos JOINs de 160 millones de filas en una tabla, y todo fue genial, todo funcionó bien, pero allí, sin embargo, se debería asignar más RAM a los buffers, al caché...

¿Qué hacer con la base de datos si nos topamos con ella? Existen técnicas como la replicación. Por lo general, se realiza la replicación maestro-esclavo y existe una replicación maestro-maestro. Puede realizar la replicación manualmente, puede fragmentar y particionar.

¿Qué es un amo-esclavo?

Se selecciona un servidor como principal y varios servidores como secundarios. Se escribe en el principal, y podemos leer desde el maestro, o también podemos hacerlo desde los esclavos (en la imagen las flechas rojas son las que escribimos, las verdes son las que leemos). En un proyecto típico, tenemos muchas más lecturas que escrituras. Hay proyectos atípicos.

En el caso de un proyecto típico, una gran cantidad de esclavos permite aliviar tanto al maestro como, en general, aumentar la velocidad de lectura.

Esto también proporciona tolerancia a fallos: si uno de los esclavos falla, no es necesario hacer nada. Si el maestro cae, rápidamente podemos convertir a uno de los esclavos en maestro. Es cierto que esto generalmente no se hace automáticamente, se trata de una situación de emergencia, pero existe la posibilidad.

Bueno, y copias de seguridad. Cada uno hace copias de seguridad de la base de datos de manera diferente, a veces esto se hace con un volcado de MySQL y congela todo el proyecto, lo cual no es muy bueno. Pero si haces una copia de seguridad de algún esclavo, habiéndolo detenido primero, el usuario no notará nada. Esto es maravilloso.

Además, se pueden realizar cálculos pesados en los esclavos para no afectar la base principal, el proyecto principal.

Existe la división de lectura/escritura. Hay 2 grupos de servidores: maestro, esclavo, conexión bajo demanda y la lógica de selección de conexión varía. El punto es que si siempre leemos de los esclavos y siempre escribimos al maestro, entonces habrá una pequeña emboscada:

aquellos. la replicación no es inmediata y no hay garantía de que se haya completado cuando realizamos cualquier solicitud.

Hay dos tipos de muestras:

para lectura o salida;
para grabar, es decir, cuando hemos seleccionado algo y luego es necesario cambiarlo y volver a escribirlo.

Si la muestra es para escritura, entonces siempre podemos leer desde el maestro y escribir en el maestro, o podemos ejecutar "MOSTRAR ESTADO DEL ESCLAVO" y mirar Seconds_Behind_Master allí (para PostgreSQL también hay una superconsulta en la imagen) - nos mostrará el número. Si es 0 (cero), entonces todo ya se ha replicado y se puede leer con seguridad desde el esclavo. Si el número es mayor que cero, entonces debemos mirar el valor; debemos esperar un poco y luego leer desde el esclavo, o leer inmediatamente desde el maestro. Si tenemos NULL, significa que aún no lo hemos replicado, algo está atascado y debemos mirar los registros.

Las razones de tal retraso son una red lenta, una réplica no puede hacer frente o demasiados esclavos (más de 20 por 1 maestro). Si la red es lenta, entonces está claro que de alguna manera es necesario acelerarla, recopilarla en centros de datos únicos, etc. Si una réplica falla, deberá agregar réplicas. Si hay demasiados esclavos, entonces necesitas pensar en algo interesante, lo más probable es que cree algún tipo de jerarquía.

¿Qué es un maestro artesano?

Esta es una situación en la que hay varios servidores y todo está escrito y leído en todas partes. La ventaja es que puede ser más rápido y es tolerante a fallos. En principio, todo es igual que para los esclavos, pero la lógica es generalmente simple: simplemente seleccionamos una conexión aleatoria y trabajamos con ella. Desventajas: el retraso de replicación es mayor, existe la posibilidad de obtener algún tipo de datos inconsistentes y, si ocurre algún tipo de falla, comienza a extenderse a todos los maestros y nadie sabe qué maestro es normal, cuál es roto... Todo esto comienza a replicarse a través del círculo, es decir. Obstruye muy bien la red. En general, si tuvieras que hacer un master-master, tendrás que pensarlo 100 veces. Lo más probable es que puedas arreglártelas con un maestro-esclavo.

Siempre puedes hacer la replicación manualmente, es decir. organiza un par de conexiones y escribe en 2, 3 a la vez, o haz algo en segundo plano.

¿Qué es la fragmentación?

De hecho, esto está distribuyendo datos entre varios servidores. puedes fragmentar mesas separadas. Tomemos, por ejemplo, una tabla de fotografías, una tabla de usuarios, etc., y colóquelas en servidores separados. Si las tablas eran grandes, entonces todo se vuelve más pequeño, se consume menos memoria, todo está bien, pero no puedes UNIRTE y tienes que hacer consultas como DÓNDE EN, es decir, primero seleccionamos un montón de ID, luego sustituimos todos estos ID. en la consulta, sino a otra conexión, a otro servidor.

Es posible fragmentar parte de los mismos datos, es decir, por ejemplo, tomamos y creamos varias bases de datos con los usuarios.

Simplemente puede seleccionar un servidor; el resto se divide por la cantidad de servidores. Una alternativa es conseguir una tarjeta, es decir. Para cada registro, mantenga la clave de valor en algún Redis o similar, es decir, dónde se encuentra cada registro.

Hay una opción más sencilla:

Es más difícil cuando no puedes agrupar los datos. Necesita conocer el ID de datos para obtenerlo. No UNIRSE, ORDENAR, etc. De hecho, reducimos nuestro MySQL o PostgreSQL a un almacén clave-valor, porque no podemos hacer nada con ellos.

Las tareas ordinarias se vuelven extraordinarias:

Seleccione TOP 10.
Desglose de página.
Elija el que tenga el menor costo.
Seleccione publicaciones del usuario X.

Si lo fragmentamos para que todo se distribuya por todos los servidores, esto ya empieza a solucionarse de una forma muy no trivial. En esta situación, surge la pregunta: ¿por qué necesitamos SQL? ¿No deberíamos escribir a Redis de inmediato? ¿Elegimos la instalación de almacenamiento adecuada?

De fábrica, la fragmentación es compatible con cosas como:

memcache;
Redis;
Cassandra (pero ella, dicen, en algún momento no puede hacer frente y comienza a caer).

¿Qué pasa con las estadísticas?

A menudo les gusta calcular estadísticas desde el servidor principal, desde un único servidor de base de datos. Esto es genial, pero las consultas en estadísticas suelen ser espeluznantes, de varias páginas, etc., por lo que calcular estadísticas a partir de los datos principales es un gran error. En la mayoría de los casos, el tiempo real no es necesario para las estadísticas, por lo que podemos configurar la replicación en el maestro-esclavo y calcular estas estadísticas en el esclavo. O podemos tomar algo ya preparado: Mixpanel, Google Analytics o similar.

Esta es la idea principal que ayuda a distribuir todo en diferentes servidores y escalar. En primer lugar, el beneficio de esto es inmediatamente visible: incluso si tiene un servidor y comienza a hacer algo en segundo plano, el usuario recibe una respuesta mucho más rápido, pero posteriormente también distribuye la carga, es decir. Podemos arrastrar todo este procesamiento a otro servidor, incluso podemos procesarlo no en PHP. Por ejemplo, en Stay.com, las imágenes cambian de tamaño en Go.

Puedes llevarte inmediatamente a Gearman. Esto es algo listo para procesar en segundo plano. Hay bibliotecas y controladores para PHP... O puedes usar colas, es decir. ActiveMQ, RabbitMQ, pero las colas solo reenvían mensajes, no llaman ni ejecutan los controladores por sí mismas, y luego tendrás que pensar en algo;

El significado general es siempre el mismo: existe el software principal que coloca algunos datos en la cola (normalmente es "¿qué debo hacer?" y datos para esto), y algún servicio: los recibe o se los envía. (si la cola puede comportarse activamente) estos datos, procesa todo en segundo plano.

Pasemos a la arquitectura.

Lo más importante a la hora de escalar es hacer que el proyecto esté lo menos conectado posible. Cuanto menos conectividad, más fácil será cambiar una solución a otra, más fácil será mover una parte a otro servidor.

La cohesión ocurre en el código. SOLID, GRASP son principios que le permiten evitar el acoplamiento en el código. Pero la conectividad en el código, por supuesto, afecta la distribución entre servidores, pero no tanto como la conectividad de la capa de dominio con nuestro entorno. Si escribimos mucho código en el controlador, resulta que lo más probable es que no podamos usarlo en ningún otro lugar. No nos resultará fácil transferir todo esto desde el controlador web a la consola y, en consecuencia, será más difícil transferirlo a otros servidores y procesarlo allí de otra manera.

Arquitectura orientada a servicios.

Hay dos enfoques para dividir los sistemas en partes:

cuando se centran en partes técnicas, es decir, por ejemplo, hay una cola, eliminaron el servicio de colas, hay procesamiento de imágenes, eliminaron este servicio, etc.
Esto es bueno, pero cuando estas colas, imágenes, etc. interactuar dentro de dos áreas de dominio... Por ejemplo, en un proyecto hay un área de Ventas y un área de Clientes; estas son áreas diferentes, trabajan con diferentes usuarios, pero ambos tienen colas diferentes. Cuando todo empieza a desmoronarse, el proyecto se vuelve un desastre;
La solución correcta es dividir en partes lógicas separadas, es decir si las áreas de Ventas y Clientes utilizan el modelo de usuario, entonces creamos 2 modelos de usuario. Pueden leer los mismos datos, pero los presentan de forma ligeramente diferente. Si descompones el sistema de esta manera, todo se percibe mucho mejor y es mucho más fácil dispersarlo todo.
Otra cosa importante es que las partes siempre deben comunicarse a través de interfaces. Entonces, en nuestro ejemplo, si Sales interactúa con algo, entonces no escribe en la base de datos, no usa modelo general, y “conversa” con otras áreas a través de un contrato específico.

¿Qué pasa con la capa de dominio?

La capa de dominio se divide en algunos servicios, etc. - Esto es importante para desarrollar una aplicación, pero para escalar su diseño no es muy importante. En la capa de dominio, es sumamente importante separarlo del entorno, el contexto en el que se ejecuta, es decir. desde el controlador, entorno de consola, etc., para que todos los modelos puedan usarse en cualquier contexto.

Hay 2 libros sobre la capa de dominio que recomiendo a todos:

"Diseño basado en dominios: abordar la complejidad en el corazón del software" por Eric Evans,
"Implementación de un diseño basado en dominios, implementación de un diseño basado en dominios".

sobre BoundedContext - http://martinfowler.com/bliki/BoundedContext.html (lo que se mencionó anteriormente - si tiene dos áreas que parecen cruzarse, pero
diferente, entonces vale la pena duplicar algunas entidades, como el modelo de usuario);
sobre DDD en general: enlace a otro libro.

En arquitectura, nuevamente, vale la pena adherirse al principio de no compartir nada, es decir Si quieres hacer algo común, hazlo siempre de forma consciente. Es preferible poner la lógica del lado de la aplicación, pero vale la pena saber cuándo detenerse. Nunca deberías, por ejemplo, crear procedimientos almacenados en un DBMS, porque escalarlo es muy difícil. Si transferimos esto al lado de la aplicación, entonces será más fácil: crearemos varios servidores y todo se realizará allí.

No subestimes la optimización del navegador. Como ya dije, de los 300-600 ms que se ejecutan las solicitudes en el servidor, se les suman 300-600 ms, que se gastan en el cliente. Al cliente no le importa si nuestro servidor es rápido o si el sitio funciona tan rápido, así que le aconsejo que utilice Velocidad de página de Google etc.

Como es habitual, la abstracción y la fragmentación no son nada libres. Si dividimos el servicio en muchos microservicios, ya no podremos trabajar con los recién llegados y tendremos que pagar mucho, mucho a nuestro equipo, que hurgará en todo esto, clasificará todas las capas, además , el servicio puede comenzar a funcionar más lento. Si esto no da miedo en los lenguajes compilados, entonces en PHP, al menos hasta la versión 7, esto no es muy...

Nunca actúes a ciegas, siempre monitoriza y analiza. Ciegamente, casi todas las decisiones por defecto son erróneas. ¡Pensar! No crea que existe una solución milagrosa, compruébelo siempre.

Algunos enlaces más útiles:

Contactos

Este informe es una transcripción de uno de mejores actuaciones en la conferencia de formación para desarrolladores de sistemas de alta carga en 2015.

¡Cosas viejas! - dices.
- ¡Valores eternos! - responderemos.

También utilizamos algunos de estos materiales en un curso de formación en línea sobre el desarrollo de sistemas de alta carga: se trata de una cadena de cartas, artículos, materiales y vídeos especialmente seleccionados. Nuestro libro de texto ya contiene más de 30 materiales únicos. ¡Conectar!

Bueno, la principal noticia es que hemos comenzado los preparativos para el festival de primavera "Tecnologías rusas de Internet", que incluye ocho conferencias, entre ellas Alta carga++ Junior.

ALEJANDRO KALENDAREV, RBC Media, programador, [correo electrónico protegido]

Problemas y soluciones

Tarde o temprano, un proyecto web o móvil popular con lado del servidor encontrará un problema de rendimiento. Una solución es escalar la base de datos horizontalmente. hablamos de trampas y sobre formas posibles evitandolos

Cada proyecto en crecimiento enfrenta un desafío de productividad. Por tanto, si crees que tu proyecto es ambicioso y pronto conquistará el mundo entero, entonces es recomendable incluir la posibilidad de escalar al nivel del desarrollo arquitectónico inicial.

Aclaremos la terminología:

Actuación– la capacidad de la aplicación para cumplir requisitos como el tiempo máximo de respuesta y el rendimiento.
Rendimiento (capacidad) – máxima oportunidad aplicaciones para pasar una cierta cantidad solicitudes por unidad de tiempo o mantener cierto número sesiones de usuario.
Escalabilidad Es una característica de una aplicación que muestra su capacidad para mantener el rendimiento a medida que aumenta. ancho de banda. A su vez, el escalamiento es el proceso de asegurar el crecimiento del sistema. El escalado puede ser vertical u horizontal.
Escalado vertical- este es un aumento en la productividad debido al aumento de la potencia del hierro, el volumen RAM etc. Tarde o temprano, la escala vertical alcanzará su límite superior.
Escalado horizontal es un aumento de la productividad al dividir los datos en varios servidores.

Separación de datos funcionales

Hay varias opciones para el escalado horizontal. Por ejemplo, se utiliza muy a menudo para separar datos según el uso funcional. Por ejemplo, los datos de los álbumes de fotos se encuentran en un grupo de servidores, los datos del perfil del usuario se encuentran en otro grupo y la correspondencia del usuario se encuentra en un tercero. En la figura. La figura 1 muestra un diagrama de escalamiento horizontal por distribución funcional.

Escalar usando replicación

El método más simple de escalado, que a menudo se usa para proyectos pequeños y medianos, es utilizar la replicación. La replicación es un mecanismo para sincronizar múltiples copias de un objeto y tablas de bases de datos (ver Fig. 2). La replicación maestro-esclavo es la sincronización de datos desde el servidor maestro principal a los servidores esclavos.

Dado que la mayoría de los sitios web y proyectos moviles Hay un orden de magnitud más de operaciones de lectura que de escritura, por lo que podemos realizar operaciones de escritura en un servidor maestro y leer datos de muchos servidores esclavos. La replicación debe configurarse entre los servidores maestro y esclavo.

Muchas bases de datos tienen replicación incorporada o, como dicen, una "solución lista para usar". Por ejemplo, la replicación de PostgreSQL se puede realizar mediante las siguientes utilidades:

Slony-I – replicación asíncrona (de maestro a múltiples esclavos);
pgpool-I/II – replicación multimaestro síncrona;
Pgcluster: replicación multimaestro síncrona;
Bucardo;
Londres;
Representante de Ruby.
a partir de la versión 9.0, replicación de transmisión incorporada.

Al escalar mediante replicación, debe utilizar diferentes conexiones: uno con servidor maestro, solo para escritura o actualización, y el segundo, solo con servidor esclavo, directamente para lectura. Además, si utilizamos varios servidores esclavos, la estrategia de selección puede ser aleatoria o asignar un servidor de base de datos específico a un servidor web específico.

Lea el artículo completo en la revista " Administrador del sistema", No. 10 para 2014 en las páginas 54-62.

versión PDF numero dado se puede adquirir en nuestra tienda.

) ¡Hola! Soy Alexander Makarov y quizás me conozcas por el marco Yii: soy uno de sus desarrolladores. También tengo un trabajo de tiempo completo (y esto ya no es una startup): Stay.com, que se ocupa de viajes.

Hoy hablaré de escalamiento horizontal, pero en términos muy, muy generales.

¿Qué es escalar? Esta es una oportunidad para aumentar la productividad del proyecto en un tiempo mínimo agregando recursos.

Normalmente, escalar no implica reescribir código, sino agregar servidores o aumentar los recursos de uno existente. Este tipo incluye escalado vertical y horizontal.

Vertical es cuando se agrega más RAM, discos, etc. en un servidor ya existente, y horizontal es cuando colocan más servidores en los centros de datos, y los servidores allí ya interactúan de alguna manera.

Los dos parámetros principales: n - el número de solicitudes que deben realizarse, c - el número de solicitudes simultáneas. De esta manera controlan la competencia.

Sucede que, de hecho, todavía no hay necesidad de preocuparse por la escala: vamos al servidor, actualizamos PHP, obtenemos un aumento del 40% en el rendimiento y todo está bien. A continuación, configuramos Opcache y lo ajustamos. Opcache, por cierto, está optimizado de la misma manera que APC, con un script que se puede encontrar en el repositorio de Rasmus Lerdorf y que muestra aciertos y errores, donde los aciertos son cuántas veces PHP fue al caché y los errores son cuántas veces fue al sistema de archivos para obtener archivos. Si ejecutamos todo el sitio, o ejecutamos algún tipo de rastreador en los enlaces, o lo pinchamos manualmente, tendremos estadísticas sobre estos aciertos y errores. Si hay un 100% de aciertos y un 0% de errores, entonces todo está bien, pero si hay errores, entonces necesitamos asignar más memoria para que todo nuestro código quepa en Opcache. Este es un error común que se comete: parece que Opcache está ahí, pero algo no funciona...

Bueno, también necesitas habilitar el caché, reemplazar apache con nginx y php-fpm para ahorrar memoria. Todo será genial.

Todo lo anterior es bastante simple y le da tiempo. Hay tiempo para que algún día esto no sea suficiente, y debemos prepararnos para ello ahora.

¿A qué debería prestar atención en este momento durante el seguimiento? Este:

accesibilidad, es decir si el servidor está vivo o no;
falta de recursos de disco, procesador, etc.;
errores.

¿Cómo monitorear todo esto?

Aquí hay una lista de excelentes herramientas que le permiten monitorear recursos y mostrar los resultados de una manera muy conveniente:

Este informe es una transcripción de una de las mejores presentaciones en la conferencia de capacitación para desarrolladores de sistemas de alta carga en 2015.
¡Cosas viejas! - dices.
- ¡Valores eternos! - responderemos.
junior de alta carga
Agregar etiquetas

Popular en la categoría: