Conteúdo


Desenvolvendo aplicativos rapidamente (parte 5): utilizando padrões de operações para resiliência

Comments

[Rick Osowski (Senior Technical Staff Member) e Kyle Brown (IBM Distinguished Engineer/CTO) colaboraram com o Roland nesta publicação. – Ed.]

Nesta série em sete partes sobre desenvolvimento de aplicativos de microsserviços, fornecemos um contexto para definir um projeto piloto baseado em nuvem que melhor se ajusta às atuais necessidades e prepara para uma decisão de adoção da nuvem em mais longo prazo.

Aqui, na parte 5: consideramos os padrões de operações disponíveis para implementar seu aplicativo de microsserviços.

Esta é uma orientação para a série em geral:

Administrando a complexidade das operações

Embora um modelo de microsserviços acelere o processo mudando e implementando um único serviço em um aplicativo, ele também complica a implementação geral do aplicativo e aumenta o esforço de gerenciar e manter um conjunto de serviços em comparação ao cenário de um aplicativo monolítico correspondente.

Os padrões de operações para microsserviços, originalmente desenvolvidos para gerenciamento de aplicativos convencionais, aplicam-se ao que podemos chamar de lado de operações do conjunto de práticas conhecido como DevOps.

Padrão de registro de serviço

Um padrão de registro de serviço possibilita mudar a implementação dos microsserviços de recebimento de dados e também fornece a opção de variação do local do serviço em diferentes estágios de seu pipeline de DevOps. Isso é alcançado evitando-se a codificação permanente de terminais específicos de microsserviços em seu código. Sem o registro de serviço, seu aplicativo apresentaria problemas rapidamente à medida que mudanças de código começassem a se propagar por uma cadeia de chamadas de microsserviços.

Padrões de ID de correlação e de agregador de logs

Os padrões de ID de correlação e de agregador de logs alcançam um melhor isolamento, ao mesmo tempo em que possibilitam depurar microsserviços mais facilmente. O padrão de ID de correlação permite a propagação de rastreio por meio de diversos microsserviços escritos em várias linguagens diferentes. O padrão de agregador de logs complementa o ID de correlação permitindo que os logs de diferentes microsserviços sejam agregados em um único log passível de busca. Juntos, esses padrões permitem a depuração eficiente e compreensível de microsserviços, independentemente do número de serviços ou da profundidade de cada pilha de chamada.

Padrão de disjuntor

O padrão de disjuntor ajuda a evitar a perda de tempo com o gerenciamento de falhas de recebimento de dados, caso você saiba que elas já estão ocorrendo. Para fazer isso, você planta uma seção de código de “disjuntor” nas chamadas de serviço de envio de dados que detectam quando um serviço de recebimento de dados não está funcionando corretamente e evitam tentar chamá-lo. O benefício dessa abordagem é que cada chamada falha rapidamente em caso de lentidões. É possível fornecer uma melhor experiência geral a seus usuários e evitar o gerenciamento indevido de recursos, como encadeamentos e conjuntos de conexões, quando você sabe que as chamadas de recebimento de dados estão fadadas a falhar.

Os disjuntores permitem que o código do usuário verifique se dependências externas estão disponíveis antes da conexão efetiva ao sistema externo. Eles monitoram quais serviços falham e, com base nos limites, decidem se um serviço deve ser usado ou não. O disjuntor também oculta a complexidade do código do usuário final. Ele mantém as estatísticas ocultas e fornece respostas simples: disponível ou não.

É possível colocar um disjuntor em qualquer lugar entre um consumidor e um fornecedor de API. Mas colocá-lo mais próximo ao consumidor resulta em melhor conformidade com a determinação de DevOps de falhar rapidamente:

Padrão de handshaking

O padrão de handshaking, ao ativar um estado “parcialmente ativado” para os estados simples do disjuntor de “ativo” e “inativo”, inclui regulagem a um aplicativo implementado.

A regulagem é introduzida perguntando se um componente pode gerenciar mais trabalho antes de designar um trabalho a ele. Um componente que esteja muito ocupado pode pedir que os clientes recuem até que possa gerenciar mais solicitações.

Padrão de anteparo

O padrão de anteparo evita que falhas em uma parte de um sistema derrubem todo o sistema. O termo vem dos navios. Um navio é dividido em compartimentos separados e estanques para evitar que uma única avaria no casco inunde todo o navio; apenas um anteparo é inundado.

A implementação desse padrão pode assumir muitas formas, dependendo do tipo de falhas que você deseja isolar. Por exemplo, você pode limitar o número de chamadas simultâneas a componentes específicos. Dessa maneira, o número de recursos (geralmente encadeamentos) em espera por uma resposta do componente é limitado.

Atingindo e mantendo a resiliência

Um aspecto principal da arquitetura de microsserviços é que cada microsserviço tem seu próprio ciclo de vida. Cada microsserviço é propriedade de uma equipe autônoma e operado por ela. Diferentes equipes podem desenvolver, implementar e gerenciar seus respectivos microsserviços de forma independente, desde que mantenham a compatibilidade com a API. Essa agilidade, quando combinada a ferramentas de integração e implementação contínuas, permite que os aplicativos sejam implementados dezenas a centenas de vezes por dia.

Para atingir resiliência no processo de iterar um microsserviço e um aplicativo de microsserviços, a indução de falhas se faz necessária.

Engenharia do caos

Ao facilitar experimentos para desvendar fraquezas sistêmicas, a engenharia do caos aborda a incerteza de sistemas distribuídos em escala.

Os experimentos da engenharia do caos seguem quatro etapas:

  1. Definir como estado estável alguma saída mensurável de um sistema que indique comportamento normal.
  2. Criar hipóteses de que esse estado estável continuará tanto no grupo de controle quanto no grupo experimental.
  3. Introduzir variáveis que reflitam eventos do mundo real, como travamentos de servidores, mau funcionamento do disco rígido, conexões de rede interrompidas, etc.
  4. Tentar refutar a hipótese procurando uma diferença no estado estável entre o grupo de controle e o grupo experimental.

Quanto mais difícil for interromper o estado estável, mais confiança você poderá ter no comportamento do sistema. Qualquer fraqueza observada se torna alvo para melhoria, frequentemente evitando que o comportamento se manifeste no sistema em geral.

A automação também é um ponto chave do teste de resiliência. Estruturas como o Gremlin e ferramentas como Simian Army Chaos Monkey garantem que seus aplicativos possam tolerar falhas de instância aleatórias.

Chaos Monkey

O Chaos Monkey é a primeira contribuição para o Simian Army da equipe técnica da Netflix. Ele encerra, aleatoriamente, contêineres e instâncias de máquinas virtuais que são executados dentro de um ambiente.

Gremlin

Essa estrutura permite que você teste sistematicamente a lógica de recuperação de falhas em microsserviços de maneira independente da linguagem de programação e da lógica de negócios dos microsserviços.

O Gremlin aproveita o fato de que os microsserviços são frouxamente acoplados e interagem entre si exclusivamente por meio de uma rede. Ele intercepta os microsserviços de interação da rede (por exemplo, chamadas de API REST) e os manipula para imitar uma falha para o responsável pela chamada (por exemplo, retorna HTTP 503 ou reconfigura a conexão TCP). Ao observar a partir da rede como outros microsserviços estão reagindo a essa falha, agora, é possível fazer afirmações sobre o comportamento completo do aplicativo durante a falha. Em ambientes de produção, a injeção de falha do Gremlin pode se limitar somente a usuários sintéticos, para que os usuários reais permaneçam não afetados.

O que fazer a partir daqui:

Roland Barcia


Recursos para download


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Big data e análise de dados
ArticleID=1051513
ArticleTitle=Desenvolvendo aplicativos rapidamente (parte 5): utilizando padrões de operações para resiliência
publish-date=07272017