Saltar para o conteúdo

Microsserviço

Origem: Wikipédia, a enciclopédia livre.

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.[1] 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.[2][3] 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.[4]

Definição

[editar | editar código-fonte]

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. [5][6][7]

Uso

[editar | editar código-fonte]

É 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.[8] 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.[9] 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.[10] 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.[11]

Arquitetura de Microserviços baseada em células

[editar | editar código-fonte]

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. [5][12][13] 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. [5][12][13]

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. [5][12][13]

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. [5][12][13]

História

[editar | editar código-fonte]

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.[14] 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.[15]

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.

Desafios

[editar | editar código-fonte]

Microserviços são susceptíveis a falácia da computação distribuída, uma série de conceitos errados que podem levar a problemas significantes em desenvolvimento de software e deployment. [16]

Desafios em Compartilhamento de Código

[editar | editar código-fonte]

Idealmente, microserviços seguem uma arquitetura de "compartilhe nada". Porém, na prática, arquiteturas de microserviços frequentemente encontram situações em que código precisa ser compartilhado entre serviços. Uma forma comum de solucionar esse desafio inclui utilizar bibliotecas compartilhadas separadas para componentes reutilizáveis (p/ ex: um biblioteca de segurança), replicando módulos estáveis com o mínimo de mudanças entre os serviços, ou, em certos casos, consolidando múltiplos microserviços em um único serviço para reduzir a complexidade. Cada abordagem tem suas vantagens e trade-offs, dependendo do contexto específico e requerimentos.[17]

Melhores Práticas

[editar | editar código-fonte]

De acordo com O'Reilly, cada microserviço deveria ter suas próprias características de arquitetura (em outras palavras, requisitos não funcionais), e arquitetos não deveriam definir características uniformes para o sistema distribuído inteiro.[16]

Tecnologias

[editar | editar código-fonte]

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.[18] A Eclipse Foundation publicou uma especificação para o desnvolvimento de microserviços, Eclipse MicroProfile.[19][20]

Service mesh

[editar | editar código-fonte]
Ver também: 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.

Ver também

[editar | editar código-fonte]

Referências

  1. ↑ «Estilo de arquitetura de microsserviço». Microsoft. Consultado em 25 de novembro de 2022 
  2. ↑ Fowler, Martin (25 de março de 2014). «Microservices». martinFowler.com. Consultado em 25 de novembro de 2022 
  3. ↑ «Microservices». AWS. Consultado em 25 de novembro de 2022 
  4. ↑ Fowler, Martin (2002). Patterns of Enterprise Application Architecture. [S.l.]: Addison-Wesley Professional. ISBN 978-0321127426 
  5. ↑ a b c d e Newman, Sam (20 de fevereiro de 2015). Building Microservices. [S.l.]: O'Reilly Media. ISBN 978-1491950357 
  6. ↑ Wolff, Eberhard (12 de outubro de 2016). Microservices: Flexible Software Architectures. [S.l.]: Addison-Wesley. ISBN 978-0134602417 
  7. ↑ Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O'Reilly 2016
  8. ↑ Martin Fowler (28 de agosto de 2014). «Microservice Prerequisites». Cópia arquivada em 3 de outubro de 2023 
  9. ↑ Richardson, Chris (novembro de 2018). Microservice Patterns. [S.l.]: Manning Publications. 1.4.1 Scale cube and microservices. ISBN 9781617294549 
  10. ↑ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (16 de outubro de 2019). «Developing Self-Adaptive Microservice Systems: Challenges and Directions». IEEE Software. 38 (2): 70–79. arXiv:1910.07660Acessível livremente. doi:10.1109/MS.2019.2955937 
  11. ↑ Research, Verified Market. «Cloud Microservices Market 2020 Trends, Market Share, Industry Size, Opportunities, Analysis and Forecast by 2026 – Instant Tech Market News» (em inglês). Consultado em 18 de fevereiro de 2020 
  12. ↑ a b c d Richardson, Chris (2019). Microservices patterns: with examples in Java. Shelter Island, NY: Manning Publications. ISBN 978-1-61729-454-9 
  13. ↑ a b c d Christudas, Binildas (2019). Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud. Berkeley, CA: Apress L. P. ISBN 978-1-4842-4501-9 
  14. ↑ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). «Architecture and Design of an XML Application Platform». HP Technical Reports. 62 páginas. Consultado em 20 de agosto de 2015 
  15. ↑ Rodgers, Peter (15 de fevereiro de 2005). «Service-Oriented Development on NetKernel- Patterns, Processes & Products to Reduce System Complexity». CloudComputingExpo. SYS-CON Media. Consultado em 19 de agosto de 2015. Cópia arquivada em 20 de maio de 2018 
  16. ↑ a b Erro de citação: Etiqueta <ref> inválida; não foi fornecido texto para as refs de nome :0
  17. ↑ Erro de citação: Etiqueta <ref> inválida; não foi fornecido texto para as refs de nome :1
  18. ↑ Wolff, Eberhard (15 de abril de 2018). Microservices - A Practical Guide. [S.l.]: CreateSpace Independent Publishing Platform. ISBN 978-1717075901 
  19. ↑ Swart, Stephanie (14 de dezembro de 2016). «Eclipse MicroProfile». projects.eclipse.org 
  20. ↑ «MicroProfile». MicroProfile (em inglês). Consultado em 11 de abril de 2021 
Obtida de "https://pt.wikipedia.org/w/index.php?title=Microsserviço&oldid=69771145"