Itinerarios de aprendizaje en AWS:

Break the Monolith

Aprenda a segmentar su primer monolito e implementar los microservicios con contenedores en AWS

bloques de contenedores
introducción

Introducción

módulo uno

Cargar el monolito en contenedores

módulo dos

Implementar el monolito

módulo tres

Break the Monolith

paso cuatro

Implementar los microservicios

módulo cinco

Eliminar

Módulo 4 – Implementar los microservicios

En este módulo, implementará su aplicación node.js como conjunto de servicios interconectados detrás de un Application Load Balancer (ALB). A continuación, utilizará el ALB para desviar el tráfico del monolito a los microservicios. Empezar a construir

Información general de la arquitectura

Este es el proceso que seguirá para soportar los microservicios y realizar una transición de forma segura del tráfico de la aplicación de esos monolitos.

Información general de la arquitectura
  1. Monolito implementado
    Esta es la configuración de inicio. La aplicación de node.js monolítica se ejecuta en un contenedor en Amazon ECS.
  2. Empezar los microservicios
    Al usar las tres imágenes de contenedores que ha creado y enviado a Amazon ECR en el módulo anterior, podrá iniciar tres microservicios en su clúster de Amazon ECS.
  3. Configurar grupos de destino
    Al igual que en el módulo 2, podrá añadir un grupo de destino para cada servicio y actualizar las reglas de ALB para conectar los nuevos microservicios.
  4. Cambiar el tráfico y apagar el monolito
    Al cambiar una regla en el ALB, empezará la ejecución del tráfico de enrutamiento a los microservicios en ejecución. Después de que todo esté en buen estado, cierre el monolito.

Tiempo de realización: 30 minutos

Servicios utilizados:

Instrucciones de implementación

Siga las instrucciones paso a paso que se detallan a continuación para implementar los microservicios. Haga clic en cada número de paso para expandir la sección.

  • Paso 1. Escriba definiciones de tareas para sus servicios

    Implementará tres nuevos microservicios en el mismo clúster que tiene en ejecución del Módulo 2. Al igual que en el módulo 2, escribirá definiciones de tareas para cada servicio.

    ⚐ NOTA: Es posible añadir varios contenedores a una definición de tarea, por lo que es posible ejecutar los tres microservicios como contenedores diferentes en un solo servicio. Este no obstante, seguiría siendo monolítico ya que cada contenedor necesitaría escalar de forma lineal con el servicio. Su objetivo es tener tres servicios independientes y cada servicio requiere su propia definición de tarea que se ejecuta en un contenedor con la imagen de ese servicio correspondiente.

    Puede escribir estas definiciones de tareas en la interfaz de usuario de la consola o acelerar las cosas al escribirlas como JSON. Para escribir la definición de tarea como un archivo JSON, seleccione Configurar a través de JSON en la parte inferior de la pantalla de la nueva definición de tareas.

    Los parámetros para la definición de tarea son:

    • Nombre = [service-name] 
    • Imagen = [service ECR repo URL]:latest 
    • cpu = 256 
    • memoria = 256 
    • Puerto del contenedor = 3000 
    • Puerto de alojamiento = 0



    O con JSON:

    {
    "containerDefinitions": [
        {
            "name": "[service-name]",
            "image": "[account-id].dkr.ecr.us-west-2.amazonaws.com/[service-name]:[tag]",
            "memoryReservation": "256",
            "cpu": "256",
            "essential": true,
            "portMappings": [
                {
                    "hostPort": "0",
                    "containerPort": "3000",
                    "protocol": "tcp"
                }
            ]
        }
    ],
    "volumes": [],
    "networkMode": "bridge",
    "placementConstraints": [],
    "family": "[service-name]"
}

    ♻ Repetir este proceso para crear una definición de tarea para cada servicio:

    • publicaciones
    • subprocesos
    • usuarios

  • Paso 2. Configurar el Application Load Balancer: Grupos de destino

    Al igual que en el módulo 2, configurará grupos de destino para cada uno de sus servicios. Los grupos de destino permiten que el tráfico llegue correctamente a cada servicio.

    Compruebe el nombre de la VPC: La pila de AWS CloudFormation tiene su propia VPC, lo más probable es que no sea su VPC predeterminada. Es importante configurar sus grupos de destino con la VPC.

    • Vaya a la sección Load Balancer de la consola de EC2.
    • Debería ver que un balanceador de carga ya existe con el nombre de demo.
    • Seleccione la casilla para ver los detalles del balanceador de carga.
    • Tenga en cuenta el valor del atributo de VPC en la página de detalles.

     

    Configurar grupos de destino

    • Vaya a la sección Grupo de destino de la consola de EC2.
    • Seleccione Crear grupo de destino.
    • Configure el grupo de destino (no modifique valores predeterminados si no se especifica aquí): Nombre = [service-name] Protocolo = HTTP Puerto = 80 VPC = seleccione la VPC que coincida con el balanceador de carga en el paso anterior.
      • Configuración avanzada de comprobación de estado: umbral en buen estado = 2 umbral en mal estado = 2 Límite de tiempo = 5 Intervalos = 6
    • Seleccione Create (Crear).

     

    ♻ Repetir este proceso para crear un grupo de destino para cada servicio:

    • publicaciones
    • subprocesos
    • usuarios

     

    Por último, cree un cuarto grupo de destino

    • tráfico de descarga

    Este grupo de destino tiene un destino de "maniquí". Lo utilizará para evitar que el tráfico llegue a su monolito después de que sus microservicios estén en ejecución. Debe tener 5 grupos de destino total en su tabla.

    grupos de destino

  • Paso 3. Configurar las reglas del agente de escucha

    El agente de escucha comprueba las solicitudes de conexión entrantes al ALB para enrutar el tráfico de forma adecuada.

    En estos momentos, cuatro de sus servicios (monolito y sus tres microservicios) se ejecutan detrás del mismo balanceador de carga. Para realizar la transición del monolito a los microservicios, comience a enrutar el tráfico a los microservicios y detenga el enrutamiento del tráfico al monolito.

    Abra su agente de escucha

    • Vaya a la sección Load Balancer de la consola de EC2.
    • Debería ver que un balanceador de carga ya existe con el nombre de demo.
    • Seleccione la casilla para ver los detalles del balanceador de carga.
    • Seleccione la pestaña Agente de escucha.

     

    Actualizar las reglas del agente de escucha

    • Seleccione View/edit rules (Ver/editar reglas) > for the listener (para el agente de escucha).
    • Seleccione + e insertar regla.
    • Los criterios de las reglas son:
      • IF Path = /api/[service-name]* THEN Forward to [service-name]
      • Por ejemplo: Path = /api/posts* forward to posts
    • Cree cuatro nuevas reglas, una para mantener el tráfico al monolito y otra para cada servicio. Tendrá un total de cinco reglas, incluyendo la predeterminada. Asegúrese de añadir las reglas en este orden:
      • api: /api* forwards to api
      • usuarios: /api/users* forwards to users
      • subprocesos: /api/threads* forwards to threads
      • publicaciones: /api/posts* forwards to posts
    • Seleccione la flecha en la parte superior izquierda de la página para volver a la consola del balanceador de carga.
    configurar las reglas del agente de escucha

  • Paso 4. Implemente sus microservicios

    Ahora, implemente sus tres servicios en el clúster. Repita estos pasos para cada uno de los tres servicios:

    • Vaya al menú "Clústers" en la parte izquierda de la consola de Amazon ECS.
    • Seleccione el clúster: BreakTheMonolith-Demo-ECSCluster.
    • En la pestaña de servicios, seleccione Create (Crear).
    • Configure el servicio (no modifique los valores predeterminados) Definición de tarea = seleccionar el máximo valor para X: [service-name]: X (X debería = 1 para la mayoría de los casos) Nombre del servicio = [service-name] Número de tareas = 1
    • Seleccione Configurar ELB
      • Tipo de ELB = Application Load Balancer
      • Para la función de IAM, seleccione BreakTheMonolith-Demo-ECSServiceRole
      • Seleccione la demostración del balanceador de carga
      • Seleccione Añadir a ELB
    • Añada su servicio para el grupo de destino:
      • Puerto de agente de escucha = 80: HTTP
      • Nombre del grupo de destino = seleccionar su grupo: [service-name]
    • Seleccione Save (Guardar).
    • Seleccione Create Service (Crear servicio).
    • Seleccione View Service (Ver servicio).


    Todos sus servicios deberían iniciarse transcurridos unos segundos. Compruebe que todos los servicios y las tareas se están ejecutando y se encuentran en buen estado antes de continuar.

    implementar los microservicios

  • Paso 5. Cambiar el tráfico a sus microservicios

    En estos momentos, los microservicios se están ejecutando, pero todo el tráfico sigue yendo a su servicio de monolito.

    Actualizar las reglas del agente de escucha para enrutar de nuevo el tráfico a los microservicios:

    • Vaya a la sección Load Balancer de la consola de EC2
    • Seleccione View/edit rules (Ver/editar reglas) > para el agente de escucha en el balanceador de carga de demostración.
    • Elimine la primera regla (/api* forwards to api).
    • Actualice la regla predeterminada que reenviar para rechazar tráfico.

    Su reglas debería verse así:

    cambiar el tráfico a sus microservicios

    Apague el monolito: Ahora, el tráfico fluye a sus microservicios y podrá desactivar el servicio monolítico.

    • Vuelva a su clúster de Amazon ECS BreakTheMonolith-Demo-ECSCluster.
    • Seleccione el servicio api y, a continuación, Update (Actualizar).
    • Cambiar el número de tareas a 0.
    • Seleccione Update Service (Actualizar servicio).

     

    Amazon ECS ahora vaciará las conexiones de contenedores que el servicio ha implementado en el clúster y, a continuación, detendrá los contenedores. Si actualiza las implementaciones o listas de tareas después de unos 30 segundos, verá que el número de tareas se reducirá a 0. El servicio está activo, por lo que si necesita restaurar por cualquier motivo, podría simplemente actualizarlo para implementar más tareas.

    • Seleccione el servicio api y, a continuación, Delete (Eliminar) y confirme la eliminación.


    Ha trasladado totalmente su node.js desde el monolito a los microservicios, sin tiempo de inactividad.

  • Paso 6. Valide su implementación

    Encuentre su servicio URL: Esta es la misma URL que ha utilizado en el módulo 2 de este tutorial.

    • Vaya a la sección Load Balancers de la consola de EC2.
    • Seleccione los microservicios de demostración del balanceador de carga.
    • Copie y pegue el valor para el nombre de DNS en su navegador.
    • Debería ver un mensaje "Listo para recibir solicitudes".

     

    Consulte los valores para cada microservicio: su ALB enruta el tráfico en función de la solicitud URL. Para ver cada servicio, solo tiene que añadir el nombre del servicio al final de su nombre DNS así:

    • http://[DNS name]/api/users
    • http://[DNS name]/api/threads
    • http://[DNS name]/api/posts
    ver los valores para cada microservicio

    ⚐ NOTA: Estas direcciones URL se ejecutan exactamente igual que cuando el monolito se implementa. Esto es muy importante porque cualquier API o los consumidores que esperarían conectarse a esta aplicación no se verán afectados por los cambios que ha realizado. Ir desde el monolito a los microservicios no requiere cambios a otras partes de su infraestructura.

    También puede utilizar herramientas como Postman (correo) para probar sus API.

Siguiente: Eliminar