Apresentamos a arquitetura de referência de microsserviços da NGINX

Chris Stetson

Nota do autor – Este post é o primeiro de uma série:

1. Apresentando a arquitetura de referência de microsserviços do NGINX (este post)
2. MRA, Parte 2: O Modelo de Proxy
3. MRA, Parte 3: O modelo de malha de roteadores
4. MRA, Parte 4: O Modelo de Fabric
5. MRA, Parte 5: Adaptando o aplicativo de doze fatores para microsserviços
6. MRA, Parte 6: Implementando o padrão Circuit Breaker com NGINX Plus

Todos os seis posts, além de um post sobre front-ends web para aplicações de microsserviços<.htmla>, foram reunidos em um e-book gratuito.

Confira também estes outros recursos da NGINX sobre microsserviços:

• Uma série muito útil e popular de Chris Richardson sobre design de aplicações de microsserviços
• Os artigos de Chris Richardson reunidos em um e-book gratuito, com dicas adicionais sobre como implementar microsserviços com o NGINX e o NGINX Plus
• Outras publicações de blog sobre microsserviços
• Webinars sobre microsserviços
• Página de soluções de microsserviços
• Tópico: Microsserviços

Introdução

O NGINX está envolvido no movimento de microsserviços desde o início. Por ser leve, flexível e oferecer alto desempenho, o NGINX é uma excelente opção para microsserviços.

A imagem Docker do NGINX é a imagem de aplicativo mais baixada no Docker Hub, e a maioria das plataformas de microsserviços disponíveis atualmente na Web inclui uma demonstração que implanta o NGINX de alguma forma e se conecta à página de boas-vindas.

Como acreditamos que a migração para microsserviços é crucial para o sucesso de nossos clientes, nós da NGINX lançamos um programa dedicado ao desenvolvimento de recursos e práticas que apoiem essa transformação profunda no desenvolvimento e na entrega de aplicações web. Também reconhecemos que existem muitas abordagens diferentes para implementar microsserviços, várias delas inovadoras e específicas às necessidades de cada equipe de desenvolvimento. Acreditamos que são necessários modelos que facilitem o desenvolvimento e a entrega de aplicações baseadas em microsserviços pelas empresas.

Com tudo isso em mente, nós da equipe de Serviços Profissionais da NGINX estamos desenvolvendo a Arquitetura de Referência de Microsserviços da NGINX (MRA) – um conjunto de modelos que você pode usar para criar suas próprias aplicações de microsserviços.

A MRA é composta por dois componentes: uma descrição detalhada de cada um dos três Modelos e um código para download que implementa nosso programa de exemplo de compartilhamento de fotos, o Ingenious. A única diferença entre os três Modelos é o código de configuração usado para configurar o NGINX Plus em cada um deles. Esta série de posts no blog apresentará uma visão geral de cada um dos Modelos; descrições detalhadas, o código de configuração e o código do programa de exemplo Ingenious serão disponibilizados ainda este ano.

Nosso objetivo ao criar esta Arquitetura de Referência é triplo:

• Fornecer aos clientes e ao setor modelos prontos para uso na criação de sistemas baseados em microsserviços, acelerando e aprimorando o desenvolvimento
• Criar uma plataforma para testar novos recursos no NGINX e no NGINX Plus, sejam eles desenvolvidos interna ou externamente e distribuídos no núcleo do produto ou como módulos dinâmicos
• Para nos ajudar a entender os sistemas e componentes dos parceiros, de modo que possamos obter uma visão holística do ecossistema de microsserviços

A Arquitetura de Referência de Microsserviços também é uma parte importante das ofertas de serviços profissionais para os clientes da NGINX. Na MRA, usamos recursos comuns ao NGINX Open Source e ao NGINX Plus sempre que possível, e recursos específicos do NGINX Plus quando necessário. As dependências do NGINX Plus são maiores nos modelos mais complexos, conforme descrito abaixo. Acreditamos que muitos usuários da MRA se beneficiarão do acesso aos serviços profissionais da NGINX e ao suporte técnico, incluído em uma assinatura do NGINX Plus.

Uma visão geral da arquitetura de referência de microsserviços

Estamos desenvolvendo a Arquitetura de Referência em conformidade com os princípios do Aplicativo de Doze Fatores. Os serviços foram projetados para serem leves, efêmeros e sem estado.

A MRA utiliza componentes padrão do setor, como contêineres Docker, uma ampla variedade de linguagens — Java, PHP, Python, NodeJS/JavaScript e Ruby — e redes baseadas no NGINX.

Uma das maiores mudanças no design e na arquitetura de aplicações ao migrar para microsserviços é o uso da rede para a comunicação entre os componentes funcionais da aplicação. Em aplicações monolíticas, os componentes se comunicam na memória. Em uma aplicação de microsserviços, essa comunicação ocorre pela rede, por isso o design e a implementação da rede tornam-se extremamente importantes.

Para refletir isso, a MRA foi implementada usando três modelos de rede diferentes, todos eles utilizando o NGINX ou o NGINX Plus. Esses modelos variam de relativamente simples a mais complexos e repletos de recursos:

• Modelo de proxy – Um modelo de rede simples, adequado para implementar o NGINX Plus como controlador ou gateway de API para uma aplicação de microsserviços. Esse modelo é baseado no Docker Cloud.
• Modelo de malha de roteadores – Uma abordagem de rede mais robusta, com um balanceador de carga em cada host e gerenciamento das conexões entre os sistemas. Esse modelo é semelhante à arquitetura do Deis 1.0.
• Modelo Fabric – A joia da coroa da MRA, o Modelo Fabric conta com o NGINX Plus em cada contêiner, gerenciando todo o tráfego de entrada e saída. Ele funciona bem em sistemas de alta carga e oferece suporte a SSL/TLS em todos os níveis, com o NGINX Plus proporcionando menor latência, conexões SSL/TLS persistentes, descoberta de serviços e o padrão circuit breaker em todos os microsserviços.

Nossa intenção é que você use esses modelos como ponto de partida para suas próprias implementações de microsserviços. Agradecemos também seus comentários sobre como podemos aprimorar a MRA. (Você pode começar adicionando um comentário abaixo.)

A seguir, apresentamos uma breve descrição de cada modelo. Sugerimos que você leia todas as descrições para começar a entender como aproveitar melhor um ou mais desses modelos. Futuras publicações no blog descreverão cada modelo em detalhes, um por publicação.

Resumo do Modelo de Proxy

O Modelo de Proxy é um modelo de rede relativamente simples. É um excelente ponto de partida para uma aplicação inicial de microsserviços ou um modelo-alvo ao converter uma aplicação monolítica legada de complexidade moderada.

No Modelo de Proxy, o NGINX ou o NGINX Plus atua como um controlador de entrada, encaminhando solicitações para microsserviços. O NGINX Plus pode usar DNS dinâmico para a descoberta de serviços à medida que novos serviços são criados. O Modelo de Proxy também é adequado para uso como modelo ao utilizar o NGINX como um gateway de API.

Se a comunicação entre serviços for necessária – como ocorre na maioria das aplicações com algum nível de complexidade –, o registro de serviços fornece o mecanismo necessário dentro do cluster. (Consulte esta publicação do blog para ver uma lista detalhada dos mecanismos de comunicação entre serviços.) O Docker Cloud usa essa abordagem por padrão; para se conectar a outro serviço, um serviço consulta o DNS e obtém um endereço IP para o qual enviar uma solicitação.

Em geral, o Modelo de Proxy é adequado para aplicações simples a moderadamente complexas. Ele não é a abordagem nem o modelo mais eficiente para balanceamento de carga, especialmente em grande escala; use um dos modelos descritos abaixo se você tiver requisitos elevados de balanceamento de carga. (“Escala” pode se referir tanto a um grande número de microsserviços quanto a altos volumes de tráfego.)

Editor – Para uma análise aprofundada desse modelo, consulte MRA, Parte 2 – O Modelo de Proxy.

Avançando para o modelo de malha de roteadores

O Modelo de Malha de Roteadores tem complexidade moderada e é uma boa opção para projetos robustos de novas aplicações, bem como para a conversão de aplicações legadas monolíticas mais complexas que não precisam dos recursos do Modelo de Malha.

O Modelo de Malha de Roteadores adota uma abordagem de rede mais robusta do que o Modelo de Proxy, executando um balanceador de carga em cada host e gerenciando ativamente as conexões entre microsserviços. O principal benefício do Modelo de Malha de Roteadores é um balanceamento de carga mais eficiente e robusto entre os serviços. Se você usar o NGINX Plus, poderá implementar verificações ativas de integridade para monitorar as instâncias individuais dos serviços e reduzir o tráfego gradualmente quando elas forem desativadas.

Deis Workflow usa uma abordagem semelhante ao Modelo de Malha de Roteadores para rotear o tráfego entre serviços, com instâncias do NGINX em execução em um contêiner em cada host. À medida que novas instâncias do aplicativo são iniciadas, um processo extrai as informações dos serviços do registro de serviços etcd e as carrega no NGINX. O NGINX Plus também pode funcionar nesse modo, usando vários locais e seus respectivos upstreams.

Nota do editor – Para uma análise aprofundada desse modelo, consulte MRA, Parte 3 – O modelo de malha de roteadores.

E, por fim – o modelo de malha, com SSL/TLS opcional

Nós, da NGINX, estamos especialmente entusiasmados com o Modelo de Malha. Ele concretiza algumas das promessas mais empolgantes dos microsserviços, incluindo alto desempenho, flexibilidade no balanceamento de carga e SSL/TLS onipresente até o nível de cada microsserviço. O Modelo de Malha é adequado para aplicações seguras e pode ser dimensionado para aplicações de grande porte.

No Modelo Fabric, o NGINX Plus é implantado em cada contêiner e se torna o proxy de todo o tráfego HTTP que entra e sai dos contêineres. As aplicações se comunicam com um endereço localhost para todas as conexões de serviço e contam com o NGINX Plus para realizar a descoberta de serviços, o balanceamento de carga e as verificações de integridade.

Em nossa configuração, o NGINX Plus consulta o ZooKeeper para localizar todas as instâncias dos serviços aos quais o aplicativo precisa se conectar. Com a configuração de frequência do DNS, valid, definida como 1 segundo, por exemplo, o NGINX Plus verifica o ZooKeeper a cada segundo em busca de alterações nas instâncias e encaminha o tráfego adequadamente.

Graças ao poderoso processamento de HTTP do NGINX Plus, podemos usar conexões persistentes para manter conexões com estado com os microsserviços, reduzindo a latência e melhorando o desempenho. Esse recurso é especialmente valioso ao usar SSL/TLS para proteger o tráfego entre os microsserviços.

Por fim, usamos as verificações ativas de integridade do NGINX Plus para direcionar o tráfego a instâncias íntegras e, essencialmente, incorporar o padrão circuit breaker sem custo adicional.

Nota do editor – Para uma análise aprofundada desse modelo, consulte MRA, Parte 4 – O modelo de malha.

Um aplicativo de demonstração engenhoso para a MRA

A MRA inclui um aplicativo de exemplo como demonstração: o Ingenious, um aplicativo de compartilhamento de fotos. O Ingenious é implementado em cada um dos três modelos – Proxy, Router Mesh e Fabric. O aplicativo de demonstração Ingenious será disponibilizado ao público ainda este ano.

O Ingenious é uma versão simplificada de um aplicativo de armazenamento e compartilhamento de fotos, semelhante ao Flickr ou ao Shutterfly. Escolhemos um aplicativo de compartilhamento de fotos por alguns motivos:

• É fácil tanto para os usuários quanto para os desenvolvedores entender o que ele faz.
• Há várias dimensões de dados para gerenciar.
• É fácil incorporar um design bonito ao aplicativo.
• Ele oferece requisitos de computação assimétricos — uma combinação de processamento de alta e baixa intensidade —, o que permite testar de forma realista os recursos de failover, escalabilidade e monitoramento em diferentes tipos de funcionalidade.

Conclusão

A Arquitetura de Referência de Microsserviços da NGINX é um avanço empolgante para nós e para os clientes e parceiros com quem a compartilhamos até o momento. Nos próximos meses, publicaremos uma série de posts no blog descrevendo-a em detalhes e a disponibilizaremos ainda este ano. Também falaremos sobre ela em detalhes na nginx.conf 2016, de 7 a 9 de setembro, em Austin, Texas. Envie-nos seus comentários. Esperamos encontrar você lá.

Enquanto isso, experimente você mesmo a MRA com o NGINX Plus – inicie sua avaliação gratuita de 30 dias hoje mesmo ou entre em contato conosco para conversar sobre seus casos de uso.

Sobre o autor

Chris Stetson

Mais publicações de Chris Stetson