Arquitetura de serviço é uma abordagem de design de software que resolve um problema com uma série de serviços autônomos.

Analogia

Uma analogia razoável para arquitetura de serviço é uma organização como um banco. O banco divide o trabalho em uma variedade de serviços, como atendimento ao cliente, serviços de TI e serviços de gestão de recursos humanos. Cada serviço é independente e pode ser implantado em diferentes escritórios. Aos clientes de cada serviço é oferecido um contrato que indica o que se pode esperar do serviço. Por exemplo, o gerenciamento de recursos humanos pode ajudar uma equipe a recrutar novos funcionários com um formulário que a equipe preenche para iniciar o processo. A estrutura de serviço da empresa divide o problema complexo de operar um banco em pequenos blocos de funcionalidade de gerenciamento.

Serviços

Serviços são unidades de software que executar uma função. Eles são usados para quebrar problemas complexos em uma série de problemas mais simples. Os serviços também são projetados para serem implantados separadamente. Esta é uma grande vantagem, pois permite que você construa sistemas altamente escaláveis e resilientes.

Resiliência

Resiliência é um termo para software confiável em condições do mundo real que inclui vários estresses e falhas. A arquitetura de serviço é uma técnica útil para construir sistemas que continuam a funcionar quando as coisas falham. Isso é feito arquitetando serviços para serem autônomos, de modo que não dependam uns dos outros. Os serviços podem ser implantados na infraestrutura em nuvem e aumentados e reduzidos conforme necessário. Quando uma instância falha, os serviços são inteligentes o suficiente para detectar isso e automaticamente encontre uma instância que esteja funcionando.

Serviços e componentes

Serviços e componentes são duas maneiras diferentes de dividir o trabalho em blocos gerenciáveis e reutilizáveis. A diferença é que os serviços podem ser implantados por conta própria. Os componentes são implantados com outra coisa e, portanto, não são autônomos. Os serviços podem ser construídos a partir de componentes. Da mesma forma, os componentes podem usar serviços.

Arquitetura Orientada a Serviços (SOA)

Arquitetura orientada a serviços foi um termo inicial para arquitetura de serviço que foi adotado e comercializado por muitos grandes fornecedores de TI que o usaram para vender plataformas SOA e middleware. Esta foi uma grande moda da tecnologia da informação por volta de 2005, que viu muitas implementações de cima para baixo que envolviam a compra de um monte de software e, em seguida, o redesenho dos sistemas existentes para se encaixar em um paradigma SOA. Grande parte dessa atividade perdeu completamente o ponto de SOA e as falhas do projeto eram comuns. A confusão choveu enquanto os especialistas de TI promoviam ou criticavam SOA, geralmente fazendo as coisas parecerem o mais complexas possível.

Microsserviços

Todas as grandes ideias e absurdos que cercou a SOA no auge de sua popularidade não impediu que arquitetos qualificados usassem suas ideias centrais de maneiras eficazes e leves, produzindo sistemas e aplicativos confiáveis, escaláveis, gerenciáveis e econômicos. Isso evoluiu para uma nova cultura de design de software conhecida como microsserviços, que é organizada em torno de um conjunto de princípios para design de serviço.

Exemplo

Uma empresa de telecomunicações projeta um sistema de faturamento como uma série de serviços implantáveis separadamente. Cada serviço é visto como um produto separado que pode ser desenvolvido, mantido e gerenciado por pessoas diferentes. Os serviços são implantados na nuvem e fracamente acoplados. Quando uma instância de serviço falha, os outros serviços mudam automaticamente para uma instância que ainda está funcionando. Embora o problema de faturamento de telecomunicações seja extremamente complexo, nenhum serviço único na arquitetura é tão complexo que seja relativamente barato de desenvolver e gerenciar. Os serviços são essencialmente auto-organizados. Cada um publica uma API para os outros serviços. Cada um sabe o que precisa dos outros serviços e é inteligente o suficiente para rotear instâncias com falha para encontrar serviços que estão respondendo. Em outras palavras, a arquitetura não tem controlador central ou middleware.

Visão geral: Arquitetura de serviço
Tipo
Definição	Uma abordagem de design de software que resolve um problema com uma série de serviços autônomos.
Conceitos relacionados