BLOG | NGINX

Apresentando a Arquitetura de Referência de Microsserviços da NGINX

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Chris Stetson
Chris Stetson
Publicado em 18 de abril de 2016

Nota do autorEsta postagem do blog é a primeira de uma série:

  1. Apresentando a arquitetura de referência de microsserviços NGINX (esta postagem)
  2. MRA, Parte 2: O modelo proxy
  3. MRA, Parte 3: O modelo de malha do roteador
  4. MRA, Parte 4: O modelo de tecido
  5. MRA, Parte 5: Adaptando o aplicativo Twelve‑Factor para microsserviços
  6. MRA, Parte 6: Implementando o padrão Circuit Breaker com NGINX Plus

Todos os seis blogs, além de um blog sobre frontends web para aplicativos de microsserviços<.htmla>, foram reunidos em um e-book gratuito .

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

INTRODUÇÃO

A NGINX está envolvida no movimento de microsserviços desde o início. A natureza leve, de alto desempenho e flexível do NGINX é uma ótima opção para microsserviços.

A imagem do NGINX Docker é a imagem de aplicativo mais baixada no Docker Hub, e a maioria das plataformas de microsserviços que você encontra na Web hoje 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 para desenvolver recursos e práticas em suporte a essa mudança radical no desenvolvimento e entrega de aplicativos web. Também reconhecemos que existem muitas abordagens diferentes para implementar microsserviços, muitas delas novas e específicas para as necessidades de equipes de desenvolvimento individuais. Acreditamos que há necessidade de modelos que facilitem o desenvolvimento e a entrega de aplicativos baseados em microsserviços por parte das empresas.

Com tudo isso em mente, nós aqui da NGINX Professional Services estamos desenvolvendo a NGINX Microservices Reference Architecture (MRA) – um conjunto de modelos que você pode usar para criar seus próprios aplicativos de microsserviços.

O MRA é composto por dois componentes: uma descrição detalhada de cada um dos três modelos, além de um código para download que implementa nosso programa de compartilhamento de fotos de exemplo, o Ingenious. A única diferença entre os três modelos é o código de configuração usado para configurar o NGINX Plus para cada um deles. Esta série de postagens de blog fornecerá descrições gerais de cada um dos modelos; descrições detalhadas, código de configuração e código para o programa de amostra Ingenious serão disponibilizados ainda este ano.

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

  • Fornecer aos clientes e à indústria projetos prontos para uso para a construção de sistemas baseados em microsserviços, acelerando e melhorando o desenvolvimento
  • Criar uma plataforma para testar novos recursos no NGINX e NGINX Plus, 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 para que possamos obter uma perspectiva 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 clientes NGINX. No 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 mais fortes nos modelos mais complexos, conforme descrito abaixo. Prevemos que muitos usuários do MRA se beneficiarão do acesso aos serviços profissionais do NGINX e ao suporte técnico, que vêm com uma assinatura do NGINX Plus.

Uma Visão Geral da Arquitetura de Referência de Microsserviços

Estamos construindo a Arquitetura de Referência para estar em conformidade com os princípios do Twelve‑Factor App . Os serviços são projetados para serem leves, efêmeros e sem estado.

O MRA usa componentes padrão da indústria, como contêineres Docker, uma ampla variedade de linguagens – Java, PHP, Python, NodeJS/JavaScript e Ruby – e redes baseadas em NGINX.

Uma das maiores mudanças no design e na arquitetura do aplicativo ao migrar para microsserviços é usar a rede para comunicação entre componentes funcionais do aplicativo. Em aplicativos monolíticos, os componentes do aplicativo se comunicam na memória. Em um aplicativo de microsserviços, essa comunicação acontece pela rede, então o design e a implementação da rede se tornam extremamente importantes.

Para refletir isso, o MRA foi implementado usando três modelos de rede diferentes, todos os quais usam NGINX ou NGINX Plus. Eles variam de relativamente simples a ricos em recursos e mais complexos:

  • Modelo de proxy – Um modelo de rede simples adequado para implementar o NGINX Plus como um controlador ou gateway de API para um aplicativo de microsserviços. Este modelo é construído sobre o Docker Cloud.
  • Modelo de malha de roteador – Uma abordagem mais robusta para redes, com um balanceador de carga em cada host e gerenciamento das conexões entre os sistemas. Este modelo é semelhante à arquitetura do Deis 1.0 .
  • Modelo de Tecido – A joia da coroa do MRA, o Modelo de Tecido apresenta o NGINX Plus em cada contêiner, lidando com todo o tráfego de entrada e saída. Ele funciona bem para sistemas de alta carga e oferece suporte a SSL/TLS em todos os níveis, com o NGINX Plus fornecendo latência reduzida, conexões SSL/TLS persistentes, descoberta de serviço e padrão de disjuntor 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 e agradecemos seu feedback sobre como melhorar o MRA. (Você pode começar adicionando aos comentários abaixo.)

Segue uma breve descrição de cada modelo; sugerimos que você leia todas as descrições para começar a ter uma ideia de como você pode usar melhor um ou mais modelos. Postagens futuras do blog descreverão cada um dos modelos em detalhes, um por postagem.

O modelo proxy em resumo

O modelo proxy é um modelo de rede relativamente simples. É um excelente ponto de partida para um aplicativo inicial de microsserviços ou como um modelo de destino na conversão de um aplicativo legado monolítico moderadamente complexo.

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

No modelo de proxy da arquitetura de referência de microsserviços do NGINX, o NGINX Plus atua como um servidor proxy reverso e controlador de entrada para as instâncias de microsserviços de um aplicativo

Se a comunicação entre serviços for necessária – e isso ocorre na maioria dos aplicativos de qualquer nível de complexidade – o registro de serviços fornece o mecanismo dentro do cluster. (Veja esta postagem do blog para uma lista detalhada de 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 enviar uma solicitação.

Geralmente, o modelo Proxy é viável para aplicações simples a moderadamente complexas. Não é a abordagem/modelo mais eficiente para balanceamento de carga, especialmente em escala; use um dos modelos descritos abaixo se você tiver requisitos pesados de balanceamento de carga. (“Escala” pode se referir a um grande número de microsserviços, bem como altos volumes de tráfego.)

Editor – Para uma exploração aprofundada deste modelo, veja MRA, Parte 2 – O Modelo Proxy .

Avançando para o modelo de malha de roteador

O modelo Router Mesh é moderadamente complexo e é uma boa combinação para novos designs de aplicativos robustos e também para converter aplicativos legados monolíticos mais complexos que não precisam dos recursos do modelo Fabric.

O modelo de malha de roteador adota uma abordagem mais robusta para redes 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 do roteador é o balanceamento de carga mais eficiente e robusto entre serviços. Se você usar o NGINX Plus, poderá implementar verificações de integridade ativas para monitorar instâncias de serviço individuais e limitar o tráfego adequadamente quando elas forem desativadas.

No modelo de malha de roteador da arquitetura de referência de microsserviços do NGINX, o NGINX Plus é executado em cada servidor para balancear a carga dos microsserviços em execução ali, e também em servidores frontend para reverter o proxy e balancear a carga do tráfego para os servidores de aplicativos com descoberta de serviço.

O Deis Workflow usa uma abordagem semelhante ao Router Mesh Model 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 de aplicativo são criadas, um processo extrai informações de serviço do registro de serviço etcd e as carrega no NGINX. O NGINX Plus também pode funcionar neste modo, usando vários locais e seus upstreams associados.

Editor – Para uma exploração aprofundada deste modelo, veja MRA, Parte 3 – O Modelo de Malha do Roteador .

E finalmente – O modelo Fabric, com SSL/TLS opcional

Nós aqui da NGINX estamos muito animados com o modelo Fabric. Ele dá vida a algumas das promessas mais interessantes dos microsserviços, incluindo alto desempenho, flexibilidade no balanceamento de carga e SSL/TLS onipresente até o nível de microsserviços individuais. O modelo Fabric é adequado para aplicações seguras e escalável para aplicações muito grandes.

No modelo Fabric, o NGINX Plus é implantado em cada contêiner e se torna o proxy para todo o tráfego HTTP que entra e sai dos contêineres. Os aplicativos se comunicam com um localhost para todas as conexões de serviço e contam com o NGINX Plus para fazer descoberta de serviço, balanceamento de carga e verificação de integridade.

No modelo de estrutura da arquitetura de referência de microsserviços do NGINX, o NGINX Plus é implantado em cada contêiner e se torna o proxy direto e reverso para todo o tráfego HTTP que entra e sai dos contêineres.

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

Devido ao poderoso processamento HTTP no NGINX Plus, podemos usar keepalives para manter conexões com estado aos microsserviços, reduzindo a latência e melhorando o desempenho. Este é um recurso especialmente valioso ao usar SSL/TLS para proteger o tráfego entre os microsserviços.

Por fim, usamos as verificações de integridade ativas do NGINX Plus para gerenciar o tráfego para instâncias saudáveis e, essencialmente, criar o padrão de disjuntor gratuitamente.

Editor – Para uma exploração aprofundada deste modelo, veja MRA, Parte 4 – O Modelo de Tecido .

Um aplicativo de demonstração engenhoso para o MRA

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

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

  • É fácil para usuários e desenvolvedores entenderem o que ele faz.
  • Há diversas dimensões de dados para gerenciar.
  • É fácil incorporar um design bonito no aplicativo.
  • Ele fornece requisitos de computação assimétrica – uma mistura de processamento de alta e baixa intensidade – que permite testes realistas de recursos de failover, dimensionamento e monitoramento em diferentes tipos de funcionalidade.

Conclusão

A Arquitetura de Referência de Microsserviços NGINX é um desenvolvimento interessante para nós e para os clientes e parceiros com quem a compartilhamos até agora. Nos próximos meses, publicaremos uma série de postagens de blog descrevendo-o em detalhes e o disponibilizaremos ainda este ano. Também discutiremos isso em detalhes na nginx.conf 2016 , de 7 a 9 de setembro em Austin, TX. Por favor, nos dê seu feedback, e estamos ansiosos para vê-lo.

Enquanto isso, experimente o MRA com NGINX Plus você mesmo – comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."