Este artigo inclui uma lista de itens que você deve considerar ao mover uma solução de IoT para um ambiente de produção.
Usar selos de implantação
Os selos são unidades discretas dos principais componentes da solução que dão suporte otimizado a um número definido de dispositivos. Cada cópia é chamada de selo ou unidade de escala. Por exemplo, um selo pode consistir em uma população de dispositivos definida, um Hub IoT, um Hub de Eventos ou outro ponto de extremidade de roteamento, além de um componente de processamento. Cada selo dá suporte a uma população de dispositivo definida. Escolha o número máximo de dispositivos que o selo pode conter. À medida que a população do dispositivo aumenta, você adiciona instâncias de selos em vez de escalar de forma independente diferentes partes da solução.
Se, em vez de adicionar selos, você mover uma única instância de sua solução de IoT para produção, poderá encontrar as seguintes limitações:
Limites de escala: Sua instância única pode encontrar limites de dimensionamento. Por exemplo, sua solução pode usar serviços que têm limites no número de conexões de entrada, nomes de host, soquetes TCP ou outros recursos.
Dimensionamento ou custo não linear: Os componentes da solução podem não ser dimensionados linearmente com o número de solicitações feitas ou a quantidade de dados ingeridos. Em vez disso, para alguns componentes, pode haver uma diminuição no desempenho ou aumento no custo depois que um limite for atendido. Escalar verticalmente com maior capacidade pode não ser uma estratégia tão boa quanto escalar por meio da adição de selos.
Separação de clientes: pode ser necessário manter os dados de determinados clientes isolados dos dados de outros clientes. Da mesma forma, você pode ter alguns clientes que exigem mais recursos do sistema para atendimento do que outros, e considerar a possibilidade de agrupá-los em selos diferentes.
Instâncias de locatário único e multilocatário: Você pode ter alguns clientes grandes que precisam de suas próprias instâncias independentes da solução. Você também pode ter um pool de clientes menores que podem compartilhar uma implantação multilocatário.
Requisitos complexos de implantação: pode ser seja necessário implantar atualizações em seu serviço de maneira controlada e implantá-las em selos diferentes em momentos diferentes.
Frequência de atualização: você pode ter alguns clientes tolerantes a atualizações frequentes do sistema, enquanto outros podem estar avessos a riscos e desejar atualizações pouco frequentes do seu serviço.
Restrições geográficas ou geopolíticas: para reduzir a latência ou atender aos requisitos de soberania de dados, você pode implantar alguns de seus clientes em regiões específicas.
Para evitar os problemas anteriores, considere agrupar seu serviço em vários selos. Os selos operam independentemente uns dos outros e podem ser implantados e atualizados independentemente. Uma única região geográfica pode conter um único selo ou pode conter vários selos para permitir a expansão horizontal dentro da região. Cada selo contém um subconjunto dos seus clientes.
Usar a retirada quando ocorrer uma falha transitória
Todos os aplicativos que se comunicam com serviços e recursos remotos são suscetíveis a falhas transitórias. Especificamente, esse é o caso de aplicativos que são executados na nuvem, onde a natureza do ambiente e da conectividade pela Internet significam que esses tipos de falha provavelmente podem ser encontrados com mais frequência. As falhas transitórias incluem:
- Perda momentânea de conectividade de rede para componentes e serviços
- Indisponibilidade temporária de um serviço
- Surgimento de tempos limite quando um serviço está ocupado
- Colisões causadas quando os dispositivos transmitem simultaneamente
Muitas vezes, essas falhas são corrigidas por conta própria e, se a ação for repetida após um atraso razoável, provavelmente será bem-sucedida. No entanto, é difícil determinar os intervalos apropriados entre as tentativas. As estratégias comuns usam os seguintes tipos de intervalo de repetição:
- Retirada exponencial. O aplicativo aguarda pouco tempo antes da primeira repetição e depois os tempos aumentam exponencialmente entre as repetições subsequentes. Por exemplo, ele pode repetir a operação depois de 3 segundos, 12 segundos, 30 segundos e assim por diante.
- Intervalos regulares. O aplicativo aguarda o mesmo período entre cada tentativa. Por exemplo, ele pode repetir a operação a cada 3 segundos.
- Repetição imediata. Às vezes, uma falha transitória é curta, talvez devido a um evento como uma colisão de pacotes de rede ou um pico em um componente de hardware. Neste caso, repetir a operação imediatamente é apropriado, pois ela poderá ser bem-sucedida se a falha for removida no tempo que leva para o aplicativo montar e enviar a próxima solicitação. No entanto, nunca deverá haver mais de uma tentativa de repetição imediata, e você deverá adotar estratégias alternativas, como retirada exponencial ou ações de fallback, caso a repetição imediata falhe.
- Aleatoriedade. Qualquer uma das estratégias de repetição listadas acima pode incluir um elemento de aleatoriedade para impedir que várias instâncias do cliente enviem tentativas de repetição subsequentes ao mesmo tempo.
Evite também os seguintes anti-padrões:
- As implementações não devem incluir camadas duplicadas de código de nova tentativa.
- Nunca implemente um mecanismo de repetição infinita.
- Nunca execute uma repetição imediata mais de uma vez.
- Evite usar um intervalo de nova tentativa regular.
- Impeça que várias instâncias do mesmo cliente, ou várias instâncias de diferentes clientes, enviem repetições ao mesmo tempo.
Usar provisionamento de toque zero
O provisionamento é o ato de registrar um dispositivo no Hub IoT do Azure. O provisionamento torna o Hub IoT ciente do dispositivo e do mecanismo de atestado que o dispositivo usa. Você pode usar o DPS (Serviço de Provisionamento de Dispositivos no Hub IoT) do Azure ou provisionar diretamente por meio de APIs do Gerenciador de Registro do Hub IoT. O uso do DPS confere o benefício da associação tardia, que permite remover e reprovisionar dispositivos de campo para o Hub IoT sem alterar o software do dispositivo.
O exemplo a seguir mostra como implementar um fluxo de trabalho de transição de ambiente de teste para produção usando o DPS.
- O desenvolvedor da solução vincula as nuvens de IoT de Teste e Produção ao serviço de provisionamento.
- O dispositivo implementa o protocolo DPS para encontrar o Hub IoT, se ele não for mais provisionado. Inicialmente, o dispositivo é provisionado para o ambiente de teste.
- Como o dispositivo está registrado no ambiente de teste, ele se conecta lá e ocorre um teste.
- O desenvolvedor provisiona o dispositivo para o ambiente de produção e o remove do hub de teste. O hub de teste rejeitará o dispositivo na próxima vez que ele se reconectar.
- O dispositivo se conecta e negocia o fluxo de provisionamento. O DPS agora direciona o dispositivo para o ambiente de produção, e o dispositivo se conecta e se autentica lá.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Matthew Cosner | Gerente de Engenharia de Software Principal
- Ansley Yeo | Principal Gerente de Programa
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.