Microservices: Decomposio de Aplicaes

para Implantao e Escalabilidade

A arquitetura monoltica um padro comumente usado para o desenvolvimento de
aplicaes corporativas. Esse padro funciona razoavelmente bem para pequenas
aplicaes, pois o desenvolvimento, testes e implantao de pequenas aplicaes
monolticas relativamente simples. No entanto, para aplicaes grandes e complexas, a
arquitetura monoltica torna-se um obstculo ao desenvolvimento e implantao, dificulta a
utilizao de uma entrega contnua, alm de limitar a adoo de novas tecnologias. Para
grandes aplicaes, faz mais sentido usar uma arquitetura de microservices, que divide a
aplicao em um conjunto de servios.
A arquitetura de microservices tem muitas vantagens, por exemplo, servios individuais
so mais fceis de entender e podem ser desenvolvidos e implantados de forma
independente. Adotar novas tecnologias e frameworks torna-se mais fcil, pois a adoo
pode ser aplicada em um servio de cada vez. A arquitetura de microservices tambm tem
algumas desvantagens significativas. Em particular, as aplicaes so muito mais
complexas e constitudas por mais elementos. Para ser utilizada de forma eficaz, a
arquitetura de microservices exige um alto nvel de automao, como um PaaS. Ao
desenvolver microservices, necessrio lidar com alguns problemas complexos de
gerenciamento de dados distribudos. Apesar dos obstculos, a arquitetura de
microservices adequada para aplicaes complexas e de grande porte que esto
evoluindo rapidamente, especialmente para aplicaes do tipo SaaS.
Existem vrias estratgias para evoluir de forma incremental uma aplicao monoltica
existente em uma arquitetura de microservices. Os desenvolvedores devem implementar
novas funcionalidades na forma de servios independentes e criar mecanismos para
integrar os servios com a aplicao monoltica. possvel tambm identificar
componentes da aplicao monoltica e refator-los em servios. Embora a refatorao
no seja trivial, melhor do que desenvolver e manter uma aplicao monoltica pesada e
inadequada.
Contedo relacionado de patrocinadores
Um guia para REST e o design de APIs
5 pilares do gerenciamento de APIs
5 pontos fundamentais do OAuth para o controle de acesso a APIs
Proteja suas fronteiras: segurana de microservices com Spring Security e CAS, no QCon So
Paulo 17
Infraestrutura e criao de APIs em alta escala usando Docker e Apache Mesos, no QCon So
Paulo 2017

Este artigo descreve um padro de arquitetura que est se tornando muito

popular conhecido como Microservice. A ideia da arquitetura de microservices projetar
aplicaes grandes, complexas e durveis em um conjunto coeso de servios que
evoluem ao longo do tempo. O termo microservices sugere fortemente que os servios
sejam pequenos.

Algumas pessoas da comunidade defendem ainda o desenvolvimento de servios com 10100 linhas de cdigo. Embora seja desejvel que os sistemas sejam pequenos, a
quantidade de cdigo no deve ser o principal objetivo. Em vez disso, deve-se visar a
decomposio do sistema em servios, a fim de resolver problemas de desenvolvimento e
implantao discutidos neste artigo. Alguns servios podem ser de fato muito pequenos,
enquanto outros podem ser muito grandes.
A essncia da arquitetura de microservices, assim como o conceito de sistemas
distribudos; bem antiga e se assemelha ao SOA.
A arquitetura de microservices j foi considerada uma verso leve ou de granularidade fina
de SOA. De fato, uma forma de pensar na arquitetura de microservices est relacionada
com SOA, porm sem a o fator comercial e livre de tecnologias WS* e ESB. Apesar de no
ser uma ideia totalmente nova, ainda vlida a discusso sobre a arquitetura de
microservices, uma vez que difere do tradicional SOA e, mais importante, soluciona vrios
problemas que muitas organizaes sofrem atualmente.
Este artigo apresenta as motivaes do uso da arquitetura de microservices e a compara
com a tradicional arquitetura monoltica. O artigo discute os benefcios e desvantagens do
uso da arquitetura de microservices, alm de apresentar solues para alguns desafios
tcnicos que incluem a comunicao entre servios e o gerenciamento de dados
distribudo.

A (algumas vezes m) aplicao monoltica

Desde de o inicio do desenvolvimento web, a arquitetura mais utilizada em aplicaes
corporativas tem sido aquela que empacota todos os componentes do servidor (serverside) em uma nica unidade. Muitas aplicaes corporativas desenvolvidas em Java so
formadas por um simples arquivo WAR ou EAR. O mesmo ocorre com aplicaes escritas
em outras linguagens, como Ruby e at mesmo C++.
Imagine por exemplo, o desenvolvimento uma loja online que recebe pedidos de clientes,
verifica o estoque e o crdito do cliente e envia os produtos. muito provvel que a
aplicao seja semelhante a mostrada na Figura 1.

Figura 1 - a arquitetura monoltica

A aplicao constituda por diversos componentes como, StoreFront UI que implementa
a interface com o usurio, servio para o gerenciamento do catlogo de produtos (Catalog

Service), servio de processamento de pedidos (Order Service) e servio de

gerenciamento de clientes (Customer Service). Estes servios compartilham o mesmo
modelo de domnio, constitudo por entidades como Produto (Product) , Pedido (Order) e
Cliente (Customer).
Apesar de ter um design modular, a aplicao implantada de forma monoltica. Por
exemplo, em aplicaes desenvolvidas em Java, apenas um arquivo WAR implantado
em container web como o Tomcat. Em aplicaes desenvolvidas em Rails, um nico
diretrio implantado no Apache/Nginx atravs do Phusion Passager, ou aplicaes
desenvolvidas com JRuby implantadas no Tomcat.
A denominada arquitetura monoltica tem uma srie de benefcios. Aplicaes monolticas
so simples para desenvolver, uma vez que IDEs e outras ferramentas de
desenvolvimento so direcionadas para o desenvolvimento de uma nica aplicao. Elas
so fceis de testar, pois preciso apenas executar o aplicativo. Aplicaes monolticas
tambm so de simples implantao, basta apenas copiar a unidade de implantao - um
arquivo ou diretrio - para uma mquina com um servidor adequado.
Esta abordagem funciona bem para aplicaes relativamente pequenas. Entretanto, a
arquitetura monoltica torna-se inadequada para aplicaes complexas. Uma grande
aplicao monoltica pode dificultar o entendimento e a manuteno para os
desenvolvedores. tambm um obstculo constante para implantaes. Para implantar as
mudanas de um componente, preciso fazer o build e implantar a aplicao inteira,
atividade que pode ser complexa, arriscada, consome tempo, requer a coordenao de
muitos desenvolvedores e resulta em longos ciclos de teste.
A arquitetura monoltica tambm torna difcil testar e adotar novas tecnologias. difcil, por
exemplo, testar um novo framework infraestrutural sem reescrever toda a aplicao, o que
arriscado e impraticvel. Consequentemente, comum ficar restrito as escolhas
tecnolgicas feitas no inicio do projeto. Em outras palavras, a arquitetura monoltica no
adequada para aplicaes grandes e durveis.

Decomposio de aplicaes em servios

Felizmente existem outras arquiteturas. O livro, The Art of Scalability, descreve um modelo
de escalabilidade de trs dimenses: the scale cube, apresentado na Figura 2.

Figura 2 - o scale cube

Neste modelo, a abordagem mais comum para escalar uma aplicao atravs da
execuo de mltiplas cpias idnticas da aplicao, acessveis atravs de um
balanceador de carga. Conhecida como escalabilidade horizontal, corresponde a
escalabilidade no eixo X (X-axis scaling), uma tima maneira para aumentar a
capacidade e disponibilidade de uma aplicao.
A escalabilidade no eixo Z (Z-axis scaling) similar a do eixo X, onde cada servidor
executa uma cpia idntica do cdigo. A grande diferena que cada servidor
responsvel por seu conjunto dos dados. Essa abordagem exige a presena de um
componente responsvel pelo roteamento das requisies para um servidor apropriado.
Uma maneira de executar o roteamento atravs do uso de parmetros na requisio, por
exemplo, a chave primria da entidade solicitada. Essa abordagem utilizada
normalmente em arquiteturas NoSQL que realizam a distribuio de informaes atravs
do processo conhecido como sharding. Outra forma de roteamento por tipo de cliente.
Por exemplo, uma aplicao pode fornecer um SLA mais elevado aos clientes pagantes,
encaminhando suas requisies a um conjunto de servidores com mais capacidade.
As abordagens Z-axis scaling e X-axis scaling ampliam a capacidade e a disponibilidade
da aplicao. Entretanto, nenhuma resolve os problemas do aumento da complexidade do
desenvolvimento e da prpria aplicao. Para solucionar estes problemas preciso aplicar
a escalabilidade de eixo Y (Y-axis scaling).
A terceira dimenso de escalabilidade denominada decomposio funcional ou (Y-axis
scaling) aplicada sobre o eixo Y. Enquanto a escalabilidade de eixo Z divide elementos

semelhantes, a escalabilidade de eixo Y divide elementos diferentes. A camada de

aplicao, (Y-axis scaling) divide uma aplicao monoltica em um conjunto de servios.
Cada servio implementa um conjunto de funcionalidades relacionadas, por exemplo,
gerenciamento de pedidos, gerenciamento de clientes etc.
Decidir como particionar um sistema em um conjunto de servios uma arte, mas existem
estratgias que podem ajudar. Uma abordagem particionar os servios por verbos ou
casos de uso. Mais adiante no artigo, apresentado um exemplo onde a loja online, j
particionada, tem um servio para fechamento de pedidos (Chekout UI service), que
implementa a interface com o usurio o caso de uso Chekout.
Outra abordagem o particionamento por sinnimos ou recursos. Este tipo de servio
responsvel por todas as operaes sobre entidades/recursos de um determinado tipo.
Por exemplo, faz sentido que a loja tenha o servio Catalog service, que gerencia o
catlogo de produtos.
O ideal que cada servio possua poucas responsabilidades. (Uncle) Bob Martin fala
sobre a modelagem de classes o com Princpio da Responsabilidade nica (Single
Responsible Principle). O princpio define que uma classe s deve ter uma razo para ser
modificada. Servios tambm podem ser modelados com o Princpio da Responsabilidade
nica.
Outra analogia que auxilia na modelagem de servios o modelo de funcionalidades Unix.
Unix oferece vrias funcionalidades como grep, cat e find. Cada funcionalidade executa
exatamente uma nica coisa, a menos que combinada com outra funcionalidade atravs
de shell script para executar tarefas complexas. Faz sentido modelar servios baseados
nas funcionalidades Unix e criar servios com responsabilidade nica.
importante notar que o objetivo da decomposio no ter servios com 10-100 linhas
de cdigo. Em vez disso, o objetivo solucionar os problemas e limitaes da arquitetura
monoltica descritos anteriormente. Alguns servios podem muito bem ser pequenos, mas
outros sero substancialmente grandes.
A Figura 3 apresenta o resultado da adoo da decomposio Y-axis scaling na aplicao
de exemplo.

Figura 3 - arquitetura de microservices

A aplicao decomposta em diversos servios de front end, que implementam diferentes
partes da interface do usurio e mltiplos servios de back end. Os servios de front end
so, Catalog UI, que implementa a busca e a navegao de produtos, e o Checkout UI,
que implementa o carrinho de compras e o processo de checkout. Os servios de back
end possuem a mesma lgica descrita no inicio do artigo. Cada componente lgico da
aplicao foi transformado em um servio independente (standalone). A seguir, so
apresentadas as consequncias dessa transformao.

Benefcios e desvantagens da arquitetura de microservices

Esta arquitetura possui muitos benefcios. Primeiramente, cada microservice
relativamente pequeno. O cdigo facilmente compreendido pelo desenvolvedor. A baixa
quantidade de cdigo no torna a IDE lenta, tornando os desenvolvedores mais
produtivos. Alm disso, cada servio inicia muito mais rpido que uma grande aplicao
monoltica, que novamente, torna os desenvolvedores mais produtivos e agiliza as
implantaes.

Segundo, cada servio pode ser implantado independentemente de outros servios. Caso
os desenvolvedores responsveis por um servio necessitem implantar uma modificao
para um determinado servio, no h necessidade de coordenao com outros
desenvolvedores. Pode-se simplesmente implantar as modificaes. A arquitetura de
microservices torna vivel a implantao contnua.
Terceiro, cada servio pode ser escalado de forma independente de outros servios
atravs da duplicao (X-axis scaling) e particionamento (Z-axis scaling). Alm disso, cada
servio pode ser implantado em um hardware mais adequado para as exigncias de seus
recursos. Situao bem diferente da utilizao de uma arquitetura monoltica, que possui
componentes com diferentes necessidades, por exemplo, uso intenso de CPU x uso
intensivo de memria, so juntamente implantados.
A arquitetura de microservices facilita escalar o desenvolvimento. Pode-se organizar o
esforo de desenvolvimento em vrios times pequenos, por exemplo, two pizza teams.
Cada equipe responsvel pelo desenvolvimento e implantao de um nico servio ou
um conjunto de servios relacionados. Cada time pode desenvolver, implantar e escalar
seus servios, independente de todos os outros times.
A arquitetura de microservices tambm melhora o isolamento de falhas. Por exemplo, um
memory leak em um servio afeta apenas aquele servio. Outros servios iro continuar a
receber requisies normalmente. Em contrapartida, em uma arquitetura monoltica, um
componente com comportamento inadequado ir comprometer todo o sistema.
A arquitetura de microservices elimina qualquer compromisso de longo prazo com a stack
de tecnologia. Em princpio, ao desenvolver um novo servio, os desenvolvedores so
livres para escolher qualquer framework e linguagem adequados para aquele servio.
Embora, em muitas organizaes as escolhas possam ter restries, o ponto principal a
independncia sobre as decises tomadas anteriormente.
Alm disso, devido aos servios serem pequenos, torna-se prtico reescrev-los usando
melhores linguagens e tecnologias. Caso ocorra uma falha ao experimentar uma nova
tecnologia , pode-se descartar o trabalho sem afetar todo o projeto. Situao bem diferente
da utilizao de uma arquitetura monoltica, onde as escolhas tecnolgicas iniciais
restringem severamente a possibilidade de adotar diferentes linguagens e frameworks no
futuro.

Desvantagens
claro que nenhuma tecnologia uma bala de prata, e a arquitetura de microservices
possui uma srie de desvantagens e problemas significativos. Primeiramente, os
desenvolvedores devem lidar com a complexidade adicional de desenvolvimento de
sistemas distribudos. Os desenvolvedores devem implementar um mecanismo de
comunicao entre processos. A implementao de casos de uso que abrangem vrios
servios sem o uso de transaes distribudas difcil. IDEs e outras ferramentas de
desenvolvimento tem o foco na construo de aplicaes monolticas e no oferecem
suporte direto para o desenvolvimento de aplicaes distribudas. Escrever testes

automatizados para vrios servios um desafio. Estes problemas no existem em uma

arquitetura monoltica.
A arquitetura de microservices introduz uma complexidade operacional significativa.
Existem muito mais elementos (mltiplas instancias de diferentes servios) que devem ser
gerenciados em produo. Para alcanar o sucesso necessita-se de um alto nvel de
automao, seja por cdigo desenvolvido pela prpria equipe ou tecnologias PaaS como
Netflix Asgard e componentes relacionados, ou tecnologias personalizados como Pivotal
Cloud Foundry.
Alm disso, a implantao de funcionalidades que abrangem vrios servios requer uma
coordenao cuidadosa entre as vrias equipes de desenvolvimento. preciso criar um
plano ordenado de implantaes de servios com base nas dependncias entre servios.
Entretanto, implantar atualizaes em uma arquitetura monoltica mais simples, pois
executado de forma atmica, onde apenas um artefato precisa ser implantado.
Outro desafio da arquitetura de microservices decidir qual o momento do ciclo de vida da
aplicao deve-se adotar esta arquitetura. Ao desenvolver a primeira verso de uma
aplicao, geralmente os problemas resolvidos pela arquitetura no existem. Entretanto, o
uso de uma arquitetura distribuda elaborada ir atrasar o desenvolvimento.
Isso pode ser um grande dilema para startups cujo grande desafio , muitas vezes, evoluir
rapidamente o modelo de negcio juntamente com a aplicao. Aplicar a decomposio
(Y-axis scaling) pode tornar as iteraes mais demoradas. Mais tarde, quando o desafio
a escalabilidade, necessita-se usar a decomposio funcional, porm as dependncias
podem estar to emaranhadas que torna difcil decompor a aplicao monoltica em um
conjunto de servios.
Devido a esses problemas, a adoo da arquitetura de microservices no deve ser tratada
de forma leviana. No entanto, para aplicaes que necessitam de escalabilidade, como
uma aplicao web voltada para o consumidor ou aplicao SaaS, geralmente a escolha
certa. Sites conhecidos, tais como eBay[PDF], Amazon.com, Groupon e Gilt evoluram de
uma arquitetura monoltica para uma arquitetura de microservices.
Uma vez apresentados os benefcios e desvantagens, o momento de analisar algumas
questes fundamentais de projeto em uma arquitetura de microservices, comeando com
mecanismos de comunicao entre microservices e entre os seus clientes.

Mecanismos de
microservices

comunicao

em

uma

arquitetura

de

Em uma arquitetura de microservices, os padres de comunicao entre clientes e a

aplicao, bem como entre os prprios componentes da aplicao, so diferentes de uma
aplicao monoltica. Primeiramente, so abordadas as questes de interao entre
clientes e os microservices. Em seguida, so abordados os mecanismos de comunicao
entre microservices.

Padro API gateway

Em uma arquitetura monoltica, os clientes da aplicao (navegadores web e aplicaes
nativas), realizam requisies HTTP para um balanceador de carga que direciona a
requisio para uma das N instncias idnticas da aplicao. Porm, em uma arquitetura
de microservices, a aplicao monoltica foi substituda por uma srie de servios. Em
razo disso, a questo a ser respondida : Como os clientes interagem com os
microservices?
Uma aplicao cliente mvel nativa, por exemplo, pode realizar requisies HTTP RESTful
diretamente para os servios como ilustrado pela Figura 4.

Figura 4 - chamada direta de servios

A primeira vista pode parecer atraente, entretanto, existe uma incompatibilidade
significativa de granularidade entre APIs compostas por servios individuais e a exigncia
de dados dos clientes. Por exemplo, exibir uma pgina web pode exigir chamadas para
diversos servios. A Amazon.com, relata que algumas pginas web realizam chamadas
para mais de 100 servios. Realizar todas essas requisies, mesmo com internet de alta
velocidade, seria muito ineficaz, resultando em uma pssima experincia ao usurio.
Uma abordagem muito melhor para os clientes realizar poucas requisies por pgina,
preferencialmente uma, atravs de um servidor de front end denominado API gateway,
como mostra a Figura 5.

Figura 5 - API gateway

A API gateway localiza-se entre os clientes da aplicao e os microservices, e proporciona
APIs adaptadas para as necessidades de diferentes clientes. API gateway fornece uma
API de granularidade grossa para clientes mveis e uma API com granularidade fina para
clientes desktop que utilizam uma rede de alta velocidade. Neste exemplo, os clientes
desktop realizam vrias requisies para recuperar informaes sobre um produto, porm,
um cliente mvel realiza uma nica requisio.
A API gateway recebe as requisies dos clientes e realiza diversas outras requisies
para microservices conectados por redes locais de alta velocidade. A Netflix, por
exemplo, relata que cada requisio envolve em mdia seis servios de back end. Neste
exemplo, as requisies com granularidade fina provenientes de um cliente desktop, so
simplesmente proxy para o servio correspondente, ao passo que cada requisio de
granularidade grossa de um cliente mvel tratada atravs da agregao de chamadas
para vrios servios.
Alm de otimizar a comunicao entre clientes e a aplicao, a API gateway encapsula os
detalhes dos microservices, permitindo sua evoluo sem causar impacto aos clientes. Por
exemplo, dois microservices podem ser agrupados em um nico servio. Outro
microservice pode ser dividido em dois ou mais servios. Apenas a API gateway precisa
ser atualizada para refletir estas mudanas. Dessa forma, os clientes no so afetados.
At este ponto, foi apresentado o papel da API gateway como mediador entre a aplicao
e seus clientes. A seguir, apresentado como implementar a comunicao entre
microservices.

Mecanismos de comunicao inter-service

Outra grande diferena da arquitetura de microservices a forma de interao entre os

diferentes componentes da aplicao. Em uma aplicao monoltica, componentes
comunicam-se atravs de chamadas de mtodos. Mas em uma arquitetura de
microservices, diferentes servios so executados em diferentes processos.
Consequentemente, os servios devem utilizar uma comunicao entre processos (IPC inter-process communication).

HTTP sncrono
Existem duas principais abordagens para a comunicao entre processos em uma
arquitetura de microservices. Uma opo utilizar mecanismos baseados em HTTP
sncrono como REST ou SOAP. Esta opo simples, conhecida e facilmente gerencivel
por firewalls, ou seja, permite a comunicao atravs da Internet, facilitando a
comunicao no formato request/reply. A desvantagem do HTTP a falta de suporte a
outros padres de comunicao, como publish/subscribe.
Outra limitao que cliente e servidor devem estar disponveis simultaneamente,
situao difcil de ser garantida, pois os sistemas distribudos so propensos a falhas
parciais. Alm disso, um cliente HTTP precisa saber o endereo e a porta do servidor.
Embora parea simples, essas informaes podem no estar disponveis diretamente,
especialmente em uma infraestrutura de nuvem que usa auto-scaling onde instncias de
servio so efmeras. Essa abordagem exige o uso de um mecanismo de descoberta de
servio. Algumas aplicaes usam um registro de servios como o Apache ZooKeeper ou
Netflix Eureka. Em outras aplicaes, servios devem ser registrados com um balanceador
de carga, como um ELB interno em um VPC Amazon.

Mensagens Assncronas
Uma alternativa para o HTTP sncrono um mecanismo assncrono baseado em
mensagens como um broker de mensagens AMQP. Esta abordagem tem muitos
benefcios, pois desacopla os produtores de mensagens dos consumidores. O broker
capaz de enfileirar e manter as mensagens at serem processadas por consumidores. O
produtor simplesmente envia a mensagem para o broker, sem a necessidade de um
mecanismo de descoberta de servios. A comunicao baseada em mensagens tambm
suporta uma variedade de padres de comunicao, incluindo os pedidos de caminho
nico (one-way requests) e publish-subscribe. Uma desvantagem do uso de mensagens
a necessidade de um broker, que mais um componente que aumenta a complexidade do
sistema. Outra desvantagem que a comunicao sncrona (request/reply) no se ajusta
naturalmente a esse estilo de comunicao.
Existem prs e contras nas duas abordagens. desejvel que as aplicaes utilizem a
combinao das duas abordagens. Por exemplo, a prxima seo discute como resolver
os problemas de gerenciamento de dados que surgem em uma arquitetura distribuda,
ser apresentado como HTTP e mensageria so usadas em conjunto.

Gerenciamento de dados descentralizados

Uma consequncia da decomposio da aplicao em servios o particionamento da
base de dados. Para garantir o baixo acoplamento, cada servio tem sua prpria base de

dados (schema). Alm disso, diferentes servios podem usar diferentes tipos de base de
dados, conhecido como arquitetura de persistncia poliglota. Por exemplo, um servio que
necessita de transaes ACID pode utilizar um banco de dados relacional, enquanto um
servio que manipula uma rede social pode utilizar um bando de dados baseado em
grafos. Particionar a base de dados essencial, mas isso resulta em um novo problema:
como lidar com as solicitaes que acessam dados pertencentes a vrios servios? A
seguir abordado como manipular as solicitaes de leitura e atualizao.

Manipulao de requisies de leitura

O exemplo da loja eletrnica define que cada cliente possui um limite de crdito. Quando
um cliente tenta fazer um pedido, o sistema deve verificar se a soma de todos os pedidos
em aberto no ultrapassa o limite de crdito. A implementao dessa regra de negcio
trivial em uma aplicao monoltica. Entretanto, muito mais difcil de implementar essa
verificao em um sistema onde os clientes (customers) so gerenciados pelo
CustomerService e os pedidos so gerenciados por OrderService. De alguma forma,
OrderService deve acessar o limite de crdito mantido pelo CustomerService.
Uma soluo OrderService recuperar o limite de crdito atravs de chamadas remotas
RPC (Remote Procedure Call) ao CustomerService. Esta abordagem simples de
implementar e garante que OrderService sempre tem o limite de crdito atualizado. A
desvantagem que ele reduz a disponibilidade, pois CustomerService deve estar em
execuo para que OrderService realize um pedido, alm de aumentar o tempo de
resposta, devido a chamada remota adicional.
Outra abordagem armazenar uma cpia do limite de crdito em OrderService. Esta
abordagem elimina a necessidade de uma requisio ao CustomerService, aumenta a
disponibilidade e reduz o tempo de resposta. Porm, implica na implementao de um
mecanismo de atualizao da cpia do limite de crdito quando ocorrer alguma
modificao em CustomerService.

Manipulao de requisies de atualizao

Manter o limite de crdito atualizado no OrderService um exemplo comum de problema
resultante da manipulao de requisies de atualizao de dados de diferentes servios.

Transaes distribudas
Uma soluo utilizar transaes distribudas. Por exemplo, ao atualizar o limite de crdito
do cliente, CustomerService poderia usar uma transao distribuda para atualizar o limite
de crdito juntamente com o valor mantido por OrderService. O uso de transaes
distribudas garante consistncia aos dados. A desvantagem a reduo da
disponibilidade do sistema, uma vez que todos os elementos envolvidos devem estar
disponveis para que a transao seja efetivada. Alm disso, transaes distribudas esto
caindo em desuso, e no so geralmente suportadas nas stacks de software modernas,
como REST, bancos de dados NoSQL etc.

Atualizaes assncronas baseadas em eventos

A outra abordagem usar a replicao assncrona baseada em eventos. Servios

publicam eventos anunciando que alguns dados foram alterados. Outros servios que
esto inscritos para receber esses eventos, atualizam seus dados. Por exemplo, quando
CustomerService atualiza o limite de crdito de um cliente, ele publica um
CustomerCreditLimitUpdatedEvent, que contm o ID do cliente e o novo limite de crdito.
OrderService recebe esses eventos e atualiza sua cpia do limite de crdito. O fluxo de
eventos mostrado na Figura 6.

Figura 6 - replicao do limite de crdito atravs de eventos

O grande benefcio desta abordagem o desacoplamento entre produtores e
consumidores de eventos. O desacoplamento simplifica o desenvolvimento e aumenta a
disponibilidade, em comparao ao uso de transaes distribudas. Caso nenhum
consumidor esteja disponvel para processar um evento, o broker de mensagens ir
enfileirar o evento at que a mensagem possa ser processada. A grande desvantagem
desta abordagem troca de consistncia em favor de disponibilidade. A aplicao deve
ser escrita de forma a tolerar eventuais inconsistncias de dados. Desenvolvedores podem
ter que implementar mecanismos de transao com suporte rollbacks por compensao.
Apesar desses inconvenientes, esta a abordagem preferida para muitas aplicaes.

Refatorao de aplicaes monolticas

Infelizmente, nem sempre possvel trabalhar em um projeto totalmente novo (greenfield
project). H uma grande chance de trabalhar em times responsveis por enormes e
assustadoras aplicaes monolticas. A boa noticia que existem tcnicas que podem ser
utilizadas para decompor aplicaes monolticas em um conjunto de servios.
A primeira coisa a ser feita no tornar o problema ainda maior. Implementaes de
novas e significativas funcionalidades no devem ser realizadas na aplicao monoltica.
Novas funcionalidades devem ser implementadas como servios independentes, como
ilustra a Figura 7. Esta no uma atividade fcil, pois necessrio desenvolver uma

complexa interface (glue code) para realizar a integrao entre os servios e a aplicao
monoltica. Este um bom comeo para a decomposio de aplicaes monolticas.

Figura 7 - refatorando para um servio

O prximo passo a identificao de componentes da aplicao monoltica que sero
transformados em servios coesos e independentes. Bons candidatos para essa
transformao so componentes que esto em constante modificao ou que possuem
conflitos de recursos, como grande quantidade de dados em memria ou operaes
intensas de CPU. A camada de apresentao tambm uma boa candidata. Pode-se
transformar o componente em um servio e desenvolver uma interface (glue code) para
integrar com o resto da aplicao. Embora no seja trivial, esta atividade permite migrar
gradativamente para uma arquitetura de microservices.

Sobre o autor
Chris Richardson desenvolvedor e arquiteto. Java Champion, estrela do JavaOne e
autor do livro POJOs in Action, livro que descreve o desenvolvimento de aplicaes
enterprise Java com uso de POJOs e frameworks como Spring e Hibernate. Chris tambm
fundador da original Clound Foundry, o incio da plataforma Paas da Amazon EC2. Atua
como consultor em organizaes que buscam melhorar o desenvolvimento e implantao
de aplicaes atravs da utilizao de tecnologias como computao em nuvem,
microservices e NoSQL. Twitter @crichardson.