Diseño de Servicios de Lectura Escalables y Stateless
Contenido del curso
Carlos Eduardo Gomez García
Tomas Bond
Francisco Serrato Jiménez
Raul Enrique Torres Reyes
J. Sebastián Botello. H.
Julio Cesar Arbieto Chavez
Carlos Eduardo Gomez García
Jair Israel Avilés Eusebio
Julio Cesar Arbieto Chavez
Julio Cesar Arbieto Chavez
Jennifer Cano
Carlos Fernando Aguilar González
Carlos Eduardo Gomez García
Rodrigo Hernández
Capacitacion 2
Wilson Delgado
Junior Ignacio Romero Quiñones
Carlos Eduardo Magallon Zepeda
Francisco Javier Pineda Giraldo
Junior Aguilera
Moisés Abraham Croes Gómez
William Schnaider Torres Bermon
Stateless (sin estado)
Se refiere a que cada solicitud será única y no tendrá ningún tipo de relación con alguna solicitud anterior, es decir, no se va a guardar nada, cada transacción iniciará desde 0. Para poner una analogía, imagina una computadora SIN disco duro, cada proceso que haga esta computadora no se va a guardar, imagina que por cada proceso, enciendes la computadora, hacer el proceso y luego la apagas de nuevo, eso es stateless. . En cambo, stateful sí que puede guardar cosas y comunicarse con procesos anteriores, usar datos generados de un proceso para hacer otro proceso.
Horizontal Scaling (escala horizontal)
. Anteriormente, cuando un sistema crecía y empezaban a incrementar la cantidad de solicitudes al servidor en miles de solicitudes por segundo solíamos pensar que simplemente teníamos que agregarle un mejor CPU, más memoria RAM, más discos duros, mejorar la conexión a internet... ¿Pero qué pasaba si mi demanda aumentaba a millones, pero yo ya tenía el servidor más potente del mundo y no podía agregarle nada más y aun así no abastecía para satisfacer millones de usuarios? A esto se le llama escala vertical, sin embargo, poco a poco se fue adoptando el concepto de escala horizontal en donde, en lugar de tener un servidor superpotente con el mejor procesador y teras de RAM, podemos tener varias computadoras atendiendo esas miles solicitudes, y si la demanda crece a millones, nos basta con simplemente agregar más computadoras que puedan atenderlas.
De nuevo, Freddy tiene un video explicando cómo se escalan: @youtube
excelente
Excelente aportación profe ++RetaxMaster++, para complementar dar clic al link.
Como bien menciona Jorge solo con retroalimentación podremos hacer las cosas mejor, así que aquí esta mi ejemplo (espero sus comentarios)
El diagrama lo realice poniendo las cosas que conozco y he utilizado
El diagrama lo realice poniendo las cosas que conozco y he utilizado
El frontend se conectaría a un servidor NGINX el cual dirigiría las peticiones dependiendo del método de request que se realice.
Si es un nuevo review(POST) este será tratado por un django api rest que vive en un contenedor de docker y que guardara los datos dentro de una base de datos en postgresql.
Esta base de datos maestra realizara una replicación a otro servidor de postgresql, esta replicación será de forma asíncrona con esto ganamos velocidad en la escritura aunque no aseguramos que los datos estén inmediatamente disponibles en el servidor de replica.
Si los usuarios quieren consultar un review(GET) este será tratado en otro api rest que también es un contenedor y se encuentra un servidor diferente, este se conecta a la base de datos postgresql que es la replica de la base de datos maestra.
Notas: Utilice una base de datos relacional como postgresql porque no tengo mucha experiencia utilizando bases de datos nosql además de que en teoría no tenemos millones de editores realizando reviews al mismo tiempo así que la velocidad de escritura no tendría diferencia significativa contra una base de datos nosql.
El proyecto de api rest de django es el mismo tanto para el de escritura como para el de lectura, por eso los puse en un contenedor para poder desplegarlo de manera mas fácil en ambos lados.
**Algo que me surge como duda es, que podría hacer en este caso: ** ¿Si un Editor escribe su review e inmediatamente quiere consultarla, no podemos asegurar que ya se encuentre guardada en el servidor de replica y quizá cuando la consulte no exista aun y le de la sensación de que no se guardo?
Podrías manejar "la sensación" con estados, creas servicios que te alerten cuando algo pasa.. En un ambiente "soñado" las replicas son inmediatas y esto no sería un lio. Creo que sería la forma de resolverlo.
Vale, aquí está mi práctica, realmente no sé cómo puedo ser más específico con eso, ¿debería poner los nombres de las funciones a llamar? . Básicamente el front-end manda a llamar servidores stateless, que contienen el API bajo Laravel procesando la solicitud, este se conecta a una base de datos alojada en GCP. . El servicio retornaría los datos del review que fue pedido, pero product solo retornará el id del producto, para obtener el resto de la información se necesita hacer otra petición hacia products:
{ "id": 1, "content": { "title": "El titulo del review", "autor": "El autor del review", "content": "El contenido del review", "product": { "id": 1 } } }
Acepto feedback:D
Buen diseño. Hablando sobre el payload, creo que seria excelente que se regrese los detalles completos de la product, para ahorrar un request. Esto en terminos de implementacion podria ser que en tus servicio de GET sea implementado con un ORM configurando las entidades que se relacionan.
Adjunto imagen plasmando la arquitectura según el requerimiento solicitado, paso a explicar:
Para realizar el procesos de leer los registro desde el Front-End, en este caso tenemos un cliente PWA React js, que lee un Api Gateway que expone un método (Serverles Function) desarrollado Net Core 3.1 C# - le denomine “GetReviewCamera” el cual solicita información al Cache “ElastiCache for Redis” y si en caso de no existir información solicitada en Cache se realizara una búsqueda en BD “Dynamo DB”, en este caso decidí utilizar esta BD por que es rápida, obviaste esto depende a la estructura o diagrama de BD. El cache nos ayudara en obtener inflacionario en menos latencia/ tiempo. Con esto reduciría poco lo que es el costo de consumo de BD, asumiendo que esta Api sera leída por millones de usuarios en tiempo real. Ademas de ello cabe mencionar que el Lambda Serverles es Auto escalable y es Algo que se requiere cuando trabajamos con Millones de Usuarios. A la vez utilizaría el Cache que tiene el Api Gateway ya que seria genial para tener menos consumo del Lambda. La Structura del Json Como Response del Method GetReviewCamera seria la siguiente:
{ "status": "OK", "message": "", "review": { "id": 1, "content": { "title": "The title of the review", "author": "The author of the review", "content": "The content of the review", "product": { "id": 1, "name": "name product", "description":"Description of the product", "manufacturer":"Manufacturer of the product", "sku": "", "feature":[] } } } }
Buenas noches, comparto mi arquitectura para feedback
Hay algo que todavía no entiendo, ¿qué cosas exactamente se debe especificar en el diseño de bajo nivel? porque en este ejemplo puse al frontend, el API, pero en este caso no sé como representar el API, por ejemplo, ¿debería poner a los servidores apuntando al API?, y yo aquí puse a los servidores apuntando a Laravel porque es con la tecnología que quiero trabajar, y puse a Laravel apuntando al modelo de Reviews, pero, ¿y si tengo varios modelos? ¿no sería demasiado y poco práctico poner cada modelo en este driagrama? . Y mi duda más grande: ¿De qué sirve tener el servicio stateless donde tengo la capacidad de aumentar servidores si así lo necesito, si al final todos acabarán llamando a la misma base de datos y será la base de datos la que tenga que procesar ese millón de solicitudes que le están llegando de cada servidor stateless? xD
Hola @RetaxMaster te aclaro algunos puntos de acuerdo a mi experiencia:
Hola, que tal? dejo un link de Drive que lleva a la carpeta de la tarea: https://drive.google.com/drive/folders/1oskwcb9em5EqhnyriVk5rcGWR-ME37Yy?usp=sharing Gracias, saludos!
¿Cuál es la mejor forma de transformar NoSQL?
La mejor estrategia es usar el patrón Data Transfer Object (DTO). Las bases de datos NoSQL suelen guardar documentos con metadatos internos, fechas de auditoría o estructuras anidadas complejas que el cliente final no necesita (y que por seguridad no deberías exponer).
En tu código, crea una clase o estructura intermedia. Cuando extraigas el documento de la base de datos, mapea únicamente los campos esenciales hacia tu DTO. Por ejemplo, si tu NoSQL tiene {"_id": "123", "internal_rev": 4, "user_comment": "Excelente"}, tu API solo debería devolver un JSON limpio como {"id": "123", "comment": "Excelente"}. Esto reduce el consumo de ancho de banda y crea un contrato claro y predecible para los desarrolladores frontend o móviles que consumen tu API.
Esta bueno el curso. Muchas gracis por compartir tus conocimientos.
Este es un esquema prácticamente desde cero, sin serverless ni demás cosas. Opcionalmente se podría agregar otra capa al frente como un balanceador de carga, aunque yo creo que con la cache debería bastar o reemplazar Django por FastAPI y SQLAlchemy, ya que soportan muchas más peticiones por minuto.
No he usado bases de datos NoSQL así que no las agregué
{ "status": "Ok", "review": { "id": 1, "title": "Title", "author": { "id": 1, "profileImg": "[].jpg", "email": "user@example.org", "username": "username", "accountType": "basic" }, "content": "Content", "created": "01-01-2000", "modified": "01-01-2000", "product": { "id": 1, "title": "Title", "category": "Category", "description": "Description", "manufacturer": "Manufacturer", "SEOTitle": "SEO title", "SEODescription": "SEO description", "averagePrice": 1, "imageUrl": "[].jpg", "sku": "sku", "created": "01-01-2000", "modified": "01-01-2000", "affiliateLink": "[].com" } }, "error": "" }
Que bueno que todos saben tanto, Yo, seguiré aprendiendo con las clases y todos sus comentarios, no solo debo Aprender sobre todas las herramientas sino echarme al agua codificando el proyecto propuesto
recomiendas vm? en vez de docker?
Personalmente me gusta mas la idea de usar Docker en un Web App de Azure o el servicio de Kubernetes, sobretodo este ultimo creo que es totalmente compatible con la característica de escalabilidad que buscamos
Hay casos de casos, pero en la mayoria de las veces un entorno contenerizado resulta más ventajoso. Además, los servicios disponibles en la nube que trabajan con contenedores ofrecen increibles herramientas.
