Arquitectura de microservicios: aprender, construir e implementar microservicios



Este blog explica la arquitectura de microservicios en detalle. También incluye los pros y los contras y un estudio de caso que explica la arquitectura de UBER.

Arquitectura de microservicio:

De mi , debe tener un conocimiento básico de la arquitectura de microservicios.Pero, ser un profesional con requerirá algo más que lo básico. En este blog, profundizará en los conceptos arquitectónicos y los implementará utilizando un estudio de caso de UBER.

En este blog, aprenderá sobre lo siguiente:





  • Definición de arquitectura de microservicio
  • Conceptos clave de la arquitectura de microservicios
  • Pros y contras de la arquitectura de microservicios
  • UBER - Estudio de caso

Puede consultar el , para comprender los fundamentos y beneficios de los microservicios.

Solo será justo si le doy la definición de microservicios.



Definición de microservicios

Como tal, no existe una definición adecuada de Microservicios, también conocida como Arquitectura de Microservicio, pero se puede decir que es un marco que consiste en pequeños servicios implementables individualmente que realizan diferentes operaciones.

Los microservicios se centran en un único dominio empresarial que se puede implementar como servicios desplegables totalmente independientes e implementarlos en diferentes pilas de tecnología.

Diferencias entre arquitectura monolítica y microservicios - Arquitectura de microservicio - Edureka



Figura 1: Diferencia entre arquitectura monolítica y de microservicio - Arquitectura de microservicio

Consulte el diagrama anterior para comprender la diferencia entre la arquitectura monolítica y de microservicio.Para una mejor comprensión de las diferencias entre ambas arquitecturas, puede consultar mi blog anterior

Para que comprenda mejor, permítame contarle algunos conceptos clave de la arquitectura de microservicios.

Conceptos clave de la arquitectura de microservicios

Antes de comenzar a crear sus propias aplicaciones utilizando microservicios, debe tener claro el alcance y las funcionalidades de su aplicación.

A continuación, se muestran algunas pautas que se deben seguir al analizar los microservicios.

Directrices al diseñar microservicios

  • Como desarrollador, cuando decida construir una aplicación separe los dominios y sea claro con las funcionalidades.
  • Cada microservicio que diseñe se concentrará solo en un servicio de la aplicación.
  • Asegúrese de haber diseñado la aplicación de tal manera que cada servicio se pueda implementar individualmente.
  • Asegúrese de que la comunicación entre microservicios se realice a través de un servidor sin estado.
  • Cada servicio se puede refactorizar en servicios más pequeños, con sus propios microservicios.

Ahora que ha leído las pautas básicas al diseñar microservicios, comprendamos la arquitectura de los microservicios.

¿Cómo funciona la arquitectura de microservicios?

Una arquitectura de microservicio típica (MSA) debe constar de los siguientes componentes:

  1. Clientela
  2. Proveedores de identidad
  3. API de puerta de enlace
  4. Formatos de mensajería
  5. Bases de datos
  6. Contenido estático
  7. administración
  8. Descubrimiento de servicios

Hacer referencia al diagrama de abajo.

Figura 2: Arquitectura de microservicios - Arquitectura de microservicios

Sé que la arquitectura parece un poco compleja, peromesimplifíquelo para usted.

1. Clientes

algoritmo de búsqueda binaria en java

La arquitectura comienza con diferentes tipos de clientes, desde diferentes dispositivos que intentan realizar diversas capacidades de administración como buscar, construir, configurar, etc.

2. Proveedores de identidad

Estas solicitudes de los clientes luego se transmiten a los proveedores de identidad que autentican las solicitudes de los clientes y comunican las solicitudes a API Gateway. Luego, las solicitudes se comunican a los servicios internos a través de API Gateway bien definida.

3. API Gateway

Dado que los clientes no llaman a los servicios directamente, API Gateway actúa como un punto de entrada para que los clientes reenvíen solicitudes a los microservicios adecuados.

Las ventajas de utilizar una puerta de enlace API incluyen:

  • Todos los servicios se pueden actualizar sin que los clientes lo sepan.
  • Los servicios también pueden utilizar protocolos de mensajería que no son compatibles con la web.
  • API Gateway puede realizar funciones transversales como proporcionar seguridad, equilibrio de carga, etc.

Después de recibir las solicitudes de los clientes, la arquitectura interna consta de microservicios que se comunican entre sí a través de mensajes para manejar las solicitudes de los clientes.

4. Formatos de mensajería

Hay dos tipos de mensajes a través de los cuales se comunican:

  • Mensajes sincrónicos: En la situación en la que los clientes esperan las respuestas de un servicio, los microservicios suelen utilizar REST (Transferencia de estado representacional) ya que se basa en un cliente-servidor sin estado y el Protocolo HTTP . Este protocolo se utiliza por tratarse de un entorno distribuido todas y cada una de las funcionalidades están representadas con un recurso para realizar operaciones
  • Mensajes asincrónicos: En la situación en la que los clientes no esperan las respuestas de un servicio, los microservicios generalmente tienden a usar protocolos como AMQP, STOMP, MQTT . Estos protocolos se utilizan en este tipo de comunicación ya que la naturaleza de los mensajes está definida y estos mensajes deben ser interoperables entre implementaciones.

La siguiente pregunta que puede venir a su mente es ¿cómo manejan sus datos las aplicaciones que utilizan microservicios?

5. Manejo de datos

Bueno, cada Microservicio posee una base de datos privada para capturar sus datos e implementar la respectiva funcionalidad de negocio. Además, las bases de datos de Microservicios se actualizan solo a través de su API de servicio. Hacer referencia al diagrama de abajo:

cómo ejecutar php en windows 10

Figura 3: Representación de datos de manejo de microservicios - Arquitectura de microservicio

Los servicios proporcionados por los microservicios se transfieren a cualquier servicio remoto que admita la comunicación entre procesos para diferentes pilas de tecnología.

6. Contenido estático

Una vez que los microservicios se comunican entre sí, implementan el contenido estático en un servicio de almacenamiento basado en la nube que puede entregarlos directamente a los clientes a través de Redes de entrega de contenido (CDN) .

Además de los componentes anteriores, hay algunos otros componentes que aparecen en una arquitectura de microservicios típica:

7. Gestión

Este componente es responsable de equilibrar los servicios en los nodos e identificar fallas.

8. Descubrimiento de servicios

Actúa como una guía a los Microservicios para encontrar la ruta de comunicación entre ellos ya que mantiene una lista de servicios en los que se ubican los nodos.

Suscríbete a nuestro canal de youtube para recibir nuevas actualizaciones ..!

Ahora, analicemos los pros y los contras de esta arquitectura para comprender mejor cuándo usar esta arquitectura.

Pros y contras de la arquitectura de microservicios

Consulte la tabla de abajo.

Ventajas de la arquitectura de microservicios Contras del microservicio Arquitectura
Libertad para utilizar diferentes tecnologíasAumenta los desafíos de resolución de problemas
Cada microservicio se centra en la capacidad empresarial únicaAumenta el retraso debido a llamadas remotas
Admite unidades desplegables individualesMayores esfuerzos para la configuración y otras operaciones
Permite lanzamientos frecuentes de softwareDifícil de mantener la seguridad de las transacciones
Garantiza la seguridad de cada servicioDifícil de rastrear datos a través de varios límites de servicio
Se desarrollan e implementan múltiples servicios en paraleloDifícil de mover código entre servicios

Comprendamos más sobre los microservicios comparando la arquitectura anterior de UBER con la actual.

ESTUDIO DE CASO DE UBER

Arquitectura anterior de UBER

sobrecarga vs anulación en java

Como muchas startups, UBER comenzó su viaje con una arquitectura monolítica construida para una sola oferta en una sola ciudad. Tener una base de código parecía limpia en ese momento y resolvió los problemas comerciales centrales de UBER. Sin embargo, a medida que UBER comenzó a expandirse en todo el mundo, se enfrentaron rigurosamente a varios problemas con respecto a la escalabilidad y la integración continua.

Figura 4: Arquitectura monolítica de UBER - Arquitectura de microservicio

El diagrama anterior muestra la arquitectura anterior de UBER.

  • Existe una API REST con la que se conectan el pasajero y el conductor.
  • Se utilizan tres adaptadores diferentes con API dentro de ellos, para realizar acciones como facturación, pagos, envío de correos electrónicos / mensajes que vemos cuando reservamos un taxi.
  • Una base de datos MySQL para almacenar todos sus datos.

Entonces, si observa aquí, todas las funciones como la gestión de pasajeros, facturación, funciones de notificación, pagos, gestión de viajes y gestión de conductores se compusieron dentro de un solo marco.

Planteamiento del problema

Si bien UBER comenzó a expandirse en todo el mundo, este tipo de marco introdujo varios desafíos. Los siguientes son algunos de los desafíos destacados

  • Todas las funciones tuvieron que reconstruirse, implementarse y probarse una y otra vez para actualizar una sola función.
  • Corregir errores se volvió extremadamente difícil en un solo repositorio, ya que los desarrolladores tuvieron que cambiar el código una y otra vez.
  • Escalar las funciones simultáneamente con la introducción de nuevas funciones en todo el mundo fue bastante difícil de manejar en conjunto.

Solución

Para evitar tales problemas, UBER decidió cambiar su arquitectura y seguir a otras empresas de hipercrecimiento como Amazon, Netflix, Twitter y muchas otras. Por lo tanto, UBER decidió dividir su arquitectura monolítica en múltiples bases de código para formar una arquitectura de microservicio.

Consulte el diagrama a continuación para ver la arquitectura de microservicios de UBER.

Figura 5: Arquitectura de microservicio de UBER - Arquitectura de microservicio

  • El principal cambio que observamos aquí es la introducción de API Gateway a través del cual todos los conductores y pasajeros están conectados. Desde el API Gateway se conectan todos los puntos internos como la gestión de pasajeros, gestión de conductores, gestión de viajes y otros.
  • Las unidades son unidades desplegables independientes que realizan funciones independientes.
    • Por ejemplo: si desea cambiar algo en los microservicios de facturación, solo tiene que implementar solo los microservicios de facturación y no tiene que implementar los demás.
  • Todas las características ahora se escalaron individualmente, es decir, se eliminó la interdependencia entre todas y cada una de las características.
    • Por ejemplo, todos sabemos que la cantidad de personas que buscan taxis es más comparativamente mayor que las personas que realmente reservan un taxi y hacen pagos. Esto nos da una inferencia de que la cantidad de procesos que trabajan en el microservicio de gestión de pasajeros es mayor que la cantidad de procesos que trabajan en pagos.

En estocamino, UBER se benefició al cambiarsusarquitectura de lo monolítico a los microservicios.

Espero que haya disfrutado leyendo esta publicación sobre Arquitectura de microservicios.Se me ocurrirán más blogs, que también contendrán prácticas.
¿Está interesado en aprender más sobre microservicios?

Si desea aprender sobre microservicios y crear sus propias aplicaciones, consulte nuestra que viene con capacitación en vivo dirigida por un instructor y experiencia en proyectos de la vida real. Esta capacitación lo ayudará a comprender los microservicios en profundidad y lo ayudará a dominar el tema.

Tienes una pregunta para nosotros? Menciónelo en la sección de comentarios de ' Arquitectura de microservicio ”Y me pondré en contacto contigo.