Microsserviços - Microservices

Uma arquitetura de microsserviço - uma variante do estilo estrutural da arquitetura orientada a serviços (SOA) - organiza um aplicativo como uma coleção de serviços fracamente acoplados . Em uma arquitetura de microsserviços, os serviços são refinados e os protocolos são leves . O objetivo é que as equipes possam levar sua vida de serviço independente das outras. O acoplamento fraco reduz todos os tipos de dependências e as complexidades ao seu redor, já que os desenvolvedores de serviço não precisam se preocupar com os usuários do serviço, eles não forçam suas mudanças para os usuários do serviço. Portanto, permite que as organizações que desenvolvem software cresçam rapidamente e se tornem grandes, bem como usem serviços prontos para uso com mais facilidade. Os requisitos de comunicação são menores. Mas tem um custo para manter o desacoplamento. As interfaces precisam ser projetadas com cuidado e tratadas como uma API pública. Técnicas como ter várias interfaces no mesmo serviço, ou várias versões do mesmo serviço, para não quebrar o código de usuários existente.

Introdução

Não existe uma definição única para microsserviços. Uma visão consensual evoluiu ao longo do tempo na indústria. Algumas das características definidoras frequentemente citadas incluem:

  • Os serviços em uma arquitetura de microsserviço geralmente são processos que se comunicam por meio de uma rede para cumprir uma meta usando protocolos agnósticos de tecnologia , como HTTP.
  • Os serviços são organizados em torno dos recursos de negócios.
  • Os serviços podem ser implementados usando diferentes linguagens de programação , bancos de dados , ambientes de hardware e software, dependendo do que for mais adequado.
  • Os serviços são pequenos em tamanho, habilitados para mensagens, limitados por contextos, desenvolvidos de forma autônoma, implementáveis ​​de forma independente, descentralizados e construídos e liberados com processos automatizados .

Um microsserviço não é uma camada dentro de um aplicativo monolítico (por exemplo, o controlador da web ou o back-end para front-end). Em vez disso, é uma funcionalidade de negócios independente com interfaces claras e pode, por meio de seus próprios componentes internos, implementar uma arquitetura em camadas. De uma perspectiva estratégica, a arquitetura de microsserviço segue essencialmente a filosofia Unix de "Faça uma coisa e faça-a bem". Martin Fowler descreve uma arquitetura baseada em microsserviços como tendo as seguintes propriedades:

  • Presta-se a um processo de desenvolvimento de software de entrega contínua . Uma mudança em uma pequena parte do aplicativo requer apenas a reconstrução e a reimplantação de apenas um ou um pequeno número de serviços.
  • Adere a princípios como interfaces refinadas (para serviços implantáveis ​​de forma independente), desenvolvimento orientado para negócios (por exemplo , design orientado para domínio ).

É comum que arquiteturas de microsserviços sejam adotadas para aplicativos nativos da nuvem , computação sem servidor e aplicativos que usam implantação de contêiner leve . De acordo com Fowler, devido ao grande número (quando comparado às implementações de aplicativos monolíticos) de serviços, a entrega contínua descentralizada e DevOps com monitoramento holístico de serviço são necessários para desenvolver, manter e operar esses aplicativos com eficácia. Uma consequência (e razão para) seguir essa abordagem é que os microsserviços individuais podem ser dimensionados individualmente. Na abordagem monolítica, um aplicativo que suporta três funções teria que ser dimensionado em sua totalidade, mesmo se apenas uma dessas funções tivesse uma restrição de recursos. Com microsserviços, apenas o microsserviço que oferece suporte à função com restrições de recursos precisa ser dimensionado, fornecendo, assim, benefícios de otimização de recursos e custos.

História

Existem inúmeras reivindicações quanto à origem do termo microsserviços. Enquanto era vice-presidente da ThoughtWorks em 2004, Fred George começou a trabalhar em arquiteturas de protótipo baseadas no que ele chamou de "Princípios Baysean" em homenagem a Jeff Bay.

Já em 2005, Peter Rodgers introduziu o termo "Micro -Web-Services " durante uma apresentação na conferência Web Services Edge. Contra o pensamento convencional e no auge da curva de hype da arquitetura SOAP SOA, ele defendeu "REST-services" e no slide # 4 da apresentação da conferência, ele discute " Os componentes de software são Micro-Web-Services". Ele prossegue, dizendo que "Micro-serviços são compostos usando pipelines do tipo Unix (a Web encontra Unix = verdadeiro acoplamento frouxo ). Os serviços podem chamar serviços (+ tempos de execução de várias linguagens). Conjuntos de serviços complexos são abstraídos por meio de URI simples interfaces. Qualquer serviço, em qualquer granularidade, pode ser exposto. " Ele descreveu como uma plataforma de microsserviços bem projetada "aplica os princípios arquitetônicos subjacentes dos serviços Web e REST junto com agendamento e pipelines semelhantes ao Unix para fornecer flexibilidade radical e simplicidade aprimorada em arquiteturas orientadas a serviços.

O trabalho de Rodgers se originou em 1999 com o projeto de pesquisa Dexter na Hewlett Packard Labs , cujo objetivo era tornar o código menos frágil e tornar sistemas de software complexos em grande escala robustos a mudanças. Em última análise, esse caminho de pesquisa levou ao desenvolvimento da computação orientada a recursos (ROC), uma abstração de computação generalizada na qual REST é um subconjunto especial.

Em 2007, Juval Löwy, em seus escritos e palestras, pediu a construção de sistemas em que cada aula fosse um serviço. Löwy percebeu que isso exigia o uso de uma tecnologia que pudesse suportar esse uso granular de serviços e estendeu o Windows Communication Foundation (WCF) para fazer exatamente isso, pegando todas as aulas e tratando-as como um serviço, mantendo o modelo de programação convencional de classes.

Um workshop de arquitetos de software realizado perto de Veneza em maio de 2011 usou o termo "microsserviço" para descrever o que os participantes viram como um estilo arquitetônico comum que muitos deles haviam explorado recentemente. Em maio de 2012, o mesmo grupo decidiu por "microsserviços" como o nome mais adequado. James Lewis apresentou algumas dessas ideias como um estudo de caso em março de 2012 na 33rd Degree in Kraków in Micro services - Java, the Unix Way, assim como Fred George quase na mesma época. Adrian Cockcroft , ex-diretor de Sistemas em Nuvem da Netflix, descreveu essa abordagem como "SOA de granulação fina", foi o pioneiro no estilo em escala da web, assim como muitos dos outros mencionados neste artigo - Joe Walnes, Dan North, Evan Bottcher e Graham Tackley.

Microsserviços é uma especialização de uma abordagem de implementação para arquiteturas orientadas a serviços (SOA) usada para construir sistemas de software flexíveis e implantáveis ​​de forma independente . A abordagem de microsserviços é a primeira realização de SOA que se seguiu à introdução do DevOps e está se tornando mais popular para construir sistemas implantados continuamente .

Em fevereiro de 2020, o Cloud Microservices Market Research Report previu que o tamanho do mercado global de arquitetura de microsserviços aumentará a um CAGR de 21,37% de 2019 a 2026 e atingirá US $ 3,1 bilhões em 2026.

Granularidade de serviço

Uma etapa importante na definição de uma arquitetura de microsserviço é descobrir o tamanho de um microsserviço individual. Não há consenso ou teste decisivo para isso, pois a resposta certa depende do contexto empresarial e organizacional. Por exemplo, a Amazon usa uma arquitetura orientada a serviços em que um serviço geralmente mapeia 1: 1 com uma equipe de 3 a 10 engenheiros. Geralmente, a terminologia é assim: os serviços que são dedicados a uma única tarefa, como chamar um sistema de back-end específico ou fazer um tipo específico de cálculo, são chamados de serviços atômicos . Da mesma forma, os serviços que chamam esses serviços atômicos para consolidar uma saída são chamados de serviços compostos .

É considerado uma prática ruim tornar o serviço muito pequeno, pois a sobrecarga do tempo de execução e a complexidade operacional podem sobrecarregar os benefícios da abordagem. Quando as coisas ficam muito refinadas, abordagens alternativas devem ser consideradas - como empacotar a função como uma biblioteca, mover a função para outros microsserviços.

Se o design orientado por domínio está sendo empregado na modelagem do domínio para o qual o sistema está sendo construído, um microsserviço pode ser tão pequeno quanto um agregado ou tão grande quanto um Contexto limitado.

Benefícios

Os benefícios de decompor um aplicativo em diferentes serviços menores são numerosos:

  • Modularidade : Isso torna o aplicativo mais fácil de entender, desenvolver, testar e se tornar mais resistente à erosão da arquitetura. Este benefício é freqüentemente questionado em comparação com a complexidade das arquiteturas monolíticas.
  • Escalabilidade : como os microsserviços são implementados e implantados independentemente uns dos outros, ou seja, são executados em processos independentes, eles podem ser monitorados e escalados independentemente.
  • Integração de sistemas heterogêneos e legados : os microsserviços são considerados um meio viável para modernizar o aplicativo de software monolítico existente. Existem relatos de experiência de várias empresas que substituíram com êxito (partes de) seu software existente por microsserviços, ou estão em processo de fazê-lo. O processo de modernização de software de aplicativos legados é feito usando uma abordagem incremental.
  • Desenvolvimento distribuído: ele paraleliza o desenvolvimento , permitindo que pequenas equipes autônomas desenvolvam, implantem e escalem seus respectivos serviços de forma independente. Também permite que a arquitetura de um serviço individual surja por meio da refatoração contínua . As arquiteturas baseadas em microsserviços facilitam a integração , entrega e implantação contínuas .

Críticas e preocupações

A abordagem de microsserviços está sujeita a críticas por uma série de questões:

  • Os serviços constituem barreiras de informação.
  • As chamadas entre serviços em uma rede têm um custo mais alto em termos de latência da rede e tempo de processamento de mensagens do que as chamadas em processo em um processo de serviço monolítico .
  • O teste e a implantação são mais complicados.
  • Transferir responsabilidades entre serviços é mais difícil. Pode envolver a comunicação entre equipes diferentes, reescrever a funcionalidade em outro idioma ou adaptá-la a uma infraestrutura diferente. No entanto, os microsserviços podem ser implantados independentemente do resto do aplicativo, enquanto as equipes que trabalham em monólitos precisam sincronizar para implantar juntas.
  • Ver o tamanho dos serviços como o mecanismo de estruturação primário pode levar a muitos serviços quando a alternativa de modularização interna pode levar a um design mais simples. Isso requer a compreensão da arquitetura geral dos aplicativos e das interdependências entre os componentes.
  • Os commits em duas fases são considerados um antipadrão em arquiteturas baseadas em microsserviços, pois isso resulta em um acoplamento mais rígido de todos os participantes da transação. No entanto, a falta dessa tecnologia causa danças estranhas que devem ser implementadas por todos os participantes da transação para manter a consistência dos dados.
  • O desenvolvimento e o suporte de muitos serviços são mais desafiadores se eles forem construídos com ferramentas e tecnologias diferentes - este é um problema especialmente se os engenheiros mudam de projeto com frequência.
  • O protocolo normalmente usado com microsserviços (HTTP) foi projetado para serviços voltados ao público e, como tal, é inadequado para o funcionamento de microsserviços internos que geralmente devem ser impecavelmente confiáveis.
  • Embora não seja específica para microsserviços, a metodologia de decomposição geralmente usa decomposição funcional, que não lida com mudanças nos requisitos, embora ainda acrescente a complexidade dos serviços.
  • O próprio conceito de microsserviço é enganoso, uma vez que existem apenas serviços. Não existe uma definição clara de quando um serviço inicia ou deixa de ser um microsserviço.

Carga cognitiva

A arquitetura apresenta complexidade adicional e novos problemas para lidar, como latência de rede , design de formato de mensagem , backup / disponibilidade / consistência (BAC), balanceamento de carga e tolerância a falhas . Todos esses problemas devem ser tratados em grande escala. A complexidade de um aplicativo monolítico não desaparece se ele for reimplementado como um conjunto de microsserviços. Parte da complexidade é traduzida em complexidade operacional. Outros locais onde a complexidade se manifesta são no aumento do tráfego de rede e no desempenho mais lento resultante. Além disso, um aplicativo composto por qualquer número de microsserviços possui um maior número de pontos de interface para acessar seu respectivo ecossistema , o que aumenta a complexidade arquitetônica. Vários princípios de organização (como HATEOAS , interface e documentação de modelo de dados capturada via Swagger , etc.) foram aplicados para reduzir o impacto de tal complexidade adicional.

Tecnologias

Os microsserviços de computador podem ser implementados em diferentes linguagens de programação e podem usar diferentes infraestruturas. Portanto, as escolhas de tecnologia mais importantes são a maneira como os microsserviços se comunicam entre si (síncrono, assíncrono, integração de IU) e os protocolos usados ​​para a comunicação ( RESTful HTTP, mensagens, GraphQL ...). Em um sistema tradicional, a maioria das opções de tecnologia, como a linguagem de programação, afetam todo o sistema. Portanto, a abordagem para a escolha de tecnologias é bem diferente.

A Eclipse Foundation publicou uma especificação para desenvolver microsserviços, Eclipse MicroProfile.

Malha de serviço

Veja também: Malha de serviço

Em uma malha de serviço, cada instância de serviço é emparelhada com uma instância de um servidor proxy reverso, chamado de proxy de serviço, proxy secundário ou sidecar. A instância de serviço e o proxy secundário compartilham um contêiner, e os contêineres são gerenciados por uma ferramenta de orquestração de contêineres, como Kubernetes , Nomad , Docker Swarm ou DC / OS . Os proxies de serviço são responsáveis ​​pela comunicação com outras instâncias de serviço e podem oferecer suporte a recursos como descoberta de serviço (instância), balanceamento de carga, autenticação e autorização, comunicações seguras e outros.

Em uma malha de serviço, as instâncias de serviço e seus proxies secundários compõem o plano de dados, que inclui não apenas o gerenciamento de dados, mas também o processamento e a resposta da solicitação. A malha de serviço também inclui um plano de controle para gerenciar a interação entre os serviços, mediada por seus proxies secundários. Existem várias opções para arquitetura de malha de serviço: Open Service Mesh , Istio (um projeto conjunto entre Google, IBM e Lyft), Linkerd (um projeto CNCF liderado por Buoyant ), Consul (um produto HashiCorp ) e muitos outros na malha de serviço paisagem . O plano de gerenciamento de malha de serviço, Meshery , fornece ciclo de vida, configuração e gerenciamento de desempenho em implantações de malha de serviço.

Uma comparação de plataformas

Implementar uma arquitetura de microsserviço é muito difícil. Existem muitas preocupações (consulte a tabela abaixo) que qualquer arquitetura de microsserviço precisa abordar. A Netflix desenvolveu uma estrutura de microsserviço para oferecer suporte a seus aplicativos internos e, em seguida, abriu o código-fonte de muitas partes dessa estrutura. Muitas dessas ferramentas foram popularizadas por meio do Spring Framework - elas foram reimplementadas como ferramentas baseadas em Spring sob a égide do projeto Spring Cloud. A tabela abaixo mostra uma comparação de um recurso de implementação do ecossistema Kubernetes com um equivalente do mundo Spring Cloud. Um aspecto notável do ecossistema Spring Cloud é que todas são tecnologias baseadas em Java, enquanto o Kubernetes é uma plataforma de tempo de execução poliglota.

Preocupação com microsserviços Spring Cloud e Netflix OSS Kubernetes
Gerenciamento de configuração: a configuração de um aplicativo de microsserviço precisa ser externalizada a partir do código e ser recuperada por meio de uma simples chamada de serviço. Spring Config Server e Netflix Archaius oferecem suporte a um local baseado em repositório Git para configuração. Archaius oferece suporte à digitação de dados de configuração. O Kubernetes ConfigMaps expõe a configuração armazenada no etcd por meio de serviços. O Kubernetes Secrets oferece suporte à implantação segura baseada em serviço e ao uso de informações de configuração confidenciais (como senhas, certificados etc.).
Descoberta de serviço : mantenha uma lista de instâncias de serviço que estão disponíveis para trabalhar em um domínio de microsserviço. O Spring Cloud Eureka permite que os clientes se registrem nele, mantém uma pulsação com clientes registrados e mapeia nomes de serviço para nomes de host para clientes que procuram serviços por nome de serviço. Os serviços do Kubernetes fornecem registro no momento da implantação de instâncias de serviços que estão disponíveis internamente no cluster. A entrada é um mecanismo pelo qual um serviço pode ser exposto a clientes fora do cluster.
Balanceamento de carga: A chave para dimensionar um sistema distribuído é ser capaz de executar mais de uma instância de um componente. A carga deve ser então distribuída entre essas instâncias por meio de um balanceador de carga. Spring Cloud Ribbon fornece a capacidade de clientes de serviço balancearem a carga entre as instâncias do serviço. O serviço Kubernetes oferece a capacidade de balanceamento de carga do serviço nas instâncias de serviço. Isso não é equivalente ao que a Faixa de Opções oferece.
Gateway de API: a granularidade das APIs fornecidas por microsserviços costuma ser diferente do que um cliente de serviço precisa. Os API Gateways implementam fachadas e fornecem serviços adicionais como proxy e tradução de protocolo e outras funções de gerenciamento. Spring Cloud Zuul fornece fachadas de API baseadas em configuração Os recursos de serviço e entrada do Kubernetes, Istio e Ambassador são soluções que fornecem funções de gateway de API tanto no sentido norte-sul (tráfego de entrada e saída do data center) quanto leste-oeste (tráfego entre data centers ou nuvens ou regiões). O Zuul também pode ser implementado junto com o Kubernetes, fornecendo configuração em nível de serviço individual.
Questões de segurança: muitas questões de segurança são direcionadas à implementação do gateway de API. Com aplicativos de microsserviços distribuídos, faz sentido não reinventar a roda da segurança e permitir a definição e implementação de políticas em componentes que são compartilhados por todos os serviços. Spring Cloud Security aborda muitas questões de segurança por meio do Spring Cloud Zuul O ecossistema Kubernetes fornece malhas de serviço como o Istio, que são capazes de fornecer segurança por meio de seus mecanismos de gateway de API.
Registro centralizado: é importante ter uma infraestrutura centralizada de coleta e análise de registros para gerenciar uma infinidade de serviços - muitos dos quais estão operando de maneira distribuída. ELK Stack ( ElasticSearch , LogStash, Kibana ) EFK Stack ( ElasticSearch , Fluentd , Kibana )
Métricas centralizadas: Uma área centralizada onde a saúde e o desempenho dos serviços individuais e do sistema geral podem ser monitorados é essencial para as operações adequadas. Espectador e Atlas da Primavera Heapster, Prometheus e Grafana
Rastreio distribuído: A criação de log por processo e o monitoramento de métrica têm seu lugar, mas nenhum deles pode reconstruir os caminhos complexos que as transações tomam à medida que se propagam em um sistema distribuído. O rastreamento distribuído é uma ferramenta essencial para uma plataforma de microsserviços. Spring Cloud Sleuth Hawkular, Jaeger
Resiliência e tolerância a falhas: os sistemas distribuídos devem ser capazes de rotear automaticamente em torno de falhas e de rotear solicitações para a instância de serviço que fornecerá uma resposta ideal. Spring Hystrix, Turbine e Ribbon Verificação de integridade , malhas de serviço (exemplo: Istio)
Escalonamento automático e autocorreção: os sistemas distribuídos respondem a cargas mais altas escalando horizontalmente: a plataforma deve detectar e responder automaticamente a tais condições. Além disso, o sistema precisa detectar falhas e tentar reinicializações automáticas sem intervenção do operador. - Verificação de integridade, autocura e escalonamento automático
Empacotamento, implantação e programação: sistemas em grande escala exigem gerenciamento robusto de pacotes e sistemas de implantação para gerenciar implantações contínuas ou azul-esverdeadas e reversões, se necessário. Um planejador ajuda a determinar em qual nó de execução específico um novo conjunto de serviços pode ser implantado com base nas condições atuais. Spring Boot, Apache Maven. O sistema Spring Cloud não possui um programador verdadeiro. Docker, Rkt, Kubernetes Scheduler & Deployment, Helm
Gerenciamento de trabalho: cálculos programados desconectados de qualquer solicitação individual do usuário. Spring Batch Trabalhos do Kubernetes e trabalhos programados
Aplicativo singleton: limite a execução de um serviço específico como a única instância desse serviço em todo o sistema. Spring Cloud Cluster Pods do Kubernetes

Veja também

Referências

Leitura adicional