# Microsserviço

Em engenharia de software, uma arquitetura de microsserviços é um padrão arquitetural que organiza uma aplicação em um conjunto de serviços independentes e com escopo limitado a uma única função comercial, chamados microserviços. Não há uma definição única para o termo, mas a independência e responsabilidade limitada dos componentes são características comuns dessa arquitetura, em contraste com uma aplicação monolítica. Outra característica comum é a comunicação entre processos através de protocolos leves, em geral HTTP. Porém ela introduz complexidades adicionais, particularmente em gerenciamento de sistemas distribuídos e comunicação entre serviços, tornando a implementação inicial mais desafiadora comparada a arquitetura de monolito.

## Definição

Não há uma definição única, universalmente aceita de microserviços. Porém elas geralmente se caracterizam pelo foco em modularidade, em que cada serviço é projetado em torno de uma capacidade do negócio. Esses serviços são fracamente acoplados, podem ser deploayados independentemente, e frequentemente desenvolvidos e escalados separadamente, permitido maior flexibilidade e agilidade no gerenciamento de sistemas complexos. A arquitetura de microserviços é fortemente associada com princípios como domain-driven design, descentralização de dados e governância, e a flexibilidade de usar diferentes tecnologias para serviços individuais para melhor atender os requisitos.

## Uso

É comum para arquiteturas de microserviços serem adotadas para aplicações cloud-native, e serverless computing, e aplicações usando containers leves. De acordo com Fowler, devido ao grande número (quando comparados a implementações de aplicações monolíticas) de serviços, descentralizado contínuos delivery e DevOps com monitoração de serviços holística são necessárias para desenvolver, manter e operar efetivamente esses tipos de aplicações. Uma consequência de (e a razão para) seguir esse método é que microserviços invisuais podem ser individualmente escalados. Em um método monolítico, uma aplicação suportando três funções teria de ser escalada em seu todo, mesmo que apenas uma dessas funções tenha restrição de recursos. Com microserviços, apenas o microseriviço com suportando a função com restrição de recursos precisaria ser escalada, assim provendo benefícios de recursos e otimização de custos. Em fevereiro de 2020, um Report de Pequisa de Mercado de Microserviços em Nuvem previu que o tamanho do mercado global de arquitetura de microserviços aumentaria em um CAGR de 21.37% de 2019 a 2026 e que chegaria a $3.1 bilhões em 2026.

## Arquitetura de Microserviços baseada em células

Arquitetura baseada em células é um design de computação distribuída em que recursos computacionais são organizados em unidades auto contidas chamadas de células. Cada célula opera independentemente, lidando com um subconjunto de reaquisição enquanto mantendo a escalabilidade, tolerância a falhas, e disponibilidade. Uma célula tipicamente consiste de múltiplos microserviços e funções como uma unidade autônoma. Em algumas implementações, o conjunto inteiro de microserviços são replicados em múltiplas células, permitindo que requisições possam ser roteadas para outra célula operational se uma experimentar uma falha. Esse método tem a intenção de melhorar a resiliência por todo o sistema ao limitar o impacto de falhas localizadas.
Algumas implementações incorporam circuit breakers dentro e entre células. Dentro de uma célula, um circuit breaker pode ser usado para mitigar falhas em cascata entre os microserviços, enquanto circuit breakers entrem células podem isolar células com falhas e redirecionar o tráfego para as que seguem operacionais.
A arquitetura baseada em células tem sido adotada em certos sistemas distribuídos de larga escala onde o isolamento de falhas e a redundância são prioridades do design. Suas implementações variam baseadas nos requisitos do sistema, restrições de infraestrutura, e especificamente objetivos operacionais.

## História

Em 1999, o desenvolvedor de software Peter Rodgers estava trabalhando no projeto de pesquisa Dexter na Hewlett Packard Labs, cujo objetivo era de fazer código ser menos frágil e tornar sistemas de grande escala e sistema de software robustos a mudanças. Em última análise esse caminho de pesquisa levou ao desenvolvimento do resource-oriented computing (ROC), uma abstração computacional generalizada em que REST é um subconjunto especial. Em 2005, durante uma apresentação na conferência Web Service Edge, Roger argumentou pela REST-services" e disse que Componentes de software são Micro-Web-Services... Micro-Services são compostos usando pipelines estilo Unix (the Web meets Unix = true loose-coupling). Serviços podem serviços (+múltiplos run-times de linguagens). Conjuntos complexos de serviços são abstraídos atrás de simples interfaces URI. Qualquer serviço, em qualquer granularidade, pode ser exposto." Ele descreveu como uma plataforma de microserviços bem projetada "aplica os princípios arquiteturais da Web e serviços REST junto com scheduling e pipelines estilo Unix para prover flexibilidade radical e simplificação mais apurada em arquiteturas orientas a serviços.
Também em 2005, Alistair Cockburn escreveu a respeito da arquitetura hexagonal que é um padrão de design de software que é usado junto com microserviços. Esse padrão faz com que o design de microserviços seja possível já que ele isola as camadas de lógica de negócio dos serviços auxiliares necessários para lançar e rodar microserviços completamente independentes dos outros.

## Tecnologias

Microserviços podem ser implementados em diferentes linguagens de programação e podem ser usados em diferentes infraestruturas. Por tanto, a escolha tecnológica mais importante são a forma como os microserviços se comunicam uns com os outros (sincronamente, assincronamente, integração com UI) e os protocolos usados para a comunicação (RESTFul HTTP, menssageria, GraphQL ...). Num sistema tradicional escolhas como a linguagem de programação impactam o sistema interio. Então, a abordagem para escolher tecnologias é bem diferente. A Eclipse Foundation publicou uma especificação para o desnvolvimento de microserviços, Eclipse MicroProfile.

### Service mesh

Em um service mesh, cada instância do serviço é pareada com uma instância de um servidor de proxy reverso, chamando service proxy, sidecar proxy ou sidecar. A instância do serviço e o proxy sidecar compartilham um container, e o contaier é gerencia por uma ferramenta de orquestração de containers como Kubernetes, Nomad, Docker Swarm ou DC/OS. O proxy de serviço é responsável pela comunicação com outras instâncias de serviço e podem suportar capacidades como descoberta de (instância de) serviço, balanceamento de carca, autenticação e autorização, comunicação segura e outras.