{"id":1755,"date":"2014-03-30T21:22:51","date_gmt":"2014-03-31T00:22:51","guid":{"rendered":"https:\/\/devkico.itexto.com.br\/?p=1755"},"modified":"2014-04-06T22:19:55","modified_gmt":"2014-04-07T01:19:55","slug":"e-arquitetura-baseada-em-micro-servicos","status":"publish","type":"post","link":"https:\/\/devkico.itexto.com.br\/?p=1755","title":{"rendered":"O que \u00e9 arquitetura baseada em micro servi\u00e7os?"},"content":{"rendered":"
\"Aventuras
Aventuras de Gulliver – bom livro!<\/figcaption><\/figure>\n

O termo\u00a0micro servi\u00e7o<\/em>\u00a0tem me ocupado nos \u00faltimos meses. Vejo a Pivotal dando \u00eanfase a este estilo arquitetural no lan\u00e7amento do Spring 4<\/a>,\u00a0 uma apresenta\u00e7\u00e3o interessante de James Lewis a respeito<\/a>\u00a0e que mais tarde, junto com\u00a0\u00a0Martin Fowler ir\u00e1 escrever um maravilhoso <\/a>artigo\u00a0a respeito e at\u00e9 mesmo textos tolos como este<\/a>. Ap\u00f3s ter lido tantas fontes h\u00e1 momentos em que me sinto como Santo Agostinho ao ser questionado sobre o tempo:<\/p>\n

“O que \u00e9, por conseguinte, o tempo? Se ningu\u00e9m me perguntar, eu sei; se o quiser explicar a quem me fizer a pergunta, j\u00e1 n\u00e3o sei.” (Livro XI das Confiss\u00f5es de Santo Agostinho)<\/p><\/blockquote>\n

\u00c9 interessante como na maior parte das fontes que citei o texto se inicia com algo do tipo “ainda n\u00e3o h\u00e1 uma decis\u00e3o precisa do termo” (Fowler<\/a>). Como ver\u00e3o neste post minha d\u00favida prim\u00e1ria ainda se mant\u00e9m: \u00e9 de fato algo novo ou apenas um daqueles momentos nos quais a ind\u00fastria renomeia algo que j\u00e1 conhec\u00edamos e us\u00e1vamos h\u00e1 anos apenas para nos vender alguma coisa?<\/p>\n

Meu entendimento sobre a coisa<\/h2>\n

Resumindo: mais uma solu\u00e7\u00e3o para o problema do alto acoplamento em aplica\u00e7\u00f5es corporativas. A diferen\u00e7a \u00e9 que desta vez estamos atacando aplica\u00e7\u00f5es monol\u00edticas<\/strong>. Bom: ent\u00e3o primeiro \u00e9 interessante pensarmos no que v\u00eam a ser uma “aplica\u00e7\u00e3o monol\u00edtica”.<\/p>\n

Uma aplica\u00e7\u00e3o monol\u00edtica \u00e9 aquela na qual todos os componentes de neg\u00f3cio encontram-se dentro de uma mesma unidade de implanta\u00e7\u00e3o. Se voc\u00ea \u00e9 programador Java j\u00e1 sabe do que estou falando: os arquivos WAR ou EAR. Reparou que usei o termo “componentes de neg\u00f3cio”?<\/p>\n

O que \u00e9 um componente?<\/h3>\n

\"componente\"Vou usar a defini\u00e7\u00e3o de Fowler e Lewis<\/a> de componente: “\u00e9 aquela unidade de software que pode ser aprimorada e substituida de forma independente”. Vamos pensar num exemplo simples: a biblioteca<\/strong> que voc\u00ea usa para compactar dados. Esta poss\u00edvelmente foi feita por um terceiro. Caso este terceiro descubra uma maneira de compactar dados de forma mais eficiente, basta que voc\u00ea troque a biblioteca, se esta mantiver a mesma assinatura, seu sistema inteiro se beneficiar\u00e1 destas melhorias de forma transparente. E voc\u00ea apenas substituiu um peda\u00e7o do seu sistema.<\/p>\n

Bom: qual o problema ent\u00e3o com aplica\u00e7\u00f5es monol\u00edticas? O fato destas conterem\u00a0em si<\/strong> todos os componentes usados e todos serem executados dentro do\u00a0mesmo processo<\/strong>. Precisou trocar um componente? Voc\u00ea ir\u00e1 fazer o deploy da unidade inteira. J\u00e1 houve algumas solu\u00e7\u00f5es interessantes para este problema, como por exemplo o EJB e OSGi <\/a>(OSGi na minha opini\u00e3o \u00e9 como o Java SEMPRE deveria ter sido, falo mais sobre ele no futuro).<\/p>\n

O ideal seria que voc\u00ea n\u00e3o precisasse parar seu sistema para substituir um componente. Como no caso do bundle OSGi ou da implementa\u00e7\u00e3o remota do EJB, mas nem sempre isto ocorre ou mesmo \u00e9 necess\u00e1rio. Ok: voc\u00ea sabe o que \u00e9 um componente. Um componente de neg\u00f3cio seria portanto aquele que encapsula um requisito funcional do seu sistema<\/strong>. O que \u00e9 ent\u00e3o um micro servi\u00e7o? Um servi\u00e7o pequeno?<\/p>\n

O que \u00e9 um servi\u00e7o?<\/h3>\n

\"servicos\"Seguindo a defini\u00e7\u00e3o de Fowler e Lewis<\/a>, um servi\u00e7o seria na realidade um tipo especial de componente. Aquele componente que descrevi alguns par\u00e1grafos acima \u00e9 o que chamar\u00edamos de\u00a0biblioteca<\/strong>. \u00c9 c\u00f3digo contra o qual ligamos<\/strong> aquele que escrevemos, e que consequentemente nos gera um sistema monol\u00edtico. O servi\u00e7o \u00e9 o\u00a0oposto da biblioteca<\/strong>, ou seja, n\u00f3s n\u00e3o ligamos nosso c\u00f3digo diretamente a este: apenas o executamos a partir de chamadas remotas.
\n<\/strong><\/p>\n

Sendo assim, um servi\u00e7o seria um componente executado em um processo diferente do cliente que o usa. Esta \u00e9 uma id\u00e9ia bastante interessante: caso um servi\u00e7o apresente problemas, basta que,\u00a0em tempo de execu\u00e7\u00e3o<\/strong>, eu substitua apenas aquele peda\u00e7o do sistema, mantendo todo o resto em execu\u00e7\u00e3o como se “quase nada” houvesse ocorrido. Preciso de maior escalabilidade? Poderia pensar em diversas inst\u00e2ncias do mesmo servi\u00e7o. As possibilidades s\u00e3o pr\u00e1ticamente infinitas quando pensamos desta forma.<\/p>\n

E o que \u00e9 o tal do micro servi\u00e7o ent\u00e3o?<\/span><\/h3>\n

\"microservicos\"<\/p>\n

O prefixo “micro” \u00e9 enganador. Em um primeiro momento podemos pensar que se trata de um programa bem pequeno, e na apresenta\u00e7\u00e3o de Lewis<\/a>\u00a0\u00e9 defendido que devem ser pequenos o suficiente para que sejam compreendidos por uma \u00fancia pessoa.<\/p>\n

Um micro servi\u00e7o compreende um requisito funcional do seu sistema. \u00c9 um componente de neg\u00f3cio executado em um processo externo portanto. Como requisitos funcionais podem ser complexos, nada impede que seu “micro” componente n\u00e3o seja t\u00e3o pequeno assim (mas isto vai depender mais da sua modelagem do que desta abordagem). \u00a0Sendo assim acredito que seja mais interessante pensar que o\u00a0ideal<\/strong>\u00a0seria serem micro servi\u00e7os pequenos, por\u00e9m o\u00a0essencial<\/strong> \u00e9 que determinem bem o que venha a ser os requisitos funcionais que implementam.<\/p>\n

Um sistema que siga a arquitetura baseada em micro servi\u00e7os portanto \u00e9 aquela que \u00e9 composta por micro servi\u00e7os, cada um destes respons\u00e1vel por um conjunto finito de requisitos funcionais do projeto.<\/p>\n

Consequ\u00eancias do micro servi\u00e7o<\/h2>\n

A sa\u00edda do modo monol\u00edtico muda bastante coisa no nosso modo de pensar. Para come\u00e7ar podemos pensar em dividir melhor a equipe. Este \u00e9 inclusive um ponto apresentado por Fowler e Lewis<\/a>. Agora podemos ter equipes especializadas naquele conjunto de funcionalidades de neg\u00f3cio, que passar\u00e3o a tratar o servi\u00e7o n\u00e3o como um mero componente, mas sim um produto, com ciclo de vida independente. Isto tr\u00e1s implica\u00e7\u00f5es profundas do ponto de vista gerencial.<\/p>\n

Outro ponto importante: como estes micro servi\u00e7os se comunicam? Faz-se necess\u00e1rio adotar uma estrat\u00e9gia que facilite a integra\u00e7\u00e3o de todas estas pontas. Em todos os artigos s\u00e3o expostas duas estrat\u00e9gias fundamentais: REST (alguns mencionam HATEOAS) e mensageria atrav\u00e9s de algum broker como ActiveMQ, RabbitMQ, HornetQ ou tantos outros. \u00c9 obrigat\u00f3ria a presen\u00e7a de um protocolo aberto comum a todos os servi\u00e7os: imagine ter de usar protocolos propriet\u00e1rios neste tipo de arquitetura, sua vida se tornaria um inferno.<\/p>\n

Um ESB se aplica? No artigo de Fowler e Lewis ele \u00e9 mencionado por alto, mas n\u00e3o se mostra como algo obrigat\u00f3rio. Sinceramente tamb\u00e9m acho que seja desnecess\u00e1rio, apesar de que um servi\u00e7o similar ao UDDI<\/a> quebre troncos nesta abordagem. UDDI \u00e9 a grosso modo um diret\u00f3rio de web services baseados em SOAP. Algo que me responda \u00e0 pergunta “qual o endere\u00e7o das implementa\u00e7\u00f5es do servi\u00e7o x?” tornaria tudo muito mais f\u00e1cil.<\/p>\n

Se todos os processos s\u00e3o isolados, tamb\u00e9m preciso que sejam monitorados, ou seja, todo servi\u00e7o deve apresentar m\u00e9tricas sobre sua qualidade de servi\u00e7o. \u00c9 fundamental que eu saiba quem est\u00e1 ou n\u00e3o online para que cada micro servi\u00e7o possa implementar sua pr\u00f3pria estrat\u00e9gia no caso de indisponibilidade de algum servi\u00e7o do qual dependa.<\/p>\n

E olha outro ponto importante: voc\u00ea tamb\u00e9m precisa de uma estrat\u00e9gia de versionamento que seja consistente. Se os micro servi\u00e7os s\u00e3o por defini\u00e7\u00e3o componentes, estes devem poder evoluir isoladamente tamb\u00e9m.<\/p>\n

Se a comunica\u00e7\u00e3o entre micro servi\u00e7os sempre requer a invoca\u00e7\u00e3o de c\u00f3digo externo \u00e9 necess\u00e1rio pensar em estrat\u00e9gias visando minimizar perda de performance. Uma coisa \u00e9 chamar c\u00f3digo diretamente ligado ao meu (bibliotecas), outra c\u00f3digo remoto.<\/p>\n

H\u00e1 tamb\u00e9m um outro ponto bastante delicado: como pensar a quest\u00e3o da\u00a0componentiza\u00e7\u00e3o?<\/strong> Se quero que meus micro servi\u00e7os sejam completamente independentes como organizo meu c\u00f3digo fonte? Na apresenta\u00e7\u00e3o de Lewis<\/a> \u00e9 proposto que cada equipe tenha seu pr\u00f3prio reposit\u00f3rio a fim de evitar a cria\u00e7\u00e3o de componentes compartilhados que causem depend\u00eancias profundas entre um ou mais micro servi\u00e7os. Faz muito sentido, especialmente se eu quiser que alguns componentes sejam escritos em linguagens distintas. Imagine dois micro servi\u00e7os dependentes de uma biblioteca compartilhada: alterando-a mudo o comportamento de dois componentes que deveriam ser em teoria completamente independentes.<\/p>\n

E estes s\u00e3o apenas alguns dos pontos gerais que observei nesta abordagem. Voc\u00eas com certeza me mostrar\u00e3o mais alguns nos coment\u00e1rios deste post, certo? :)<\/p>\n

Consequ\u00eancias do lado Java<\/h3>\n

Pensando como desenvolvedor Java as coisas mudam de figura no modo como pensamos o deploy de nossos projetos. At\u00e9 ent\u00e3o pensamos em arquivos WAR e EAR que iremos instalar em nossos servidores de aplica\u00e7\u00e3o. No entanto os servi\u00e7os s\u00e3o executados isoladamente, certo?<\/p>\n

Logo devemos minimizar o uso de containers. Imagine que eu sobrecarregue um container com in\u00fameros micro servi\u00e7os. Se este cai, diversos v\u00e3o junto. A solu\u00e7\u00e3o \u00e9 embarcar o container e distribuir nossa aplica\u00e7\u00e3o como um jar \u00fanico. J\u00e1 h\u00e1 projetos que nos permitem fazer isto. Destes o que acho mais interessante atualmente (e que podemos usar HOJE) \u00e9 o Spring B oot<\/a>. Grails ter\u00e1 algo similar em breve (afinal de contas, \u00e9 Pivotal n\u00e9?), Vertx<\/a>\u00a0tamb\u00e9m nos permite fazer algo similar.<\/p>\n

E ei: se voc\u00ea olhar com aten\u00e7\u00e3o, ver\u00e1 que toda a hist\u00f3ria por tr\u00e1s do Node.js gira em torno deste conceito tamb\u00e9m. ;)<\/p>\n

Mas cad\u00ea a novidade?<\/h2>\n

Este \u00e9 minha grande d\u00favida. Cad\u00ea a novidade? Decompor nossos projetos em micro servi\u00e7os \u00e9 algo que fazemos h\u00e1 muito tempo. Veja por exemplo EJB e seu modelo distribu\u00eddo. Um \u00fanico protocolo comum (RMI por baixo dos panos) e l\u00f3gica de neg\u00f3cios encapsulada no bean.<\/p>\n

Outro exemplo interessante: OSGi. Em que eu posso inclusive fazer o deploy de um servi\u00e7o (representado como um bundle) no container em tempo de execu\u00e7\u00e3o sem parar a aplica\u00e7\u00e3o. Neste caso n\u00e3o necess\u00e1riamente seria um micro servi\u00e7o pois o bundle \u00e9 executado na maior parte das vezes dentro de um mesmo processo, mas poderia ser externo tamb\u00e9m.<\/p>\n

E tem tamb\u00e9m o SOA, que nos fornece exatamente isto com o uso de ESBs, certo? Isto sem mencionar as diversas vezes em que desenvolvemos sistemas usando esta mesma abordagem no passado sem fugir muito destes princ\u00edpios que apresentei sem darmos este nome (aqui<\/a> est\u00e1 um exemplo interessante no blog do Rafael Rom\u00e3o).<\/p>\n

A novidade talvez esteja no fato de finalmente estarmos dando um nome a este boi. Gosto disto, quanto melhor o vocabul\u00e1rio, melhor.<\/p>\n

Concluindo<\/h2>\n

N\u00e3o acredito que a pergunta “ser\u00e1 uma arquitetura baseada em micro servi\u00e7os o futuro?” ser\u00e1 respondida somente em um futuro distante. Na realidade, ela j\u00e1 foi resolvida: ela \u00e9 o presente. A partir do momento em que isolamos os objetivos de neg\u00f3cio do nosso sistema em processos isolados que possuam as caracter\u00edsticas a seguir:<\/p>\n