Seminario Web MongoDB-Paradigma: Cree aplicaciones más escalables utilizando microservicios
Descargar como PPTX, PDF2 recomendaciones2,331 vistas
Las arquitecturas de microservicios han sido adoptados muy rápidamente, debido a su capacidad para proveer modularidad, escalabilidad y alta disponibilidad En este seminario web grabado, nuestros expertos, Rubén Terceño de MongoDB y Miguel Garrido de Paradigma Digital le explican cómo se puede usar microservicios para: Alinear las estructuras de tu organización Realizar aplicaciones más rápidamente Hacer un uso eficiente de tus recursos
Publicidad
Más contenido relacionado
La actualidad más candente (20)
Destacado (20)
Publicidad
Similar a Seminario Web MongoDB-Paradigma: Cree aplicaciones más escalables utilizando microservicios (20)
Publicidad
Más de MongoDB (20)
![MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]](https://cdn.slidesharecdn.com/ss_thumbnails/315pminfosysfinalsfoversionvocalpart1-200120221508-thumbnail.jpg?width=560&fit=bounds)
Último (20)
Seminario Web MongoDB-Paradigma: Cree aplicaciones más escalables utilizando microservicios
- 1. Seminario Web MongoDB & Paradigma Desarrolle aplicaciones más escalables utilizando microservicios
- 2. Ruben Terceño Senior Solutions Architect MongoDB Miguel Garrido Senior Solutions Architect Paradigma Digital
- 3. Agenda Introducción a los microservicios: ¿Por qué han surgido? ¿Qué beneficios aportan frente a arquitecturas tradicionales? Nuevas tecnologías que ayudan en arquitecturas de microservicios ¿Qué beneficios aporta el uso de MongoDB en este tipo de arquitecturas?
- 5. 5 Definición de microservicio “Microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language- agnostic APIs. These services are small, highly decoupled and focus on doing a small task.”
- 6. 6 Un poco de historia Equipo de desarrollo Arquitecturas monolíticas (pre- SOA) Arquitecturas SOA Microservicios En arquitecturas monolíticas cualquier cambio afecta al producto completo y todos los equipos deben estar de acuerdo en implementarlo. Los elementos en SOA se desarrollan de manera más autónoma pero los equipos deben coordinarse con otros para que los cambios encajen en el diseño general. El nuevo paradigma de desarrollo
- 7. 7 • Alto nivel de acoplamiento • Complejidad de código • Un pequeño cambio de código en la aplicación implica un despliegue completo • Escalado ineficiente • Menos especialización Arquitecturas monolíticas
- 8. 8 • Menor acoplamiento entre servicios • Bus de servicios que mapea el servicio lógico y llama al servicio físico • Se premia la reusabilidad, lo que puede llevar a que contengan demasiado código • Los servicios tienen estado • Suelen utilizar modelos de datos relacionales • En algunos casos, es complicado separar la funcionalidad entre servicios Arquitecturas SOA
- 9. 9 Arquitecturas de microservicios • Principio de responsabilidad única • Desarrollo eficiente • Escalado elástico • Ciclo de vida independiente • Menor Time-to-Market (Continuous Delivery) • Facilidad de integración con otros sistemas
- 10. 10 Retos de una arquitectura de microservicios • ¿Dónde se encuentran desplegados los servicios? • ¿Qué pasa si alguno falla? • ¿Cómo se configuran? • ¿Dónde se guardan las trazas? • ¿Cómo los monitorizamos? • ¿Cómo los desplegamos? • Gestionar el aumento del tráfico interno PaaS Microservici o 1 Microservici o 2 Microservici o 3 Microservici o 4 Servicio de enrutamiento Almacenamiento Servicio de orquestación Servicio de descubrimiento Registro de contenedores Consumidores Servicios de logging / monitorización Servicio de configuración Herramient a de CI Control de versiones
- 11. 11 Herramientas Microservicio 1 Microservicio 2 Microservicio 3 Microservicio 4 Servicio de enrutamiento Docker registry Servicio de orquestación Servicio de descubrimiento Devops Consumidores Servicios de logging / monitorización Servicio de configuración
- 12. 12 Herramientas Microservicio 1 Microservicio 2 Microservicio 3 Microservicio 4 Servicio de enrutamiento Docker registry Servicio de orquestación Servicio de descubrimiento Devops Consumidores Servicios de logging / monitorización Servicio de configuración Encargado del pipeline de Continuous Delivery Gestión del código fuente de los microservicios Gestión de imágenes docker de los diferentes microservicios Motor de base de datos
- 13. 13 Ejemplo de una arquitectura de microservicios PaaS Consumidor 1 CPD 1 Node 1 Gestión de pedidos Gestión de clientes Gestión de artículos Gestión de usuarios Node 2 Eureka Gestión de clientes CPD 2 Node 3 Gestión de pedidos Node 4 Gestión de clientes Gestión de artículos Gestión de usuarios Zuul Zuul Spring Cloud Config Eureka Spring Cloud Config MongoDBMongoDB CPD 3 (virtual) MongoDB Arbiter Master 1 Master 2 MongoDBMongoDB Master 3 Consumidor 2 Consumidor 3 Consumidor 4 Consumidor 5 Consumidor 6
- 14. 14 • Como hemos visto, la manera de comunicarse entre microservicios son los protocolos de red, especialmente el protocolo http, definiendo APIs REST como interfaz de comunicación. Estas APIs proporcionan: – Organizan sistemas internos para dar apoyo a nuevos proyectos innovadores de una manera uniforme. – Reducen costes de mantenimiento. – Incrementan la agilidad en los procesos de transformación. – Acercan la omnicanalidad a la empresa Microservicios y APIs Servicio API
- 15. 15 JSON como formato de intercambio • JSON son las siglas de JavaScript Object Notation, y fue originalmente pensado para llevar la notación nativa usada para declarar objetos en JavaScript a otros lenguajes. Proporciona: – Flexibilidad – Ligereza – Evita transformaciones con bases de datos en formato JSON – Modelo de datos autoexplicativo
- 16. 16 Proyecciones y expansiones • Funcionamiento similar a MongoDB • Minimizan el tráfico y optimizan el servicio en casos de acceso a múltiples datastores • Ejemplo de llamada con proyección: rest/api/content?type=page&spaceKey=TEST&proje ctions=version, history • Proporcionan mayor rendimiento y menor consumo, limitando el número de llamadas a un API • Permiten la expansión de campos e items embebidos de un recurso • Ejemplo de llamada con expansión: rest/api/content?type=page&spaceKey=TEST&expa nd=version,history.lastUpdated Proyecciones Expansiones
- 17. 17 Transaccionalidad en microservicios La división de los datos en diferentes repositorios (base de datos, colas de mensajes, etc) y su accesibilidad a través de servicios que los envuelven supone perder la transaccionalidad nativa a nivel de base de datos: Existen diversos patrones que permiten tratar esta situación: • Reintentar: en situaciones de caída puntual o no disponibilidad parcial del servicio (caída de un nodo por ejemplo), reintentar la operación puede ser una solución válida. • Abortar la operación completa: en esta situación, debe existir una operación de ‘compensación’ para volver a un estado de consistencia. • Transacción distribuida: basa su funcionamiento en la la existencia de un proceso de gobierno de la transacción (‘transaction manager’). Ok Servicio 1 Servicio 2 Servicio 3 Servicio 3 Ok Reintento Servicio 1 Servicio 2 Servicio 3 Deshacer Coordinador Servicio 2 Servicio 3 Preparar Servicio 1 Commit
- 19. 19 Cloud, IaaS y PaaS • Ayudan con la gestión eficiente de recursos • Posibilitan escalado ilimitado • Delegación de responsabilidad en piezas propias (balanceo de carga, enrutamiento, descubrimiento, seguridad...etc) • Monitorización de servicios • Logs centralizados • Trazabilidad de servicios • Despliegue automatizado con estrategias de balanceo automáticas
- 20. 20 Docker containers • Proveen entornos aislados gestionados por procesos (hypervisor) con el mínimo kernel de sistema operativo en cada contenedor • Con el mismo hardware se pueden ejecutar más contenedores que con máquinas virtuales • Docker ha conseguido un gran seguimiento de la comunidad con un repositorio público de imágenes, Docker Hub, que contiene sobre 400.000 imágenes
- 21. 21 Broker de mensajería • Broker de mensajería publisher / subscriber con persistencia en disco • Conecta microservicios • Desacopla llamadas entre microservicios • Proporciona alta disponibilidad Microservicio 1 Microservicio 2 Almacenamiento Microservicio 1 Microservicio 2 Almacenamiento - Dependencia entre servicios - Gestión de errores y reintentos en el servicio llamante - Añadir un nuevo servicio implica sólo suscripción - Gestión de reintentos en Kafka - Desacoplamiento entre servicios
- 23. 23 Bases de datos NoSQL Lenguaje de búsqueda expresivo Índices secundarios Consistencia Fuerte Integración con herramientas de gestión Escalable y distribuido • Escalabilidad horizontal • Cloud Rendimiento • Usuarios globales • Muy alta disponibilidad Flexibilidad • Esquema flexible • Datos no estructurados • Sin relaciones complejas
- 24. 24 MongoDB Nexus Architecture Lenguaje de búsqueda expresivo Índices secundarios Consistencia Fuerte Integración con herramientas de gestión The only NoSQL Database that combines best of RDBMS + NoSQL Escalable y distribuido • Escalabilidad horizontal • Cloud Rendimiento • Usuarios globales • Muy alta disponibilidad Flexibilidad • Esquema flexible • Datos no estructurados • Sin relaciones complejas
- 25. 25 Modelo de datos flexible Consumidor A Consumidor B Microservicio 1 • El esquema flexible de MongoDB permite que cada consumidor del servicio pueda tener una percepción propia de un modelo común, sin afectar esto a la morfología del dato en MongoDB • La propagación de los cambios en el modelo de datos de los consumidores es automática • Las vistas read-only permiten exponer el modelo de datos de forma polimórfica y realizar ofuscación
- 26. 26 Redundancia Debido a la naturaleza distribuida de los microservicios, estos tienen que ser diseñados teniendo en cuenta la redundancia del dato. MongoDB encaja perfectamente en este requerimiento, ya que proporciona de base redundancia a través de sus replica set. Es muy importante destacar MongoDB permite que la política de redundancia puede ser variable por petición y por criticidad del dato CloudCPD 2CPD 1 Replica set Nodo 1 Nodo 2 ArbiterNodo 3 Nodo 4
- 27. Los microservicios no se pueden interrumpir para hacer cambios en su esquema de datos. MongoDB puede adaptarse a cambios en el esquema de datos sin ninguna pérdida de servicio. Su arquitectura independiente de la plataforma proporciona facilidad de portabilidad. Frontend Applications Digital & Mobile Apps Backend Applications … Operational & BI Reporting Application Layer API Access Layer Microservices Layer Database Layer Flexibilidad para modelar estructuras de datos cambiantes sin necesidad de parar la plataforma para realizar mantenimiento. 1 MongoDB and Microservices – Flexibility
- 28. La habilidad de escalar rapidamente para adaptarse a una demanda cambiante es un atributo clave de los microservicios. La arquitectura de MongoDB permite escalado y alta disponibilidad de forma nativa. Frontend Applications Digital & Mobile Apps Backend Applications … Operational & BI Reporting Application Layer API Access Layer Microservices Layer Database Layer 2 La escalabilidad y alta disponibilidad nativas se dan la mano con el alto rendimiento necesario en una plataforma de microservicios. MongoDB and Microservices – Scalability
- 29. MongoDB proporciona funcionalidad de autenticación, control de acceso, auditoría y cifrado para proteger los despliegues de MongoDB. Las vistas read-only permiten exponer el modelo de datos de forma polimórfica y realizar ofuscación. Frontend Applications Digital & Mobile Apps Backend Applications … Operational & BI Reporting Application Layer API Access Layer Microservices Layer Database Layer 3 Seguridad nativa que protege los datos y facilita el desarrollo de aplicaciones al asumir el control de accesos y la visibilidad. MongoDB and Microservices – Security
- 30. Nuestra receta: Orquestación de MongoDB con Docker
- 31. Gestiona y provisiona los contenedores Convierte un grupo de contenedores en un único servicio Define una aplicación multicontenedor en un único fichero de descripción Ecosistema Docker
- 32. Orquestación Coordina los contenedores de MongoDB para realizar un despliegue según las mejores prácticas. Control de Recursos Dimensionado de cada instancia (y cada clúster) para evitar contención de recursos Docker
- 33. 5x más rápido que Kubernetes para lanzar un nuevo contenedor 7x más rápido que Kubernetes en listar los contenedores activos Evaluación de plataformas a gran escala 1000 instancias EC2 en un clúster ¿Rendimiento? ¿Capacidad operativa? ¿Facilidad de soporte? https://medium.com/on-docker/evaluating-container-platforms-at-scale- 5e7b44d93f2c#.k2fxds8c2 https://www.docker.com/survey-2016 Porqué Swarm?
- 34. swarm-node-2 swarm-node-3swarm-node-1 ¿Cómo conectamos los diferentes procesos mongod? • Swarm proporciona redes host a host • Utiliza el hostname definido en el archivo Compose magicmagic magic Redes multi host de Swarm
- 35. SECONDARY cgroup/docker cgroup/docker cgroup/docker cgroup/docker cgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker PRIMARY SECONDARY SECONDARY PRIMARY SECONDARY PRIMARYSECONDARY SECONDARY PRIMARYSECONDARY SECONDARY PRIMARYSECONDARY SECONDARY PRIMARYSECONDARY SECONDARY Tendremos un primario y al menos dos secundarios por aplicación. Definiremos reglas de afinidad en Docker Compose para evitar que los miembros de un mismo replicaset se desplieguen el en mismo servidor físico. Con Linux cgroups aislaremos los recursos (RAM / CPU / BlockIO) a lo que tendrá acceso cada mongod. MongoDB Ops/Cloud Manager es clave en este proceso ya que permite la provisión programática ! MACHINE 1 APP 1 MACHINE 2 MACHINE 3 APP 2 APP 3 APP 4 APP 5 APP 6 SECONDARY Despliegue en alta disponibilidad
- 36. SECONDARY cgroup/docker cgroup/docker cgroup/docker cgroup/docker cgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker cgroup/dockercgroup/docker cgroup/docker PRIMARY PRIMARY SECONDARY PRIMARY PRIMARY PRIMARYSECONDARY SECONDARY PRIMARYSECONDARY SECONDARY PRIMARYSECONDARY SECONDARY PRIMARYSECONDARY SECONDARY MACHINE 1 APP 1 MACHINE 2 MACHINE 3 APP 2 APP 3 APP 4 APP 5 APP 6 SECONDARY En caso de fallo a nivel de servidor alguno de los nodos secundarios tomará el rol de primario. Cuando los contenedores de la máquina en fallo se vuelvan a levantar, siempre que respeten los nombres la arquitectura se resincroniza. Evento de HA (La ley de Murphy)
- 37. Frontend Applications Digital & Mobile Apps Backend Applications … Operational & BI Reporting Application Layer API Access Layer Microservice s Layer Database Application Storage Modelo Uno: Contenedores para todos Pros: • Se despliega como un todo • Se migra fácilmente entre entornos Cons: • El storage debe ser persistente • La comunicación intra nodo es más compleja • Más difícil de debugear Arquitectura de referencia
- 38. Frontend Applications Digital & Mobile Apps Backend Applications … Operational & BI Reporting Application Layer API Access Layer Microservice s Layer Database Cluster Modelo Dos: Contenedores para la aplicación Pros: • Permite a la base de datos manejear su propia HA y escalado • Permite la separación entre las capas lógicas y de datos (Seguridad) • Más fácil de debuguear Cons: • La base de datos se provisiona de forma independiente. Arquitectura de referencia
- 39. • Nuevos clústers en segundos • Despliegues con redundancia y alta disponibilidad • Completamente elástico, sin pérdida de servicio • Parches automáticos y acceso inmediato a nuevas funcionalidades • Con autenticación y cifrado • Backup continuo con recuperación a la carta • Alertas personalizables y monitorización fina Completamente seguro Ya lo hacemos nosotros • Pago or uso. Facturación por horas • Soporte multi cloud (AWS ahora mismo, Azure & Google Cloud antes de verano) • Fácil migración mediante herramientas a despliegues cloud, on premise o híbridos. Sin trucos MongoDB Atlas Base de datos como servicio de MongoDB