As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Determinando a abordagem de integração para microsserviços no MES
Em um MES baseado em microsserviços, a service-to-service comunicação é essencial para trocar dados, compartilhar informações e garantir operações perfeitas. Os microsserviços MES podem trocar dados sobre eventos específicos ou em intervalos regulares. Por exemplo, um usuário pode fornecer a quantidade de produção durante uma transação de confirmação da produção. Essa transação pode iniciar várias transações em segundo plano, como enviar as informações para o ERP, capturar as horas de funcionamento da máquina, capturar informações de qualidade sobre produtos e relatar as horas de trabalho. Microsserviços diferentes podem ser responsáveis por essas tarefas, mas um único evento inicia todas elas por meio de um microsserviço.
Além disso, um MES também se integra a sistemas externos para otimizar as operações de fabricação, conectar roscas end-to-end digitais e automatizar processos. Ao criar um MES baseado em microsserviços, você deve decidir sobre a estratégia para lidar com a integração com serviços internos e externos.
Os padrões funcionais a seguir fornecem diretrizes sobre como selecionar a tecnologia certa com base no tipo de comunicação necessária.
Comunicações síncronas
Em um padrão de comunicação síncrona, o serviço de chamada é bloqueado até receber uma resposta do endpoint. Normalmente, o endpoint pode chamar outros serviços para processamento adicional. O MES exige comunicações síncronas para transações sensíveis à latência. Por exemplo, considere uma linha de produção contínua em que um usuário conclui uma operação em um pedido. O próximo usuário esperaria ver esse pedido chegar imediatamente para a próxima operação. Qualquer atraso nessas transações pode afetar negativamente o tempo de ciclo do produto e o desempenho da fábrica KPIs, além de causar tempo de espera adicional e subutilização de recursos.

Comunicações assíncronas
Nesse padrão de comunicação, o chamador não espera por uma resposta do endpoint ou de outro serviço. O MES adota esse padrão quando pode tolerar a latência sem afetar negativamente a transação comercial. Por exemplo, quando um usuário conclui uma operação usando uma máquina, talvez você queira reportar as horas de execução dessa máquina ao microsserviço de manutenção. Essa comunicação pode ser assíncrona, pois a atualização das horas de execução não inicia imediatamente um evento nem afeta a conclusão da operação.

Padrão Pub/sub
O pub/sub) pattern further extends asynchronous communications. Managing interdependent communications can become challenging as the MES matures and the number of microservices grows. You might not want to change a caller service every time you add a new service that has to listen to it. The pub/sub padrão publish-subscribe () resolve isso permitindo comunicações assíncronas entre vários microsserviços sem acoplamento estreito. Nesse padrão, um microsserviço publica mensagens de eventos em um canal que os microsserviços assinantes podem ouvir. Portanto, ao adicionar um novo serviço, você se inscreve no canal sem alterar o serviço de publicação. Por exemplo, um relatório de produção ou transação concluída da operação pode atualizar vários registros de registro e histórico de transações. Em vez de modificar essas transações sempre que você adiciona novos serviços de registro para máquinas, mão de obra, inventário, sistemas externos etc., você pode inscrever cada novo serviço na mensagem da transação original e tratá-la separadamente.

Comunicações híbridas
Os padrões de comunicação híbrida combinam padrões de comunicação síncrona e assíncrona.
AWS oferece vários serviços sem servidor
Produto da AWS |
Descrição |
Padrão de suportes |
||
---|---|---|---|---|
Síncrono |
Assíncrono |
Pub/Sub |
||
Permite que os microsserviços acessem dados, lógica de negócios ou funcionalidades de outros microsserviços. O API Gateway aceita e processa chamadas de API simultâneas para todos os três padrões de comunicação. |
✓ |
✓ |
✓ |
|
Fornece funcionalidade de computação sem servidor e orientada por eventos para executar código sem gerenciar servidores. As empresas podem usar o Lambda para desacoplar, processar e transmitir dados entre outros AWS serviços, como bancos de dados e serviços de armazenamento. |
✓ |
✓ |
✓ |
|
Suporta application-to-application mensagens (A2A) e application-to-person (A2P). O A2A fornece mensagens de alto rendimento baseadas em push entre sistemas distribuídos, microsserviços e aplicativos sem servidor. A funcionalidade A2P permite que você envie mensagens para pessoas com textos SMS, notificações push e e-mail. |
|
✓ |
✓ |
|
Permite enviar, armazenar e receber mensagens entre componentes de software em qualquer volume sem perder mensagens ou exigir que outros serviços estejam disponíveis. |
|
✓ |
✓ |
|
Fornece acesso em tempo real a eventos causados por alterações nos dados em um microsserviço ou em um AWS serviço dentro de um microsserviço sem escrever código. Você pode então receber, filtrar, transformar, rotear e entregar esse evento ao alvo. |
|
✓ |
✓ |
|
Serviço gerenciado de intermediário de mensagens que simplifica a configuração, a operação e o gerenciamento de agentes de mensagens no. AWS Os corretores de mensagens permitem que sistemas de software, que geralmente usam linguagens de programação diferentes em várias plataformas, se comuniquem e troquem informações. |
|
|
✓ |
Para obter mais informações, consulte Integração de microsserviços usando serviços AWS sem servidor no site da Orientação Prescritiva AWS .