Microsserviços – Parte II

Este texto é de James Lewis e Martin Fowler, disponível em: http://martinfowler.com/articles/microservices.html.

A primeira parte está disponível aqui: Microsserviços – Parte I


Características de um Microsserviço

Não podemos dizer que há uma definição formal do estilo de arquitetura de microsserviços, mas podemos tentar descrever as características comuns em arquiteturas que se encaixam nesse rótulo. Como muitas definições que delineiam as características comuns, nem todas as arquiteturas de microsserviços possuem todas as características, mas esperamos que a maioria das arquiteturas de microsserviços apresentem a maioria delas. Mesmo que nós autores tenhamos sido membros dessa vaga comunidade, nossa intenção é tentar descrever o que vemos em nosso próprio trabalho e em esforços similares por times que conhecemos. Particularmente, não estamos formulando uma definição a ser obedecida.

Componentização Via Serviços

Enquanto estivermos envolvidos na indústria de software, há um grande desejo de construir sistemas plugando componentes, quase como vemos as coisas serem feitas no mundo físico. Durante as últimas duas décadas, vimos um progresso considerável com grandes compêndios de bibliotecas que são parte da maioria das plataformas de linguagens.

Ao falar de componentes, acabamos na difícil definição de o que faz um componente. Nossa definição é que um componente é uma unidade de software que pode ser trocada ou melhorada independentemente.

As arquiteturas de microsserviços vão usar bibliotecas, mas a forma primária de componentização do próprio software é quebrando-o em pedaços. Definimos bibliotecas como componentes que estão ligados em um programa usando chamadas de função em memória, enquanto serviços são componentes fora do processo, que se comunicam com um mecanismo como requisições de webservices, ou chamada de procedimento remoto. (Isso é um conceito diferente daquele de Objeto de Serviço em vários programas OO [3].)

Uma razão principal para usar serviços como componentes (em vez de bibliotecas) é que os serviços são implantados independentemente. Se você tem uma aplicação [4] que consiste de várias bibliotecas em um único processo, uma mudança em um único componente resulta em ter que reimplantar a aplicação inteira. Mas, se a aplicação está decomposta em múltiplos serviços, você pode esperar várias mudanças em um único serviço que só precisarão da reimplantação desse serviço. Não é absoluto, algumas mudanças vão alterar as interfaces entre serviços, resultando em coordenação, mas o objetivo de uma boa arquitetura de microssserviço é minimizar as alterações de interface por meio de fronteiras de serviço coesas e mecanismos de evolução nesses contratos de serviço.

Outra consequência de usar serviços como componentes é uma interface de componente mais explícita. A maioria das linguagens não têm um bom mecanismo para definir uma Interface Publicada explícita. Comumente, só a documentação e a disciplina previnem alguém de quebrar o encapsulamento de um componente, levando a grande acoplamento entre componentes. É mais fácil prevenir isso com serviços pois usam mecanismos explícitos de chamada remota.

Usar serviços têm seu lado negativo. As chamadas remotas são mais caras que as chamadas dentro do mesmo processo, então as APIs remotas precisam ser mais menos granulares, o que é mais estranho de usar. Se você precisa mudar a alocação de responsabilidades entre os componentes, tais movimentos de comportamento são mais difíceis de fazer quando você está cruzando as fronteiras dos processos.

À primeira vista, podemos observar que cada serviço é, tempo de execução, um só processo, mas é só à primeira vista. Um serviço pode ter vários processos que vão ser desenvolvidos e implantados juntos, como um processo e um banco de dados que só é usado por esse serviço.


[3] Muitos designers orientados a objetos, incluindo nós mesmos, usamos o tempo “objeto de serviço” (“Service Object”) no senso de um objeto que executa um processo significativo e que não está amarrado em uma entidade. Esse é um conceito diferente de “serviço” do que estamos usando neste artigo. Infelizmente, o termo “serviço” tem os dois significados e temos que conviver com a polissemia.

[4] Consideramos que uma aplicação é uma construção social que une uma base de código, um grupo de funcionalidades, e um corpo de financiamento.

Anúncios
Marcado com: , , ,
Publicado em Microsserviços

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: