Neste módulo, você implantará seu aplicativo node.js como um conjunto de serviços interconectados por trás de um Application Load Balancer (ALB). Em seguida, você usará o ALB para mudar o tráfego do monólito para microsserviços. Comece a compilar

Este é o processo que você seguirá para validar microsserviços e mudar o tráfego do aplicativo para longe do monólito com segurança.

visão geral da arquitetura
  1. Monólito implantado
    Esta é a configuração inicial. O aplicativo monolítico node.js em execução em um contêiner no Amazon ECS.
  2. Inicie microsserviços
    Usando as três imagens de contêiner criadas e enviadas por push ao Amazon ECR no módulo anterior, você iniciará três microsserviços no seu cluster do Amazon ECS.
  3. Configure Grupos-alvo
    Assim como no Módulo 2, você adicionará um grupo-alvo para cada serviço e atualizará o ALB Rules para se conectar a novos microsserviços.
  4. Mude o tráfego e desligue o monólito
    Ao alterar uma regra no ALB, você iniciará o tráfego de roteamento para os microsserviços em execução. Uma vez que tudo esteja íntegro, desligue o monólito.

Siga as instruções detalhadas abaixo para implantar os microsserviços. Clique em cada número de etapa para expandir a seção.

  • Etapa 1. Gravar definições de tarefas para os seus serviços

    Você implantará três novos microsserviços no mesmo cluster em execução do Módulo 2. Assim como no Módulo 2, você gravará Task Definitions para cada serviço.

    ⚐ OBSERVAÇÃO: é possível adicionar vários contêineres a uma definição de tarefa. Assim, você pode executar todos os três microsserviços como diferentes contêineres em um único serviço. Isso, no entanto, ainda seria monolítico posto que cada contêiner precisaria escalar de forma linear com o serviço. O objetivo é ter três serviços independentes e cada serviço requer sua própria definição de tarefa executando um contêiner com a imagem para esse respectivo serviço.

    Você pode gravar essas Definições de tarefas na UI do console ou acelerar as coisas gravando-as como JSON. Para gravar a definição da tarefa como um arquivo JSON, selecione Configurar por meio de JSON na parte inferior da nova tela Definição de tarefas.

    Os parâmetros para a definição de tarefa são:

    • Name = [service-name] 
    • Image = [service ECR repo URL]:latest 
    • cpu = 256 
    • memory = 256 
    • Container Port = 3.000 
    • Host Post = 0



    Ou com 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]"
    }

    ♻ Repita esse processo para criar uma definição de tarefa para cada serviço:

    • publicações
    • threads
    • usuários
  • Etapa 2. Configurar o Application Load Balancer: Grupos-alvo

    Assim como no Módulo 2, você irá configurar grupos-alvo para cada um dos seus serviços. Grupos-alvo permitem ao tráfego alcançar corretamente cada serviço.

    Verifique seu nome VPC: a pilha do AWS CloudFormation tem sua própria VPC, que possivelmente não é sua VPC padrão. É importante configurar seus grupos-alvo com a VPC correta.

    • Navegue até a Load Balancer section of the EC2 Console.
    • Você deve ver um Load Balancer já existente chamado demo.
    • Selecione a caixa de seleção para ver os detalhes do Load Balancer.
    • Observe o valor do atributo VPC na página de detalhes.

     

    Configurar grupos-alvo

    • Navegue até a seção grupo-alvo no console do EC2.
    • Selecione Create target group.
    • Configure o grupo-alvo (não modifique padrões se eles não são especificados aqui): Name = [service-name] Protocol = HTTP Port = 80 VPC = selecione a VPC que corresponde ao seu Load Balancer da etapa anterior.
      • Configurações avançadas de verificação de integridade: Limite íntegro 2 Limite não íntegro = 2 Timeout 5 Intervalo = 6
    • Selecione Create.

     

    ♻ Repita esse processo para criar um grupo-alvo para cada serviço:

    • publicações
    • threads
    • usuários

     

    Finalmente, Crie um quarto grupo-alvo

    • tráfego suspenso

    Este grupo-alvo é um alvo 'fictício'. Você irá usá-lo para evitar que o tráfego atinja seu monólito após seus microsserviços estarem totalmente em execução. Você deve ter um total de 5 grupos-alvo em sua tabela.

    grupos-alvo
  • Etapa 3. Configurar as regras de ouvinte

    O ouvinte verifica as solicitações de conexão recebidas para o ALB para direcionar o tráfego adequadamente.

    No momento, os seus quatro serviços (monólito e seus três microsserviços) estão sendo executados por trás do mesmo load balancer. Para fazer a transição de monólito para microsserviços, você iniciará o direcionamento do tráfego para o microsserviço e irá interromper o direcionamento de tráfego para o monólito.

    Abra seu ouvinte

    • Navegue até a Load Balancer section of the EC2 Console.
    • Você deve ver um Load Balancer já existente chamado demo.
    • Selecione a caixa de seleção para ver os detalhes do Load Balancer.
    • Selecione a guia Ouvintes.

     

    Atualizar as regras do ouvinte

    • Selecione Exibir/editar regras > para o ouvinte.
    • Selecione o + e insira a regra.
    • Os critérios das regras são:
      • IF Path = /api/[service-name]* THEN Forward to [service-name]
      • For example: Path = /api/posts* forward to posts
    • Crie quatro novas regras, uma para manter o tráfego para o monólito e uma para cada serviço. Você terá um total de cinco regras, incluindo a padrão. Certifique-se de ter adicionado as regras nesta ordem:
      • api: /api* forwards to api
      • users: /api/users* forwards to users
      • threads: /api/threads* forwards to threads
      • posts: /api/posts* forwards to posts
    • Selecione a seta na parte superior esquerda da página para retornar ao console do load balancer.
    configurar regras de ouvinte
  • Etapa 4. Implantar seus microsserviços

    Agora, você implantará os três serviços em seu cluster. Repita essas etapas para cada um dos três serviços:

    • Navegue até o menu "Clusters" no lado esquerdo do console do Amazon ECS.
    • Selecione seu cluster: BreakTheMonolith-Demo-ECSCluster.
    • Na guia Services, selecione Create.
    • Configure o serviço (não modifique nenhum valor padrão) Definição de tarefa = selecione o valor mais alto para X: [service-name]:X (X deve = 1 para a maioria dos casos) Nome do serviço = [nome-serviço] Número de tarefas = 1
    • Selecione Configure ELB
      • Tipo de ELB = Application Load Balancer
      • Para função do IAM, selecione BreakTheMonolith-Demo-ECSServiceRole
      • Selecione sua demonstração do Load Balancer
      • Selecione Add to ELB
    • Adicione o serviço ao grupo-alvo:
      • Porta do ouvinte = 80:HTTP
      • Nome do grupo-alvo = selecione seu grupo: [service-name]
    • Selecione Save.
    • Selecione Create Service.
    • Selecione View Service.


    Deve levar apenas alguns segundos para que todos os seus serviços iniciem. Verifique se todos os serviços e as tarefas são executadas e íntegras antes de prosseguir.

    implantar microsserviços
  • Etapa 5. Transferir o tráfego para os seus microsserviços

    No momento, seus microsserviços estão em execução, mas todo o tráfego ainda está fluindo para o seu serviço monolítico.

    Atualizar regras de ouvinte para redirecionar o tráfego para os microsserviços:

    • Navegue até a Load Balancer section of the EC2 Console
    • Selecione View/edit rules > for the listener on the demo load balancer.
    • Exclua a primeira regra (/api* forwards to api).
    • Atualize a regra padrão para encaminhar para o tráfego suspenso.

    Suas regras devem ser semelhantes a esta:

    transfira o tráfego para os seus microsserviços

    Desligue o monólito: agora, o tráfego está fluindo para os microsserviços e você pode reduzir o serviço monolítico.

    • Volte para o seu cluster do Amazon ECS BreakTheMonolith-Demo-ECSCluster.
    • Selecione o serviço API e, em seguida, Update.
    • Altere Number of Tasks para 0.
    • Selecione Update Service.

     

    Amazon ECS drenará qualquer conexão de contêineres que o serviço implantou no cluster e, em seguida, irá parar os contêineres. Se você atualizar as implantações ou as listas de tarefas após cerca de 30 segundos, você verá que o número de tarefas cairá para 0. O serviço ainda está ativo, portanto, se por algum motivo você precisar voltar, pode simplesmente atualizá-lo para implantar mais tarefas.

    • Selecione a API de serviço e, em seguida, clique em Delete e confirme a exclusão.


    Você agora realizou a completa transição do seu node.js de um monólito para microsserviços, sem qualquer tempo de inatividade!

  • Etapa 6. Validar sua implantação

    Encontre seu serviço URL: Este é o mesmo URL que você usou no Módulo 2 deste tutorial.

    • Navegue até a seção Load Balancers no console do EC2.
    • Selecione seu load balancer demo-microservices.
    • Copie e cole o valor do nome DNS para seu navegador.
    • Você deve ver uma mensagem assim: "Ready to receive requests".

     

    Veja os valores para cada microsserviço: Sua ALB direciona o tráfego com base no URL solicitado. Para ver cada serviço, basta adicionar o nome do serviço ao final do nome de DNS da seguinte forma:

    • http://[DNS name]/api/users
    • http://[DNS name]/api/threads
    • http://[DNS name]/api/posts
    ver os valores para cada microsserviço

    ⚐ OBSERVAÇÃO: esses URLs executam exatamente da mesma forma que quando o monólito é implantado. Isso é muito importante, porque as APIs ou os consumidores que esperariam se conectar a este aplicativo não serão afetados pelas alterações feitas. Ir de monólito para microsserviços não exigiu nenhuma alteração de outras partes de sua infraestrutura.

    Você também pode usar ferramentas como Postman para testar suas APIs.