Nota do autor – Esta postagem do blog é a primeira de uma série:
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:
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:
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.
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:
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 é 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 .
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 .
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.
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 .
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.
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 .
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:
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."