{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Patrones arquitect\u00f3nicos convenientes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola, Habr!<\/p>\n

<\/p>\n

A la luz de los acontecimientos actuales debido al coronavirus, varios servicios en l\u00ednea han empezado a recibir una carga incrementada. Por ejemplo, una de las cadenas comerciales en el Reino Unido simplemente detuvo su sitio web de pedidos en l\u00ednea<\/a><\/noindex>, ya que no contaba con los recursos necesarios. Y no siempre se puede acelerar un servidor simplemente agregando hardware m\u00e1s potente, sin embargo, es necesario procesar las solicitudes de los clientes (o se ir\u00e1n con la competencia).<\/p>\n

<\/p>\n

En este art\u00edculo, mencionar\u00e9 brevemente las pr\u00e1cticas populares que permitir\u00e1n crear un servicio r\u00e1pido y resistente a fallos. Sin embargo, de las posibles esquemas de desarrollo, he seleccionado solo aquellos que ahora son f\u00e1ciles de utilizar<\/strong>. Para cada punto, ya tienes bibliotecas listas o hay opciones para resolver el problema a trav\u00e9s de una plataforma en la nube.<\/p>\n

<\/a><\/noindex><\/p>\n

Escalado horizontal<\/h1>\n

<\/p>\n

El punto m\u00e1s simple y conocido por todos. En general, hay dos esquemas de distribuci\u00f3n de carga que se ven con m\u00e1s frecuencia: escalado horizontal y escalado vertical. En el primer caso,<\/a><\/noindex> permites que los servicios operen en paralelo, distribuyendo as\u00ed la carga entre ellos. En el segundo,<\/a><\/noindex> pides servidores m\u00e1s potentes o optimizas el c\u00f3digo.<\/p>\n

<\/p>\n

Por ejemplo, tomar\u00e9 un almacenamiento en la nube abstracto de archivos, es decir, un an\u00e1logo de OwnCloud, OneDrive, etc.<\/p>\n

<\/p>\n

La imagen est\u00e1ndar de un esquema similar se muestra a continuaci\u00f3n, pero solo demuestra la complejidad del sistema. Tenemos que sincronizar los servicios de alguna manera. \u00bfQu\u00e9 pasar\u00e1 si un usuario guarda un archivo desde su tableta y luego quiere verlo desde su tel\u00e9fono?<\/p>\n

<\/p>\n

\"Patrones
\nLa diferencia entre los enfoques: en el escalado vertical estamos dispuestos a aumentar la potencia de los nodos, mientras que en el escalado horizontal, agregamos nodos nuevos para distribuir la carga.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Separaci\u00f3n de responsabilidad en comandos y consultas<\/a><\/noindex> es un patr\u00f3n bastante importante, ya que permite a diferentes clientes no solo conectarse a diferentes servicios, sino tambi\u00e9n recibir flujos de eventos id\u00e9nticos. Sus beneficios no son tan evidentes para una aplicaci\u00f3n simple, sin embargo, es crucial (y simple) para un servicio de alta carga. Su esencia es: los flujos de datos entrantes y salientes no deben cruzarse. Es decir, no puedes enviar una solicitud y esperar una respuesta; en su lugar, env\u00edas una solicitud al servicio A, pero recibes una respuesta en el servicio B.<\/p>\n

<\/p>\n

El primer beneficio de este enfoque es la capacidad de desconexi\u00f3n (en un sentido amplio) durante la ejecuci\u00f3n de una larga solicitud. Tomemos como ejemplo una secuencia m\u00e1s o menos est\u00e1ndar:<\/p>\n

<\/p>\n

    \n
  1. El cliente envi\u00f3 una solicitud al servidor.<\/li>\n
  2. El servidor inici\u00f3 un procesamiento prolongado.<\/li>\n
  3. El servidor respondi\u00f3 al cliente con el resultado.<\/li>\n<\/ol>\n

    <\/p>\n

    Imaginemos que en el punto 2 se produjo una interrupci\u00f3n de la conexi\u00f3n (ya sea que la red se reconect\u00f3 o que el usuario cambi\u00f3 a otra p\u00e1gina, cortando la conexi\u00f3n). En este caso, ser\u00e1 dif\u00edcil para el servidor enviar una respuesta al usuario con informaci\u00f3n sobre lo que se proces\u00f3. Al aplicar CQRS, la secuencia ser\u00e1 un poco diferente:<\/p>\n

    <\/p>\n

      \n
    1. El cliente se suscribi\u00f3 a las actualizaciones.<\/li>\n
    2. El cliente envi\u00f3 una solicitud al servidor.<\/li>\n
    3. El servidor respondi\u00f3 \"solicitud aceptada\".<\/li>\n
    4. El servidor respondi\u00f3 con el resultado a trav\u00e9s del canal del punto \"1\".<\/li>\n<\/ol>\n

      <\/p>\n

      \"Patrones<\/p>\n

      <\/p>\n

      Como se puede ver, el esquema es un poco m\u00e1s complejo. Adem\u00e1s, el enfoque intuitivo de solicitud-respuesta est\u00e1 ausente aqu\u00ed. Sin embargo, como se observa, la interrupci\u00f3n de la conexi\u00f3n durante el procesamiento de la solicitud no conducir\u00e1 a un error. Adem\u00e1s, si efectivamente el usuario est\u00e1 conectado al servicio desde varios dispositivos (por ejemplo, desde un tel\u00e9fono m\u00f3vil y una tableta), se puede hacer que la respuesta llegue a ambos dispositivos.<\/p>\n

      <\/p>\n

      Curiosamente, el c\u00f3digo para procesar los mensajes entrantes se vuelve similar (no al 100%) tanto para los eventos que fueron influenciados por el cliente como para otros eventos, incluidos los de otros clientes.<\/p>\n

      <\/p>\n

      Sin embargo, en realidad, obtenemos beneficios adicionales debido a que el flujo unidireccional puede ser procesado de manera funcional (utilizando RX y an\u00e1logos). Y eso ya es una ventaja considerable, ya que, en esencia, la aplicaci\u00f3n puede hacerse completamente reactiva, adem\u00e1s de utilizar un enfoque funcional. Para aplicaciones robustas, esto puede ahorrar significativamente recursos en desarrollo y mantenimiento.<\/p>\n

      <\/p>\n

      Si combinamos este enfoque con la escalabilidad horizontal, obtenemos como bono la posibilidad de enviar solicitudes a un servidor y recibir respuestas de otro. De esta manera, el cliente puede elegir el servicio que le sea conveniente, y el sistema interno podr\u00e1 manejar correctamente los eventos.<\/p>\n

      <\/p>\n

      Event Sourcing<\/h1>\n

      <\/p>\n

      Como saben, una de las caracter\u00edsticas principales de un sistema distribuido es la ausencia de un tiempo com\u00fan y una secci\u00f3n cr\u00edtica com\u00fan. Para un proceso, puede hacerse la sincronizaci\u00f3n (en los mismos mutex), dentro de la cual est\u00e1s seguro de que nadie m\u00e1s est\u00e1 ejecutando ese c\u00f3digo. Sin embargo, para un sistema distribuido, esto es peligroso, ya que requerir\u00eda gastos generales y se perder\u00eda toda la ventaja de la escalabilidad: de todos modos, todos los componentes esperar\u00edan a uno.<\/p>\n

      <\/p>\n

      De aqu\u00ed obtenemos un hecho importante: no se puede sincronizar un sistema distribuido r\u00e1pido, ya que entonces disminuir\u00edamos el rendimiento. Por otro lado, a menudo necesitamos cierta consistencia de los componentes. Para ello, se puede utilizar el enfoque de consistencia eventual<\/a><\/noindex>, donde se garantiza que, en ausencia de cambios en los datos, despu\u00e9s de un cierto per\u00edodo de tiempo tras la \u00faltima actualizaci\u00f3n (\u00abeventualmente\u00bb), todas las solicitudes devolver\u00e1n el \u00faltimo valor actualizado.<\/p>\n

      <\/p>\n

      Es importante entender que para las bases de datos cl\u00e1sicas a menudo se aplica consistencia estricta<\/a><\/noindex>, donde cada nodo posee la misma informaci\u00f3n (esto a menudo se logra cuando la transacci\u00f3n se considera establecida solo despu\u00e9s de la respuesta del segundo servidor). Hay ciertas flexibilidades debido a los niveles de aislamiento, pero la esencia general sigue siendo la misma: puedes vivir en un mundo completamente consistente.<\/p>\n

      <\/p>\n

      Sin embargo, volvamos a la tarea inicial. Si una parte del sistema puede construirse con consistencia eventual<\/a><\/noindex>, entonces se puede construir el siguiente esquema.<\/p>\n

      <\/p>\n

      \"Patrones<\/p>\n

      <\/p>\n

      Caracter\u00edsticas importantes de este enfoque:<\/p>\n

      <\/p>\n