Metodologías de Sistemas Distribuidos a Gran Escala

Los sistemas distribuidos a gran escala generalmente se caracterizan por una gran cantidad de datos, una gran cantidad de usuarios simultáneos, requisitos de escalabilidad y requisitos de rendimiento, como latencia, etc. hacer frente a cada uno de estos requisitos que existen en los sistemas. También a esta gran escala es difícil tener la práctica de desarrollo y prueba también. Esta tecnología es utilizada por varias empresas como GIT, Hadoop, etc.

Arquitectura del sistema a gran escala:

1. La arquitectura tiene que desempeñar un papel vital en términos de comprensión significativa del dominio. Es muy importante comprender los dominios para el titular de la participación y los propietarios del producto. También tenían que comprender el tipo de integraciones con la plataforma que se realizarán en el futuro.
2. Otro aspecto importante es sobre los requisitos de seguridad y cumplimiento de la plataforma y estas son también las decisiones que deben tomarse desde el comienzo de los proyectos para que los procesos de desarrollo en el futuro no se vean afectados.

Sistemas Distributivos :

• Ahora, primero hablemos de los sistemas distributivos. Los sistemas distribuidos contienen múltiples Nodes que están físicamente separados pero vinculados mediante la red. Cada uno de estos Nodes contiene una pequeña parte del software del sistema operativo distribuido. Para una mejor comprensión, consulte el artículo de Sistemas Distribuidos
• Los grandes sistemas distribuidos son muy complejos, lo que significa que en términos de tolerancia a fallas (cuán resistente es su sistema). Significa que consideró todos los casos posibles en los que su sistema puede fallar y puede recuperarse de eso.
• Para que el sistema distributivo funcione bien, usamos la arquitectura de microservicios. Puede leer sobre la arquitectura de microservicios en el artículo. Pero el desafío es tener una arquitectura basada en microservicios, debe trazar los límites de los microservicios; de lo contrario, podría diseñar en exceso el sistema y podría dividirlo en límites no naturales y el sistema no funciona de manera coherente en una condición natural. El otro lado de la arquitectura de microservicios del que hablamos es el teorema de la tapa.
  

  Los límites en los microservicios deben ser claros.

Teorema de la PAC:

• El teorema del límite establece que puede tener los tres aspectos de consistencia, disponibilidad y partición. Solo puedes tener dos cosas de esas tres. Ahora debe tener muy claro según los requisitos de su dominio qué dos desea elegir entre estos tres aspectos.
  

  Elija dos de estos tres aspectos

Cola de mensajes: las
colas de mensajes son excelentes, ya que algunos microservicios publican algunos mensajes y algunos microservicios consumen los mensajes y hacen el flujo, pero el desafío que debe pensar aquí antes de ir a la arquitectura de microservicios es el orden de los mensajes. Si no le importa el orden de los mensajes, es genial que pueda almacenar mensajes sin el orden de los mensajes. Una cosa más importante que entra en el flujo es el Event Sourcing.

Abastecimiento de eventos:
el abastecimiento de eventos es el gran patrón en el que puede tener sistemas inmutables. Si podemos tener modelos en los que podamos considerar que todo es un flujo de eventos a lo largo del tiempo y solo procesamos los eventos uno tras otro y también realizamos un seguimiento de estos eventos, entonces puede aprovechar la arquitectura inmutable. Inmutable significa que siempre podemos reproducir los mensajes que hemos almacenado para llegar al último estado. Significa que en el momento de las implementaciones y migraciones es muy fácil para usted ir y venir y también da cuenta de la corrupción de datos que generalmente ocurre cuando se maneja una excepción.

Nota:
el origen de eventos y las colas de mensajes irán de la mano y ayudarán a que el sistema sea resistente a gran escala.

Metodología de implementación:

• No puede tener un solo equipo que esté haciendo todas las cosas en un solo lugar, debe considerar dividir su equipo en un pequeño equipo multifuncional. Debe tener equipos pequeños que estén constantemente desarrollando sus partes y desarrollando su microservicio e interactuando con otros microservicios desarrollados por otros.
• También hay que mencionar aquí que estas cosas son impulsadas por organizaciones como Uber, Netflix, etc. Estas organizaciones tienen grandes equipos con un conjunto de habilidades increíble. Entonces, la cosa es que siempre debes jugar por la fuerza de tu equipo y no por lo que sería el equipo ideal.
  

  Un solo equipo haciendo cosas en un solo lugar

  

  Pequeños equipos que desarrollan constantemente sus piezas/microservicios

Seguridad y TDD (Desarrollo dirigido por pruebas):
el desarrollo en el equipo debe asegurar las prácticas de codificación y el sistema de desarrollo donde los datos en movimiento y los datos en reposo se cifran de acuerdo con el marco regulatorio y de cumplimiento.

TDD (Test Driven Development) se trata de desarrollar código y caso de prueba simultáneamente para que pueda probar cada abstracción de su código particular con los casos de prueba correctos que ha desarrollado. De esta manera, mientras desarrolla, obtiene comentarios de que todo va según lo planeado en lugar de esperar hasta que finalice el desarrollo.