UNIVERSIDADE FEDERAL DO CEAR

CAMPUS DE QUIXAD ENGENHARIA DE

SOFTWARE

THIAGO PEREIRA ROSA

UM MTODO PARA O DESENVOLVIMENTO DE SOFTWARE

BASEADO EM MICROSSERVIOS

QUIXAD - CE
2016
 THIAGO PEREIRA ROSA

UM MTODO PARA O DESENVOLVIMENTO DE SOFTWARE

BASEADO EM MICROSSERVIOS

Trabalho de concluso de curso submetido

Coordenao do Curso Bacharelado em Engenharia
de Software da Universidade Federal do Cear como
requisito parcial para obteno do grau de bacharel.
rea de concentrao: Cincia da Computao/
Metodologia e Tcnicas da Computao / Engenharia
de Software.

Orientador(a): Ticiana Linhares Coelho da Silva.

Co-Orientador: Flvio Rubens de Carvalho Souza.

QUIXAD - CE
2016
 Dados Internacionais de Catalogao na Publicao
Universidade Federal do Cear
Biblioteca do Campus de Quixad

R696m Rosa, Thiago Pereira

Um mtodo para o desenvolvimento de software baseado em microsservios/ Thiago Pereira
Rosa. 2016.
64 f.: il. color., enc.; 30 cm.

Monografia (graduao) Universidade Federal do Cear, Campus Quixad, Curso de

Engenharia de Software, Quixad, 2016.
Orientao: Prof. Me. Ticiana Linhares Coelho da Silva
Coorientao: Prof. Dr. Flvio Rubens de Carvalho Sousa
rea de concentrao: Computao

1. Software - desenvolvimento. 2. Arquitetura de software. 3. Sistemas de computao.

I. Universidade Federal do Cear (Campus Quixad). II. Ttulo.

CDD 005.1
 THIAGO PEREIRA ROSA

UM MTODO PARA O DESENVOLVIMENTO DE SOFTWARE

BASEADO EM MICROSSERVIOS

Trabalho de concluso de curso submetido

Coordenao do Curso Bacharelado em Engenharia
de Software da Universidade Federal do Cear como
requisito parcial para obteno do grau de bacharel.
rea de concentrao: Cincia da Computao /
Metodologia e Tcnicas da Computao / Engenharia
de Software.

Aprovado em: 15 / fevereiro / 2016

BANCA EXAMINADORA

Prof(a). MSc. Ticiana Linhares Coelho da Silva

Orientador(a)

Prof. Dr. Flvio Rubens de Carvalho Sousa

Co-Orientador

Prof. MSc. Rgis Pires Magalhes

Universidade Federal do Cear
Dedico este trabalho minha famlia e amigos.
 RESUMO

Devido ao grande avano da tecnologia, as formas de comunicao e conectividade se

reinventaram. Assim, a maneira de desenvolver software tem se tornado mais complexa e
multidisciplinar. Utilizar a arquitetura monoltica como padro de desenvolvimento de
aplicaes corporativas uma abordagem comumente empregada, no entanto, este padro gera
complicaes quando utilizado para desenvolver grandes aplicaes, com contratempos na
escala e principalmente inconvenientes quando h necessidade de iteraes e entregas
frequentes. Com isso, a arquitetura de microsservios surge como uma alternativa para
construo de aplicaes corporativas complexas. Fundamentado nesta alternativa, este
trabalho de concluso de curso prope e avalia um mtodo para o desenvolvimento de software
baseado em microsservios. Para isso, foi realizado um estudo de caso construindo um sistema
baseado em microsservios para complementar o tratamento medicinal com aplicao de
fototerapia.

Palavras chave: Software como Servio, Desenvolvimento de Software, Sistema Monoltico,

Arquitetura orientada a Servios.
 ABSTRACT

Due to the great advancement of technology, communication tools and connectivity have
reinvented. Therefore, the way to develop software has become more complex and
multidisciplinary. Using the monolithic architecture as standard enterprise application
development is an approach commonly employed, however, this pattern generates
complications when used to develop large applications with setbacks in scale and particularly
inconvenient when it is necessary iterations and frequent deliveries. Indeed, the microservices
architecture is an alternative for building complex enterprise applications. Based on this
alternative, this term paper proposes and evaluates a method for developing a microservices
software. For this purpose, was conducted a case study building a microservices-based system
to complement the medical treatment with phototherapy application.

Keywords: Software as a Service, Software Development, Monolithic Application, Service-

Oriented Architecture.
 LISTA DE ILUSTRAES

Figura 1 - Estilo arquitetnico bsico baseado em microsservios ................................................ 13

Figura 2 - Arquitetura tradicional de uma aplicao web ............................................................... 15
Figura 3 - Aplicao utilizando arquitetura baseada em microsservios........................................ 16
Figura 4 - Abstrao da arquitetura hexagonal ............................................................................... 18
Figura 5 - Ilustrao do modelo de camadas em intercomunicao ............................................... 20
Figura 6 - Papis na computao em nuvem .................................................................................. 22
Figura 7 - Modelo European Telecommunications Standards Institute M2M ............................... 26
Figura 8 - FI-WARE data model, particionado em verbos e substantivos ...................................... 27
Figura 9 - Aplicao monoltica ..................................................................................................... 30
Figura 10 - Tecnologia de virtualizao tradicional e continer..................................................... 33
Figura 11 - Provisionamento das tecnologias de VM tradicionais e contineres ........................... 34
Figura 12 - Uma abordagem para comunicao dos microsservios.............................................. 35
Figura 13 - Princpios apoiados pelo The Twelve-Factor ou Os Doze Fatores .............................. 37
Figura 14 - Representao da tecnologia de Mquina Virtual........................................................ 38
Figura 15 - Representao da tecnologia Docker ........................................................................... 39
Figura 16 - Quadro das fases de desenvolvimento gil com microsservios ................................. 41
Figura 17 - Exemplo de arquitetura e definio de responsabilidades por camadas ...................... 43
Figura 18 - Explorador de projetos do Eclipse Java EE IDE 4.5.1................................................. 55
Figura 19 - Dashboard de monitoramento bsico de microsservios............................................. 57
Figura 20 - Interface de gerenciamento de pacientes...................................................................... 57
Figura 21 - Interface para incluso de paciente .............................................................................. 58
 LISTA DE TABELAS

Tabela 1 Bancos de dados suportados pelo Synapse ................................................................... 28

Tabela 2 Mapeamento padro de endpoint do microsservio bright-ms_cliente ........................ 56
 SUMRIO

1 INTRODUO ............................................................................................................... 10
2 FUNDAMENTAO TERICA................................................................................... 12
2.1 Microsservios.................................................................................................................... 12
2.1.1 Princpios dos Microsservios ............................................................................................ 14
2.1.2 Modelo de arquitetura web tradicional............................................................................... 14
2.1.3 Modelo de arquitetura baseada em microsservios ............................................................ 15
2.2 Aplicaes monolticas....................................................................................................... 16
2.3 REST como modelo arquitetural ........................................................................................ 17
2.4 Componentizao dos microsservios................................................................................ 18
2.4.1 Design orientado a domnio ............................................................................................... 19
2.5 Computao em Nuvem ..................................................................................................... 20
2.5.1 Uniform Resource Locator ................................................................................................. 22
2.6 Arquitetura de Software...................................................................................................... 23
2.7 Resilincia .......................................................................................................................... 23
2.8 Scrum .................................................................................................................................. 24
3 TRABALHOS RELACIONADOS ................................................................................. 25
3.1 On Micro-services Architecture ......................................................................................... 25
3.2 Synapse: A Microservices Architecture for Heterogeneous-Database Web Applications. 27
3.3 Towards a Technique for Extracting Microservices from Monolithic Enterprise Systems 29
4 PROCEDIMENTOS METODOLGICOS .................................................................... 32
4.1 Reviso bibliogrfica.......................................................................................................... 32
4.2 Estruturar logicamente os artefatos da soluo .................................................................. 32
4.3 Definir tecnologias para auxiliar a construo de microsservios ..................................... 32
4.4 Planejar a comunicao dos microsservios ...................................................................... 34
4.5 Definir mtodo para construir microsservios ................................................................... 36
4.6 Implantar os microsservios construdos ........................................................................... 37
4.7 Realizar um estudo de caso ................................................................................................ 39
5 MTODO DE DESENVOLVIMENTO COM MICROSSERVIOS............................ 40
5.1 Elicitao de requisitos....................................................................................................... 40
5.1.1 Abordagem de desenvolvimento gil de software com microsservios............................. 41
5.2 Definir funcionalidades ...................................................................................................... 42
5.3 Definir relacionamento entre as funcionalidades ............................................................... 43
5.4 Definir servios e interfaces fundamentado pelas funcionalidades.................................... 44
5.4.1 Comunicao e negociao de contedo entre clientes e servios ..................................... 44
5.4.2 Cdigos de resposta e retorno ............................................................................................ 45
5.5 Escolher tecnologia para implementao de microsservios ............................................. 45
5.5.1 Principais tecnologias de microsservios ........................................................................... 46
5.6 Definir alocao dos microsservios .................................................................................. 49
5.7 Testar microsservios ......................................................................................................... 50
5.7.1 Entrega contnua ................................................................................................................. 51
5.8 Implementao ................................................................................................................... 51
5.8.1 Implementao dos microsservios .................................................................................... 52
5.9 Monitoramento dos microsservios.................................................................................... 52
6 ESTUDO DE CASO........................................................................................................ 54
6.1 Repositrio de cdigo do estudo de caso ........................................................................... 59
7 CONCLUSO ................................................................................................................. 60
REFERNCIAS....................................................................................................................... 62
 10

1 INTRODUO

A evoluo da tecnologia da informao (TI) e a melhoria da conectividade da

internet permitiram uma revoluo na forma como as aplicaes e os servios de TI so
construdos e disponibilizados aos usurios. Nesse contexto, a computao em nuvem dispe,
a um custo acessvel, de uma infraestrutura escalvel, com qualidade de servio e altamente
disponvel. Desse modo, a forma de desenvolver software tambm tem evoludo para melhorar
a construo de software complexo e confivel de maneira modular.
Uma das maneiras de se construir um software a partir do contexto de negcios
utilizar o Domain-Driven Design ou design orientado ao domnio. necessrio entender os
problemas de negcio, bem como o funcionamento das aplicaes corporativas e planejar um
cenrio que se assemelhe ao mesmo, para que, em seguida, seja possvel desenvolver um
produto de software que atenda a estes requisitos.
Atualmente, h diversos padres comumente difundidos para o desenvolvimento
de aplicaes corporativas, visto que as fases do desenvolvimento no so atividades triviais.
A arquitetura monoltica um padro amplamente 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 so relativamente
simples (FOWLER; LEWIS, 2014). No entanto, para aplicaes grandes, complexas e muito
acopladas, a arquitetura monoltica torna-se um obstculo ao desenvolvimento e implantao,
alm de dificultar a entrega contnua e limitar a adoo de novas tecnologias. Para aplicaes
complexas, que necessitem de alta performance computacional e disponibilidade ininterrupta
mais interessante utilizar uma arquitetura de microsservios, que divide a aplicao em um
conjunto de servios leves e coesos.
O termo Microservices ou Microsservios surgiu nos ltimos anos para descrever
uma maneira particular de conceber aplicaes de software como uma sute de servios
independentemente implementveis (FOWLER; LEWIS, 2014). Embora ainda no exista uma
definio precisa deste estilo arquitetnico, pode-se elencar um conjunto de caractersticas
comuns, tais como controle descentralizado de linguagens e de dados e independncia dos
servios.
A crescente demanda por recursos descentralizados e orientados a dados em
aplicaes de software transformou esse tipo de aplicao, em muitos casos, em conglomerados
complexos de servios que operam diretamente em dados, e, em outros, em uma arquitetura
gerencivel coerente.
 11

O objetivo prevalecente de implementar um mtodo de desenvolvimento baseado

em microsservios minimizar a necessidade de re-implementao, caso ocorram mudanas,
por meio da limitao de servios devidamente coesos com os mecanismos projetados de
evoluo das interfaces de servio, envolvendo uma combinao de tecnologias em diferentes
reas da tecnologia da informao, alm de suportar o quesito multiplataforma, propendendo
interoperabilidade.
Nesse contexto, este trabalho prope um mtodo para o desenvolvimento de
software baseado em microsservios. Este mtodo fornece um conjunto de passos para a
construo de software utilizando microsservios. Para avaliar este mtodo foi realizado um
estudo de caso envolvendo o desenvolvimento de um software baseado em microsservios para
suplementar o tratamento medicinal com aplicao de fototerapia.
Nesta proposta de pesquisa, o objetivo geral propor e validar um mtodo para o
desenvolvimento de software baseado em microsservios. A partir deste objetivo mais geral,
foram elencados como objetivos especficos: (i) identificar modelos de desenvolvimento
existentes baseados em microsservios; (ii) identificar caractersticas e funcionalidades
fundamentais em sistemas baseados em microsservios; (iii) definir um mtodo para o
desenvolvimento de software baseado em microsservios; e (iv) realizar um estudo de caso
utilizando o mtodo proposto.
No prximo captulo apresentada a fundamentao terica relacionada e como as
abordagens influem, em carter prtico, neste trabalho de concluso de curso.
 12

2 FUNDAMENTAO TERICA

A seguir so apresentados os conceitos-chave adotados neste trabalho. Nas trs

primeiras subsees so explanados os conceitos de microsservios e, posteriormente, seus
princpios, os modelos arquiteturais tradicionais e baseados em microsservios, a utilizao do
REST como modelo arquitetural, a componentizao dos microsservios, o design orientado a
domnio e computao em nuvem, respectivamente. Na subseo seguinte introduzido o
conceito de arquitetura de software, aplicaes monolticas e resilincia, bem como so tecidas
algumas consideraes sobre o processo de desenvolvimento de software baseado em
microsservios.

2.1 Microsservios

Newman (2015) explica sobre servios autnomos que trabalham juntos e que, nos
ltimos dez anos, os sistemas distribudos se tornaram mais refinados, evoluindo de aplicaes
monolticas de cdigo pesado para microsservios independentes.
O termo microsservios, ou microservices, definido por Thnes (2015) como um
aplicativo que pode ser implantado, dimensionado e testado de maneira independente, seguindo
o princpio da responsabilidade nica. O intuito da responsabilidade nica que o aplicativo
desenvolvido deve ser planejado para realizar apenas um conjunto mnimo vivel de tarefas,
sendo facilmente compreendido, modificvel e substituvel.
O princpio da responsabilidade nica, ou SOLID, baseia-se em requisitos
funcionais, no funcionais, ou, como o autor aborda, em requisitos multifuncionais. Um
exemplo de funcionamento de um microsservio pode ser um processador estar lendo
mensagens de uma fila na memria enquanto realiza uma pequena parte da lgica de negcios,
podendo variar de algo funcional a no funcional com a responsabilidade nica de servir a um
determinado recurso em particular.
Os microsservios devem ser focados, pequenos e executarem uma nica tarefa por
conta prpria, decompondo funcionalmente a aplicao em um conjunto colaborativo de
servios, em que cada servio implementa um conjunto de funes relacionadas de maneira
bem restrita, para implementar as regras de negcio. O estilo arquitetnico baseado em
microsservios uma abordagem para o desenvolvimento de uma aplicao nica, baseada em
um conjunto de microsservios, cada um executando em seu prprio processo e se comunicando
 13

por meio de um mecanismo leve, muitas vezes, uma API de recursos HTTP (FOWLER;
LEWIS, 2014).
Os servios so construdos em torno das regras de negcio da organizao e so
independentemente implementveis por mquinas totalmente automatizadas. Contudo, o
gerenciamento pode ser centralizado e escrito por meio de linguagens de programao
diferentes e com diferentes mecanismos de persistncia de dados.
Observando-se a Figura 1, a Interface do lado do cliente consiste em pginas
desenvolvidas com tecnologia HTML, Javascript e CSS, em execuo atravs de um navegador
na mquina do usurio. A aplicao do lado servidor lida com as solicitaes HTTP, executa a
lgica de negcio do domnio, recupera e atualiza os dados na base de dados, seleciona e
disponibiliza as vises HTML enviadas ao browser e geralmente, possui um SGBD relacional.

Figura 1 - Estilo arquitetnico bsico baseado em microsservios

Fonte: Elaborado pelo autor.

Para Fowler e Lewis (2014), o termo microsservios surgiu nos ltimos anos para
descrever uma maneira peculiar de desenvolver aplicaes de software independentemente
implementveis, como uma sute de servios, embora este estilo de desenvolvimento ainda no
seja precisamente definido. Com os servios independentemente implementveis e escalveis,
possvel desenvolv-los em diferentes linguagens de programao e tambm mant-los e
gerenci-los por equipes distintas.
Outro fator abordado por Fowler e Lewis a componentizao via servios, que
trata os componentes como uma unidade de software autnoma, substituvel e atualizvel. Uma
aplicao baseada em microsservios pode utilizar bibliotecas, mas o intuito principal
modularizar o software em servios independentes. Para os autores, bibliotecas so
componentes que esto ligados a um determinado programa e que so chamados utilizando-se
funes, enquanto os servios esto completamente fora do processo de componentizao e se
comunicam atravs de um mecanismo de solicitao de servio ou chamada a um procedimento
remoto.
O objetivo prevalecente de implementar um mtodo de desenvolvimento baseado
em microsservios minimizar a necessidade de re-implementao, caso ocorram mudanas,
 14

por meio da limitao de servios devidamente coesos com os mecanismos projetados para
evoluo das interfaces do servio.

2.1.1 Princpios dos Microsservios

Newman (2015) elenca os princpios e objetivos estratgicos junto s prticas de

design e delivery para o desenvolvimento de software baseado em microsservios, defendendo
a construo de servios autnomos pequenos que trabalham em conjunto. Os princpios dos
microsservios so:
A modelagem deve estar focada no domnio de negcio.
Utilizar a cultura da automao.
Abstrair os detalhes da implementao.
Descentralizar todas as coisas.
Isolar as falhas.
Deploy independente.
Os princpios abordados acima visam, segundo Newman (2015), reduzir a inrcia,
fazendo escolhas que favoream o feedback e mudanas rpidas, reduzindo as dependncias
entre as equipes. Para eliminar a complexidade acidental deve-se substituir os processos
complexos, desnecessrios e principalmente as integraes tambm demasiadamente
complexas com o propsito de privilegiar o desenvolvimento.

2.1.2 Modelo de arquitetura web tradicional

primeira vista, o contexto de uma aplicao web tradicional possui algumas

vantagens em relao ao contexto baseado em microsservios, como por exemplo nas fases de
desenvolvimento e testes, em que as atuais ferramentas de desenvolvimento, comumente
tituladas no setor de TI como IDE's ou Integrated Development Environment, oferecem apoio
tanto ao desenvolvimento quanto ao trabalho em equipe do grupo de desenvolvedores. A
facilidade de instalao, no caso de uma aplicao utilizando a tecnologia Java, aparentemente
tambm mais atrativa, visto que necessria apenas a implantao de um arquivo WAR no
continer web, por exemplo. Com isso, obtm-se simplicidade de escala seguindo o modelo
citado, tornando possvel replicar a aplicao executando vrias cpias do aplicativo,
 15

orquestradas por um balanceador de carga responsvel por receber e direcionar as requisies

oriundas dos clientes.

Figura 2 - Arquitetura tradicional de uma aplicao web

Fonte: Microservices architecture (2015).

Na Figura 2, apresentada uma arquitetura tradicional de uma aplicao monoltica

web, desenvolvida utilizando a tecnologia Java. A aplicao consiste em um nico arquivo
WAR, que pode ser implantado em um continer web, como neste exemplo do Apache Tomcat , 1_

um servidor de cdigo fonte aberto responsvel pelo processamento das tecnologias Java
Servlet e JavaServer Pages, que pode ser executado por diversas instncias conectadas a um
balanceador de carga, a fim de ampliar a disponibilidade da aplicao.

2.1.3 Modelo de arquitetura baseada em microsservios

No contexto de microsservios, as vantagens apresentadas na sesso anterior

utilizando-se o modelo de arquitetura web tradicional so abordadas como uma srie de
inconvenientes. A grande base de cdigo monoltico intimida os desenvolvedores devido
dificuldade de compreenso e modificabilidade do cdigo fonte da aplicao como um todo. O
IDE, devido maior base de cdigo, fica sobrecarregado. A dificuldade de escala eficiente
visvel, visto que s pode ocorrer em uma dimenso tal que a arquitetura no pode vir a ser

1
http://tomcat.apache.org
 16

dimensionada com o volume crescente de dados e principalmente no possvel dimensionar

cada componente de maneira independente.

Figura 3 - Aplicao utilizando arquitetura baseada em microsservios

Fonte: Microservices architecture (2015).

A Figura 3 mostra uma aplicao que consiste em vrios componentes que

implementam a interface com o usurio como um conjunto de servios. Cada servio pode ser
implantado de maneira independente dos demais servios, tornando mais simples a adio de
novas funcionalidades com maior frequncia. E como os servios so independentes o
isolamento a falhas aumenta, pois o comportamento inadequado compreende somente o servio
afetado.

2.2 Aplicaes monolticas

Aplicaes monolticas so sistemas de software desenvolvidos com variados

componentes e funcionalidades agrupados dentro de um grande sistema, fazendo desta uma
aplicao projetada e construda em uma nica unidade de software.
Em definio tcnica, uma aplicao com abordagem de desenvolvimento
monoltica possui diversos mdulos em uma base de cdigo unificada. Estes mdulos so
divididos entre funcionalidades tcnicas e regras de negcio, e para sua execuo
frequentemente efetuada uma compilao nica para se construir a aplicao na ntegra,
gerando assim um nico binrio executvel ou implementvel.
 17

Em Monolithic Design, pela Cunningham & Cunningham (2014), so elencadas as

seguintes dificuldades enfrentadas com o crescimento de aplicaes monolticas.
A grande base de cdigo monoltico torna o entendimento complexo.
Dimensionamento da aplicao torna-se um desafio.
Integrao contnua e implantao tornam-se complexas e extensas.
Sobrecarga da IDE em virtude da grande base de cdigo.
Com os obstculos pautados pela Cunningham & Cunningham (2014) durante o
desenvolvimento crescente de uma aplicao monoltica, notam-se as dificuldades de transio
de tecnologias, linguagem de programao ou frameworks em consequncia da estrutura da
aplicao estar intimamente interligada e dependente.

2.3 REST como modelo arquitetural

Criar e manter sistemas distribudos naturalmente aparenta ser uma atividade

complexa, pois envolve o desenvolvimento de artefatos que atendam desde os requisitos de
negcio at os requisitos da aplicao, como o gerenciamento das transaes distribudas e os
protocolos de comunicao, que sero elucidados posteriormente na sesso 4.4 a respeito da
comunicao dos microsservios.
A utilizao de boas prticas de desenvolvimento tende a reduzir o tempo
necessrio para se construir um sistema como um todo; no sentido de desenvolver uma
aplicao com processamento distribudo e interconectado, o REST (Representational State
Transfer) pode ser utilizado como um modelo arquitetural capaz de atender aos requisitos
complexos, sem agregar complexidade e com alto nvel de acoplamento na integrao dos
microsservios, mesmo que estrategicamente os modelos de domnio sejam projetados para
uma arquitetura neutra.
Fielding (2000) defende a utilizao do REST para interligar sistemas
essencialmente heterogneos, sendo possvel realizar a troca de mensagens e informaes
mantendo a semntica dos dados entre os dispositivos envolvidos, e ainda garantir a segurana,
integridade e consistncia nos dados distribudos.
Vernon (2013), por demasiada nfase na arquitetura, defende um modelo chamado
de Hexagonal, que pode ser utilizado para facilitar a compreenso e o desenvolvimento do
modelo REST e orientao a eventos, focando na importncia de elaborar cuidadosamente um
 18

modelo baseado em DDD ou Domain Driven Design, conceito melhor explicitado

posteriormente na sesso 2.4.1 Design orientado a domnio.
A Figura 4, em seguida, descreve uma abstrao de arquitetura hexagonal,
definindo o modelo de domnio como o centro do software, com sua interface bem definida e
projetada para o consumo dos servios por clientes distintos, relativamente simples de se
empregar e essencialmente focada no modelo de domnio.

Figura 4 - Abstrao da arquitetura hexagonal

Fonte: VERNON (2013).

2.4 Componentizao dos microsservios

Tradicionalmente, um componente uma unidade de software independente que

pode ser representada como substituvel e atualizvel. Bibliotecas de software usualmente so
componentes que esto diretamente ligados a um programa. No caso dos servios, estes so
componentes fora do processo, e, para sua comunicao, deve-se utilizar chamadas de
procedimentos remotos, por esta razo servios independentes devem ser considerados
componentes em vez de bibliotecas ou outras classificaes.
O planejamento prvio para se projetar e construir as interfaces de servios em
desenvolvimento uma vantagem desta abordagem, visto que qualquer desenvolvimento sem
o planejamento adequado da componentizao tende a resultar em um cdigo no sustentvel.
 19

Salientando a componentizao dos microsservios, segundo Namiot e Sneps-

Sneppe (2014), deve-se utilizar as seguintes premissas para o desenvolvimento preciso de
sistemas baseados em microsservios:
Chamadas/Respostas devem utilizar dados arbitrariamente estruturados.
Eventos assncronos devem fluir em tempo real e em ambas direes.
Pedidos e respostas podem fluir em qualquer direo.
Pedidos e respostas podem ser arbitrariamente aninhados.
O formato de serializao de mensagem deve ser conectvel (JSON, XML).

2.4.1 Design orientado a domnio

Evans (2015) ajuda a entender a importncia de se representar as caractersticas do

mundo real em cdigo, visto que o Domain Design Driven ou DDD um tema amplo e que
contm detalhes de difcil incorporao em uma base de cdigo. Sendo assim, deve-se
considerar os conceitos em que a lgica de negcio ou partes do domnio geralmente possam
ficar escondidas. O intuito do DDD est em escrever um cdigo menos acoplado e mais coeso,
e, como consequncia, facilitar sua compreenso mesmo em situaes de grande escala.
Segundo Vernon (2013), no DDD o foco est na lgica de negcios e no domnio.
Isso leva a desenvolver maneiras melhores e mais estruturadas de comunicao e interao
entre mquinas.
Com a constante evoluo dos recursos computacionais a compreenso das
plataformas de virtualizao permite dispor e redimensionar mquinas segundo uma
necessidade especfica, com uma infraestrutura que disponibiliza diversas maneiras de lidar
com os problemas de grande escala.
Abordando o DDD no contexto da responsabilidade nica e arquitetura limpa,
Martin (2003) define responsabilidade como uma razo e eixo para mudana. Quando se possui
uma classe, e possvel pensar em mais de um motivo para se realizar uma mudana, ento
bem provavelmente essa mesma classe possuir mais de uma responsabilidade. Quando um
requisito tende a mudar, essa mudana se manifesta principalmente atravs da alterao da
responsabilidade entre classes, desse modo, se uma classe assume mais de uma
responsabilidade haver mais de uma razo para que ela mude. Segundo Martin (2003),
desenvolvedores se habituam a pensar em responsabilidades em grupos.
 20

Figura 5 - Ilustrao do modelo de camadas em intercomunicao

2
Fonte: Modelo tradicional de diviso de software por camadas

Na Figura 5, a camada Interfaces apresenta e interpreta os comandos oriundos do

usurio, a camada Application coordena as atividades da aplicao no contendo as lgicas de
negcio, a camada Domain contm as informaes principais do domnio e a camada
Infrastructure suporta as demais camadas, assegura a comunicao entre elas e ainda
implementa a persistncia.

2.5 Computao em Nuvem

O conceito de computao em nuvem se refere utilizao de computadores

compartilhados e interligados por meio da internet. Segundo Marinescu (2013), a computao
em nuvem um movimento iniciado nas primeiras dcadas do novo milnio, sendo motivado
pela ideia de que o processamento de informaes pode ser feito de forma mais eficiente em
grandes centros de sistemas de computao e armazenamento acessveis atravs da internet.
Para Marinescu (2013), a computao em nuvem uma evoluo do paradigma da
computao local, em que aplicaes cientficas, minerao de dados, jogos, redes sociais,
dentre outras inmeras atividades computacionais que fazem o uso intensivo de dados so
visivelmente beneficiadas pelo armazenamento de informaes na nuvem.
A computao em nuvem deve oferecer servios de computao e armazenamento
escalveis e estticos de maneira transparente para o usurio final, e a utilizao dos recursos

2
http://dddsample.sourceforge.net/architecture.html
 21

pode ser facilmente medida. Os recursos de TI so fornecidos como um servio, permitindo ao

usurio final consumi-los sem a necessidade de conhecimento sobre a tecnologia utilizada.
Marinescu (2013) ainda esclarece que na computao em nuvem a operao mais
eficiente e o aumento de confiabilidade e segurana tambm maior, baseando-se na
multiplexao de recursos e principalmente devido economia em escala, configurando-se
como uma realidade tcnica e social dos dias atuais, e, ao mesmo tempo, uma tecnologia
emergente.
Pode-se utilizar os trs tipos de classificao como expostos na Figura 6, ou seja,
papeis na computao em nuvem para facilitar o entendimento da tecnologia:
SaaS: Software as a Service ou Software como servio.
O modelo de SaaS proporciona sistemas de software com propsitos especficos,
que esto disponveis para o usurio atravs da internet. Os sistemas so acessveis
a partir dos vrios dispositivos do usurio.
PaaS: Plataform as a Service ou Plataforma como servio.
O PaaS oferece uma infraestrutura de alto nvel de integrao para implementar e
testar aplicaes na nuvem. O usurio no administra ou controla a infraestrutura,
mas tem controle sobre as aplicaes implantadas.
IaaS: Infrastructure as a Service ou Infraestrutura como servio.
A Infraestrutura como servio a parte responsvel por prover toda infraestrutura
para o PaaS e SaaS, com o objetivo principal de tornar mais acessvel o fornecimento
de recursos de computao fundamentais para se construir um ambiente sob
demanda. O termo IaaS se refere a uma infraestrutura computacional baseada em
tcnicas de virtualizao de recursos de computao.
 22

Figura 6 - Papis na computao em nuvem

Fonte: SOUSA, MOREIRA, MACHADO (2009).

A computao em nuvem refora a ideia de que a computao e a comunicao

esto fortemente entrelaadas. Uma das desvantagens da computao em nuvem no contexto
de microsservios em ambientes de redes locais que ela pode no emergir como uma possvel
alternativa aos paradigmas tradicionais para aplicaes com intensivo acesso a dados por meio
da internet em que os principais gargalos so largura de banda, latncia e custo de comunicao.

2.5.1 Uniform Resource Locator

A URL ou Uniform Resource Locator refere-se ao endereo de rede onde se

encontra algum recurso computacional. Conforme Berners-Lee et al. (1998, p. 1, destaques do
autor) essa rede pode ser desde a internet como qualquer rede computacional corporativa:

The specification is derived from concepts introduced by the World Wide

Web global information initiative, whose use of such objects dates from 1990
and is described in "Universal Resource Identifiers in WWW", RFC 1630.
The specification of URLs is designed to meet the requirements laid out in
"Functional Requirements for Internet Resource Locators"

utilizando o endereo URL que se obtm acesso aos recursos projetados e

disponibilizados pelo microsservios por intermdio de uma API.
 23

2.6 Arquitetura de Software

O Working Group on Architecture (1998) da IEEE define arquitetura como o

conceito de nvel mais alto de um sistema em seu ambiente. Este padro proposto pelo grupo
recomenda uma descrio da arquitetura com base no conceito de mltiplas vises. A finalidade
das mltiplas vises neste cenrio apoiar a compreenso do software utilizando o vasto
conjunto de tipos de dados e auxiliar na anlise do desempenho da comunicao utilizada
atravs da rede de computadores interligados.
Apesar da dificuldade em definir arquitetura de software com preciso esta se
configura como um aspecto do design de software que se concentra na adequao e integridade
do sistema e nas preocupaes estticas, levando em considerao o sistema como um todo no
ambiente de desenvolvimento e do usurio, organizando e estruturando os componentes
significativos do sistema.
Garlan e Shaw (1993) sugerem que a arquitetura de software um nvel de design
voltado para questes que vo alm dos algoritmos e das estruturas de dados da computao. A
projeo e a especificao da estrutura geral de um sistema emergem como um novo tipo de
problema e as questes estruturais incluem organizao total, estruturas de controle globais,
protocolos de comunicao, sincronizao e acesso a dados, atribuies de funcionalidades a
elementos de design, distribuio fsica, escalonamento e desempenho.
A arquitetura de software resultado do fluxo de trabalho no desenvolvimento de
software, estando em constante desenvolvimento, refinamento e aprimoramento.

2.7 Resilincia

Segundo Newman (2015), o conceito principal de engenharia de resilincia o

bulkhead ou resguardo. Se algum componente do sistema falhar possvel isolar o problema e
os demais sistemas ainda continuam operacionais. Em um sistema monoltico, se algum dos
servios falhar o sistema em sua completude interrompido, j em um sistema monoltico que
pode ser executado em vrias mquinas pode-se reduzir a chance de falhas, no entanto, com os
microsservios pode-se construir sistemas que lidem com o fracasso total dos servios, sem
degrader as funcionalidades em conformidade com os requisitos.
 24

2.8 Scrum

O Scrum uma metodologia gil e um framework para desenvolvimento iterativo

e incremental com foco na gesto e planejamento de projetos de software. Os projetos no Scrum
so divididos em ciclos e so nomeados de Sprint, sendo que elas representam um conjunto de
atividades a serem executadas. Alm disso o Scrum um conjunto de princpios e prticas que
fornece uma base para que se utilize praticas de engenharia de software relevantes para as
atividades de construo de sistemas.
 25

3 TRABALHOS RELACIONADOS

Esta seo descreve os trabalhos relacionados que se instituem como incito e

referncia para o enriquecimento desta proposta.

3.1 On Micro-services Architecture

Namiot e Sneps-Sneppe (2014) descrevem a implementao e a viso geral de uma

arquitetura baseada em microsservios, abordando o fato de que o desenvolvimento deve tornar
os servios leves, independentes e executores de funes simples colaborando entre si por meio
de interfaces bem definidas. Foram identificados os princpios comuns utilizando-se esta
abordagem, sendo possvel avaliar as vantagens e desvantagens do uso da arquitetura de
microsservios e como foi a transio natural do desenvolvimento de aplicaes utilizando o
framework Machine to Machine (M2M), considerado parte integral do conceito da internet das
coisas ou Internet of Things (IoT).
Esse trabalho tambm apresenta algumas limitaes do uso dos microsservios. Os
autores supracitados destacam que na prtica esta abordagem possui seu prprio conjunto de
inconvenientes, tais como a complexidade adicional para se planejar e criar sistemas
distribudos, tornando os testes de software mais complexos e dificultando principalmente a
implementao do mecanismo de comunicao interservios e de transaes distribudas.
Alm disso, os microsservios contribuem para o aumento do consumo de
memria, devido aos independentes espaos de memria alocados para cada um dos servios.
Outro desafio citado como dividir ou particionar o sistema em microsservios. Uma
abordagem planejada pelos autores foi particionar os servios em casos de uso, que sero
exemplificados posteriormente na Figura 8, seguindo os princpios definidos pelo M2M ETSI,
mostrado a seguir na Figura 7.
Na Figura 7, o conceito Machine to Machine, ou mquina mquina, refere-se
tecnologia que permite que sistemas se comuniquem com outros sistemas ou dispositivos que
tambm possuam a mesma habilidade. A comunicao se d originalmente atravs de uma rede
de comunicao, assim, as informaes so transmitidas e analisadas por uma tecnologia
centralizadora e, posteriormente, podem ser roteadas para um sistema computacional.
 26

Figura 7 - Modelo European Telecommunications Standards Institute M2M

Fonte: ETSI M2M (2014).

Outra estratgia o particionamento por verbos e substantivos, exemplificado na

Figura 8, em que servios poderiam implementar subsistemas como por exemplo login e
backup, enquanto o particionamento por substantivos trataria como recursos os servios
responsveis por operarem em entidades de determinados tipos. O ideal que cada servio
possua um pequeno conjunto de responsabilidades e siga o padro Single Responsibility
Principle ou Princpio da Responsabilidade nica.
 27

Figura 8 - FI-WARE data model, particionado em verbos e substantivos

Fonte: Elmangoush at al. (2013).

De forma semelhante, a abordagem proposta neste trabalho de concluso de curso

tambm utiliza uma prtica de desenvolvimento focada em sistemas distribudos com o
emprego de testes unitrios e um conceito de Continer, posteriormente explanado na sesso
especfica 4.6 para escalar os microsservios da aplicao, alm de tambm implementar um
mecanismo de comunicao de interservios e utilizar a abordagem de particionamento em
verbos para extrair funcionalidades com responsabilidades especficas impostas por limites
explcitos.

3.2 Synapse: A Microservices Architecture for Heterogeneous-Database Web

Applications

Viennot et al. (2015) apresentam o Synapse, um sistema de cdigo fonte aberto,

fortemente semntico, baseado em uma abordagem de integrao e replicao de servios web
orientado a dados para grande escala. Este um sistema de replicao cross-DB que simplifica
o desenvolvimento e evoluo de aplicaes web baseadas em dados. Os microsservios so
independentes e compartilham dados entre si de maneira isolada e escalvel, atuando sobre os
mesmos dados, desse modo, cada servio executado com sua prpria base de dados; os SGBD
ou Sistema Gerenciador de Banco de Dados pode ser distinto, porm, incorpora as vises
 28

compartilhadas entre servios. Isso permite que os bancos de dados operem em diferentes
esquemas, com motores distintos.
O sistema sincroniza em tempo real os subconjuntos de dados de maneira
transparente, utilizando um mecanismo de replicao consistente e escalvel, aproveitando os
modelos de dados de alto nvel e estendendo a arquitetura MVC, em que os desenvolvedores
separam logicamente os modelos da aplicao web para realizarem a replicao entre os bancos
de dados heterogneos por meio da distribuio horizontal dos dados. Os controladores definem
as unidades bsicas em que os dados so lidos, manipulados e escritos, implementando a lgica
de negcios e agindo sobre os dados. Atravs da API possvel especificar quais os dados sero
compartilhados entre os servios, alm disso, os modelos so expressos por objetos de alto
nvel, mapeados automaticamente via ORM ou Object-relational mapping.
O Synapse foi desenvolvido utilizando o framework Ruby on Rails, suportando
replicao e propagao de dados entre uma ampla variedade de sistemas de gerenciamento de
banco de dados com suporte na linguagem de consulta estruturada ou Structured Query
Language (SQL) e NoSQL, incluindo MySQL, PostgreSQL, Oracle, MongoDB, Cassandra,
entre outros, como pode ser visto na Tabela 1.

Tabela 1 Bancos de dados suportados pelo Synapse

Type Supported vendors Example use cases
Relational PostgreSQL, MySQL, Oracle Highly structured content
Document MongoDB, TokuMX, RethinkDB General purpose
Columnar Cassandra Write-intensive workloads
Search Elasticsearch Aggregations and analytics
Graph Neo4j Social network modelink
Fonte: VIENNOT et al. (2015).

Nele foi implementado um conjunto de microsservios que serviro como

referncia em tecnologia de desenvolvimento e linguagem de programao para a base do
mtodo proposto neste trabalho e aplicao no estudo de caso de desenvolvimento do software
de dosagem para o tratamento com aplicao de fototerapia. O Synapse est atualmente
executando em produo para mais de 450.000 usurios, por mais de dois anos. Ele simplifica
a construo e evoluo de aplicaes web orientadas a dados complexos, proporcionando um
alto nvel de agilidade, crucial para aplicaes que utilizam grandes fontes de dados em
expanso.
 29

De maneira semelhante, este projeto de pesquisa estende a arquitetura MVC para o

desenvolvimento em camadas dos microsservios, e, caso necessrio, cada servio dispe de
um mecanismo de persistncia que melhor se adapta ao modelo de dados que este gerencia e
compartilha atravs de uma API de alto nvel.

3.3 Towards a Technique for Extracting Microservices from Monolithic Enterprise

Systems

Levcovitz et al. (2015) propem uma tcnica para extrao de microsservios a

partir de sistemas monolticos, seguindo o conceito de construo de uma aplicao complexa
como um conjunto de servios pequenos, coesos e independentes. Esta tcnica auxilia na
identificao e definio dos microsservios tendo como base um sistema monoltico,
identificando assim bons candidatos para serem transformados em microsservios, reduzindo o
tamanho do sistema original e transportando os benefcios da arquitetura de microsservios.
Segundo Richardson (2014), sistemas monolticos ficam maiores ao longo do
tempo, desviando-se da arquitetura projetada, tornando sua evoluo complexa, arriscada e de
custo elevado.
Nesse artigo de Levcovitz et al. (2015), foi aplicada a tcnica de extrao de
microsservios em um sistema monoltico bancrio de 750 KLOC, ou seja, 750 mil linhas de
cdigo, que gerencia 3,5 milhes de contas bancrias, realizando quase 2 milhes de
autorizaes por dia e se mostra uma alternativa promissora para modernizao empresarial
tendo como base sistemas monolticos legados.
A tcnica considera que aplicaes monolticas possuem 3 partes principais,
posteriormente aprofundadas na sesso 2.1 Microsservios:
Interface de usurio do lado do cliente.
Um aplicativo do lado do servidor.
Um banco de dados.
Como detalhado na Figura 9, em seguida, considerado que o sistema como um
todo est estruturado em subsistemas menores e cada subsistema possui um conjunto bem
definido de responsabilidades.
 30

Figura 9 - Aplicao monoltica

Fonte: Levcovitz et al. (2015)

Em termos formais, assume-se que o sistema S representado por uma tripla (F, B,
D), onde F = {fc1, fc2, ..., fcn} um conjunto de fachadas, B = {bf1, bf2, ..., bfn} um conjunto
de funes de negcio, e D = {tb1, tb2, ..., tbn} um conjunto de tabelas do banco de dados.
As fachadas (fci) so pontos de entrada que invocam funes de negcio (bfi), as funes de
negcio so mtodos que codificam as regras de negcio e dependem das tabelas do banco de
dados (tbi). Tambm importante definir uma unidade organizacional O = {a1, a2, ..., an}
dividida em reas responsveis pelos processos de negcio.
A tcnica para identificar microsservios em um sistema S consiste em 6 etapas,
sintetizadas a seguir.
Etapa #1: Mapear as tabelas do banco de dados tbi D em subsistemas ssi SS.
Cada subsistema representa uma rea de negcio (ai) da organizao.
Etapa #2: Criar um grfico de dependncia (V, E), onde os vrtices representam
fachadas (fci F), funes de negcio (bfi B), ou tabelas do banco de dados (tbi D), e as
arestas podem representar: chamadas das fachadas para funes de negcio, chamadas entre
funes de negcio e acesso entre funes de negcio para tabelas do banco de dados.
Etapa #3: Identificar pares (fci, tbj), onde fci F e tbj D, no havendo caminho a
partir de fci para tbj no grfico de dependncias.
 31

Etapa #4: Para cada subsistema ssi previamente definido no Passo #1, selecione
pares (fci, tbj) identificados na etapa anterior, onde tbj ssi.
Etapa #5: Identificar candidatos a serem transformados em microsservios. Para
cada par distinto (fci, tbj) obtido na etapa anterior deve-se inspecionar os cdigos da fachada e
das funes de negcio no caminho do vrtice fci para tbi no grfico de dependncias. Essa
estratgia tem como objetivo identificar quais regras de negcio realmente dependem das
tabelas do banco de dados e as operaes devem ser descritas em forma de regras, com
objetivos, entrada/sada, funcionalidades e dados.
Etapa #6: Criar a API para transformar a migrao dos microsservios transparentes
para os clientes. A API consiste em uma camada intermediria entre cliente e servidor,
utilizando as mesmas tecnologias e interface como fci, que lida com as solicitaes do lado do
cliente, sincroniza chamadas para o novo microsservio M e fci, uma nova verso de fci sem o
cdigo extrado e implementado no microsservio. Para cada fachada deve ser definida uma
API.
Traando um paralelo com este trabalho de concluso de curso, este mtodo
contribui viavelmente para avaliar sistemas, identificar e descrever microsservios, inclusive
diferenciar subsistemas que no so bons candidatos para migrar para o desenvolvimento
baseado em microsservios, alm de auxiliar na identificao de cenrios e isolamento de
fragmentos que requerem um esforo adicional para migrar subsistemas para um conjunto de
microsservios.
O prximo captulo descreve os conceitos, decises e abordagens, relacionados por
meio dos procedimentos metodolgicos, que compreendem a elaborao deste projeto de
pesquisa.
 32

4 PROCEDIMENTOS METODOLGICOS

Primeiramente, realizou-se uma reviso bibliogrfica para identificao dos

modelos de desenvolvimento baseados em microsservios existentes. Identificou-se as
caractersticas e os princpios utilizados para o desenvolvimento de software baseado em
microsservios e estudou-se ferramentas e tecnologias como suporte ao desenvolvimento
baseado em microsservios. Com esses conhecimentos, props-se um mtodo de
desenvolvimento de software no contexto de microsservios e, por fim, realizou-se um estudo
de caso utilizando o mtodo proposto.

4.1 Reviso bibliogrfica

Este trabalho de concluso de curso se iniciou com a fase de reviso bibliogrfica,

cujo foco foi o desenvolvimento de competncias sobre os seguintes temas:
Microsservios.
Computao em Nuvem.
Virtualizao.

4.2 Estruturar logicamente os artefatos da soluo

O planejamento e a definio hierrquica da rvore de diretrios da soluo tm

como intuito facilitar a organizao lgica dos artefatos gerados antes, durante e aps os
processos que permeiam o desenvolvimento e a entrega do software, enfocando como objetivo
principal a separao de interesses e a abstrao da alocao de espao fsico pelo computador.
O sistema de arquivos a estrutura lgica utilizada pelo sistema operacional que ser a base
para modularizao dos microsservios desenvolvidos.

4.3 Definir tecnologias para auxiliar a construo de microsservios

Com a constante evoluo dos recursos computacionais, a compreenso das

plataformas de virtualizao e tecnologias de continer permite dispor e redimensionar recursos
fsicos e lgicos segundo a necessidade, atravs de uma infraestrutura que disponibilize diversas
maneiras de lidar com o problema da escalabilidade e distribuio de recursos computacionais.
 33

A seguir, apresentada uma comparao visual entre as tecnologias de continer e

mquinas virtuais, separando em cores os recursos distintos, porm, dedicados aplicao,
sistema operacional e hardware ou computador, comumente presentes em tais tecnologias.

Figura 10 - Tecnologia de virtualizao tradicional e continer

Fonte: VMware buys into Docker containers, diferenas entre virtualizao e continer

Como pde ser visto na Figura 10, as diferenas entre as tecnologias tradicionais
de mquina virtual ou virtual machine (VM), virtualizao e paravirtualizao para continer,
so aparentes, sendo que na VM, alm das aplicaes e dependncias, necessria a execuo
de um sistema operacional (SO) completo, enquanto o continer compreende apenas os
aplicativos e suas dependncias para executar o software em completude.
As mquinas virtuais padronizadas so capazes de dividir e distribuir recursos
computacionais de maneira vivel, sem depender do kernel do sistema operacional e at
utilizando hardware separado. Porm, executar um SO separadamente para obter recursos e
isolar a segurana, desconsiderando a inicializao lenta devido espera pelo prprio SO, leva
a um desperdcio de recursos imprescindveis para a execuo da aplicao, com o consumo
maior, geralmente por parte do SO de memria de acesso aleatrio (RAM) e disco rgido (HD),
do que o expectvel para as prprias aplicaes hospedadas.
A Figura 11, a seguir, mostra a comparao em tempo na escala de milissegundos,
com base no progresso arquitetural, entre o desacoplamento do provisionamento para a
 34

implantao de hardware por parte de uma mquina virtual e o desacoplamento do

provisionamento do sistema operacional e inicializao (boot) utilizando uma tecnologia de
continer. O Bare Metal tambm uma forma de virtualizao de mais baixo nvel, conhecida
como Tipo 1, em que o sistema operacional se comunica diretamente com o hardware.

Figura 11 - Provisionamento das tecnologias de VM tradicionais e contineres

3
Fonte: Melhoria no provisionamento de recursos

4.4 Planejar a comunicao dos microsservios

Uma anlise cuidadosa de como os clientes se comunicam com os servios de

extrema relevncia. Em um sistema baseado em microsservios uma considerao importante
no projeto est na comunicao do cliente com os microsservios, desse modo, como os
servios devem ser processos independentes e pequenos, considerar e planejar as possibilidades
especficas de como os clientes devero se comunicar deve ser uma tarefa crucial e prioritria.
Uma abordagem a se adotar permitir que os clientes se comuniquem apenas com
um servio nomeado de API Gateway, que atua como um receptor agregador de diferentes
servios, com o propsito de receber as solicitaes por parte dos clientes.
No diagrama apresentado na Figura 12, um API Gateway posicionado entre as
aplicaes do cliente e os microsservios, oferecendo uma API adaptada e fortemente semntica
aos diferentes tipos de aplicaes que iro consumi-la.

3
http://www.linuxjournal.com/content/containersnot-virtual-machinesare-future-cloud?page=0,1
 35

Figura 12 - Uma abordagem para comunicao dos microsservios

4
Fonte: Abordagem para comunicao centralizada dos microsservios

Para facilitar o entendimento da comunicao entre microsservios necessrio

entender a diferena entre sistemas baseados em processos e eventos. Compreender esse
propsito nos permite preconceber a metodologia que mais se adequa construo de um
sistema baseado em microsservios.
Segundo Balla (2014), nos sistemas fundamentados em processos, um nico
processo dedicado a servir a uma nica solicitao. Caso a solicitao seja sobre a obteno
de alguns dados de um armazenamento permanente, ou outro servio, o processo ser
bloqueado espera da operao de entrada para ser concludo. Em sistemas baseados em
eventos, h um nico processo, sendo que os eventos podem ser processados em threads
distintas para servir a um grande nmero de pedidos, no bloqueando as operaes de entrada.
A seguir so elencadas as caractersticas bsicas principais, citadas por Balla
(2014), de sistemas baseados em processos e em eventos.
Sistemas baseados em Processos:
o Processo simples / Threads por pedido.
o I/O bloqueante.
o Conjunto encadeado de processos.

4
http://www.developer.com/open/building-microservices-with-open-source-technologies.html
 36

Sistemas baseados em Eventos:

o Processo nico para grande nmero de pedidos.
o I/O no bloqueante.
o Usa um processo por Core em sistemas escalveis.
Entender o propsito e suas diferenas permite adotar o estilo correto para planejar
a comunicao dos microsservios. Balla (2014) auxilia a metodologia e proposta de
desenvolvimento esclarecendo que um sistema baseado em processos a opo ideal quando
se possui um alto poder computacional, j um sistema baseado em eventos ideal para a
utilizao intensiva de recursos de Entrada e Sada (I/O ou input-output) e gerenciamento de
dados.

4.5 Definir mtodo para construir microsservios

Esta etapa consistiu em definir o mtodo para a construo dos microsservios. Para
tanto, este trabalho se baseou no manifesto denominado The Twelve-Factor App que
disponibiliza uma abordagem metodolgica para construo de servios de software,
defendendo as seguintes premissas:
Utilizar formatos declarativos para automao de configurao.
Possuir contrato (interface) bem definido com o sistema subjacente.
Ser adequado para a implantao em plataformas de nuvem modernas.
Minimizar a divergncia entre desenvolvimento e produo.
Possibilitar a escalabilidade vertical.
Os contribuintes deste manifesto esto diretamente envolvidos no processo de
desenvolvimento, escala e implantao de centenas de aplicativos, sintetizando a experincia
dos observadores sobre uma ampla variedade de softwares entregues como um servio,
triangulando as prticas de desenvolvimento, com ateno especial para a dinmica do
crescimento orgnico do software ao longo do tempo e tambm para a colaborao entre os
desenvolvedores.
 37

Figura 13 - Princpios apoiados pelo The Twelve-Factor ou Os Doze Fatores

Fonte: The Twelve-Factor App

Como segue na Figura 13, esta referncia de metodologia pode ser aplicada em
softwares escritos em linguagens de programao diferentes e que utilizaro quaisquer
combinaes de servios de apoio, como banco de dados, filas, cache de memria e etc.,
conforme explicitado detalhadamente na sesso 5.3 Definir relacionamento entre as
funcionalidades. O foco do manifesto est em desenvolvedores e engenheiros que implantam
ou administram software como um servio, abordando assuntos como controle de verso,
ambiente, construo, comunicao e execuo de tarefas de gesto e administrao.

4.6 Implantar os microsservios construdos

 38

Uma das vantagens em se utilizar os microsservios que estes possuem seus

prprios ciclos de compilao de maneira independente. Para tanto, faz-se necessrio adotar
uma soluo de recipiente leve, em plataforma aberta, para administradores e desenvolvedores,
que permita executar aplicaes distribudas, alm de oferecer um servio de nuvem para o
compartilhamento de aplicativos e automao dos fluxos de trabalho, proporcionando
isolamento de recursos necessrios, como por exemplo CPU, memria e rede.
O Docker tecnicamente uma plataforma aberta para se implantar e executar
aplicaes distribudas, permitindo que elas sejam construdas a partir de componentes,
eliminando o atrito entre o ambiente de desenvolvimento e o controle de qualidade e produo
definido em seu aspecto comercial. Com o Docker tambm possvel fornecer um ambiente
padronizado para a equipe de desenvolvimento, alm de facilitar a implantao e execuo de
aplicativos em qualquer infraestrutura.

Figura 14 - Representao da tecnologia de Mquina Virtual

5
Fonte: Desmembramento dos recursos de uma mquina virtual tradicional

Como mostra a Figura 14, cada aplicao virtualizada no contm apenas seu
aplicativo, uma vez que na virtualizao se deve incluir tambm os arquivos binrios, as
bibliotecas necessrias, alm de um sistema operacional completo em operao para permitir
que uma determinada aplicao se mantenha em execuo como expectado, o que pode
necessitar um espao em mdia de 10 Gigabytes (GB) de armazenamento em disco.

5
http://www.docker.com/whatisdocker/
 39

Na Figura 15, a seguir, o recipiente provido pelo Docker compreende apenas o

aplicativo e suas dependncias, sendo que a aplicao executada por um processo encadeado
e isolado no espao do usurio do sistema operacional em operao, compartilhando seu ncleo
com os outros recipientes, aumentando a portabilidade e a eficincia em virtude particularmente
da alocao e do isolamento de recursos.

Figura 15 - Representao da tecnologia Docker

6
Fonte: Diviso em camadas de uma tecnologia de continer

4.7 Realizar um estudo de caso

O estudo de caso consistiu em utilizar o mtodo proposto neste trabalho de

concluso de curso para desenvolver um sistema para auxiliar o tratamento mdico com o uso
de fototerapia. Este sistema composto por um conjunto de servios independentes, alm de
possibilitar acesso via dispositivos mveis.
A partir da concluso desse estudo de caso foi possvel verificar a conformidade e
a adaptabilidade, bem como o refinamento do mtodo ora proposto, tendo como base os
requisitos elicitados para o desenvolvimento das aplicaes e, ao final, sendo destacadas as
foras e fraquezas do mtodo no cenrio e contexto em que o mesmo foi aplicado.

6
http://www.docker.com/whatisdocker/
 40

5 MTODO DE DESENVOLVIMENTO COM MICROSSERVIOS

Nesse contexto, este trabalho prope a definio de um mtodo para o

desenvolvimento de software baseado em microsservios. Este mtodo direciona a construo
de servios, pois fornece um conjunto de nove passos bem definidos e utiliza os principais
conceitos para desenvolvimento de aplicaes distribudas, utilizando alta tecnologia,
computao em nuvem e a habilidade de escala horizontal e vertical, tendo seus recursos
computacionais garantidos, isolados e seguros a fim de evitar a sobrecarga das mquinas fsicas
provenientes do alto nmero de acessos simultneos dos multiusurios. Com a utilizao do
mtodo proposto pretende-se facilitar o processo de desenvolvimento de sistemas de software
mais complexos, confiveis, modulares, com maior qualidade e voltados grande escala.
A proposta compreende tambm, caso necessrio, utilizar componentes de cdigo
aberto que atendam s necessidades do negcio e auxiliem na construo de um software
baseado em microsservios, evitando custos no planejados com licenciamento ou propriedade
intelectual de software.

5.1 Elicitao de requisitos

Como primeira etapa deste conjunto de passos, a elicitao de requisitos uma

tarefa primordial para que se identifique as regras de negcio em que o sistema se apoia e uma
maneira de simplificar e validar o entendimento das funcionalidades deste sistema. Como em
todo processo de engenharia de software desejvel conhecimento sobre o domnio da
aplicao, juntamente com o entendimento especfico do problema a ser resolvido e do negcio,
levando em considerao as necessidades do cliente e as limitaes das tecnologias.
Pode-se utilizar desde as principais tcnicas tradicionais, como:
Coleta de dados
Entrevistas
Questionrios
Reunies
Tcnicas colaborativas, como:
Brainstorms
Prototipao
Tcnicas cognitivas, como:
 41

Anlise de tarefas
Tcnicas de aquisio de conhecimento
E tambm, abordagens contextuais, como:
Etnografia
Anlise de discursos
Ambas tcnicas citadas esto disponveis na literatura, cada uma contendo seu
prprio conjunto de vantagens e desvantagens em sua aplicao prtica7.
Acompanhando a abordagem da sesso 2.1.1 Princpios dos Microsservios, os
servios devem ser projetados para serem leves, coesos e possurem responsabilidade nica,
sendo assim, utilizar uma metodologia de desenvolvimento gil, como o Scrum apoiado em
estrias de usurio, pode auxiliar o planejamento e a gesto do projeto de software, pois os
ciclos tipicamente mensais e as funcionalidades a serem implementadas mantidas no Product
Backlog permitem ciclos de iteraes ideais aderentes ao modelo de desenvolvimento de
software baseado em microsservios proposto.

5.1.1 Abordagem de desenvolvimento gil de software com microsservios

Uma abordagem para o desenvolvimento baseado em microsservios utilizar o

modelo de desenvolvimento gil, com ele possvel manter entregas contnuas do produto,
separando, caso necessrio, o desenvolvimento dos microsservios entre os times responsveis.
Pode-se granular os servios a partir de um conceito inicial e dar incio aos processos que
antecedem ou sucedem a prpria fase de desenvolvimento, e consequentemente manter as
entregas em paralelo.

Figura 16 - Quadro das fases de desenvolvimento gil com microsservios

Fonte: Elaborado pelo autor.

7
http://martinfowler.com/articles/microservice-testing/
 42

Na Figura 16, so exibidas as fases de desenvolvimento adotadas para esta proposta

e como podem ser mantidos os status de uma determinada funcionalidade ao longo o ciclo de
vida do processo de desenvolvimento dos microsservios.

5.2 Definir funcionalidades

Esta segunda etapa, apoiada nos requisitos funcionais, no funcionais e de

qualidade, consiste na definio das funes (funcionalidades) do sistema, ainda seguindo os
conceitos de projeto simples, microsservios leves e independentes, ou seja, ao definir as
funcionalidades um servio deve possuir zero dependncias e estar limitado a um nico
domnio.
Deve ser realizada a decomposio do produto de software em microsservios com
base nas responsabilidades e interaes do sistema, em que se identifica funcionalidades para
encontrar contextos limitados. Deve-se encontrar responsabilidades especficas impostas por
um limite explcito para definir as funcionalidades que compreendero o sistema em sua
totalidade.
A alternativa para definio de funcionalidades em um novo projeto modelar
servios para microsservios baseando-se no produto mnimo vivel, em que se inicia com um
pequeno conjunto de funcionalidades com foco no ncleo ou core do sistema, atentando-se
arquitetura, qualidade do cdigo e se possvel entrega contnua. A estratgia de particionamento
de funcionalidades em verbos, como abordado no trabalho relacionado 3.1 On Micro-services
Architecture, auxilia na limitao de contextos, como por exemplo:
Contexto do website:
o Assinar newsletter.
o Efetuar pagamento.
o Fornecer informao de entrega.
o Adicionar artigo ao carrinho de compras.
Contexto da manipulao de pedidos:
o Enviar e-mail de confirmao.
o Atualizar estoque.
o Escolher produto em armazm.
Contexto do relacionamento com o cliente:
o Mapear interesse do cliente.
 43

o Personalizar recomendaes.

5.3 Definir relacionamento entre as funcionalidades

Neste terceiro passo, um fator importante a ser considerado aps a definio e

formalizao das funcionalidades da etapa anterior, utilizar o conceito de agregador para
unificar as chamadas aos servios que compem o fluxo de relacionamento entre as
funcionalidades.
Como mostra a Figura 17, a seguir, ao definir o relacionamento entre as
funcionalidades ou responsabilidades, o conceito de agregador otimiza a API para a aplicao
da camada superior (Aplicaes) tornando seu comportamento mais consistente e
principalmente promove o isolamento das funcionalidades dos servios na camada de Servios
de negcio por meio da inverso de controle dos microsservios para a camada de Agregadores.

Figura 17 - Exemplo de arquitetura e definio de responsabilidades por camadas

8
Fonte: Adaptado de hybris-as-a-service, A Microservices Architecture in Action

Ainda na Figura 17, os Servios de apoio, divididos em uma camada, so quaisquer

servios consumidos via rede como parte da operao normal ou fluxo de operao de um
microsservio essencial ou de negcio.
Sendo assim, nessa proposta, clientes na camada de Aplicaes no se
comunicariam diretamente com os microsservios da camada Servios de negcio,
simplificando o nmero de requisies para atender a uma regra ou fluxo de negcio e

8
Microxchg conf: http://microxchg.io/2015/slides/02_05_microxchg_andrea.pdf
 44

reduzindo o tratamento de erros e as lgicas de negcio da responsabilidade do cliente na

camada de Aplicaes.

5.4 Definir servios e interfaces fundamentado pelas funcionalidades

Ao definir servios e interfaces para os microsservios uma das vantagens notveis

desta arquitetura a sua natureza granular e, com isso, o fato de se possuir vrias opes a
respeito de como se resolver problemas. A fim de reduzir a repetio de cdigo entre servios
distintos que utilizam modelos semelhantes, pode-se adotar as tcnicas elencadas abaixo, desde
que elas no gerem dependncias entre os servios, e possam ser reaproveitadas durante a fase
de desenvolvimento, como:
Bibliotecas compartilhadas.
Mdulos.
Neste momento, com o intuito de reduzir a transmisso de dados entre
cliente/servidor e minimizar o nmero de solicitaes aos recursos disponibilizados pelos
microsservios, deve-se especificar como um cliente solicita que os recursos sejam acessados
ou modificados e como o servidor deve responder a essas solicitaes. Para definir servios e
interfaces mais complexas pode-se utilizar UML, em especial, os diagramas de sequncia, com
o intuito de representar visualmente o comportamento das funcionalidades que envolvem vrias
classes e chamadas a mtodos distintos, tornando complexo determinar o fluxo e o
comportamento ao longo do ciclo de vida do microsservio.
Nas subsees posteriores abordam-se as responsabilidades dos clientes e
servidores, bem como indica-se uma padronizao para cdigos de resposta e retorno
frequentemente utilizados.

5.4.1 Comunicao e negociao de contedo entre clientes e servios

Para o planejamento de comunicao e construo da API deve-se manter uma

semntica intuitiva, sendo que os termos adotados precisam ser concretos e de fcil assimilao
ao prover acesso s funcionalidades projetadas para os microsservios. Adotar as especificaes
da json:api (2015) para o formato das solicitaes e respostas e seguir as convenes
compartilhadas permite se concentrar na comunicao dos servios, aumentando a
produtividade na fase de desenvolvimento.
 45

O cliente deve solicitar e enviar toda informao via requisio, obrigatoriamente

contendo o cabealho Content-Type: application/vnd.api+json e sem nenhum tipo de
parmetro adicional (JSON:API, 2015).
O servidor deve enviar toda informao de resposta via documento,
obrigatoriamente contendo o cabealho Content-Type: application/vnd.api+json e sem
nenhum tipo de parmetro adicional (JSON:API, 2015). Neste contexto, documentos so
quaisquer estruturas definidas em JSON, ou seja, JavaScript Object Notation, um formato leve
de intercmbio de dados.

5.4.2 Cdigos de resposta e retorno

Ao planejar o desenvolvimento da API, deve-se padronizar os cdigos de resposta

e retorno, pois eles indicam ao cliente um feedback sobre a requisio solicitada.
200: Sucesso.
400: URL Invlida.
403: Recurso invlido.
404: Recurso no encontrado.
412: Falha na requisio.
500: Erro interno de servidor.
503: Limite de uso atingido.
Assim, define-se uma especificao de como os clientes devem solicitar os recursos
e como o servidor deve responder a esses pedidos. Com essa definio, os clientes podem
padronizar tomadas de deciso sobre alguma falha inesperada ao acessar recursos ou caso parte
de um fluxo seja interrompido baseando-se nos cdigos de resposta definidos. Se necessrio,
pode-se utilizar customizar mais cdigos de resposta, desde que se adequem ao fluxo de
execuo.

5.5 Escolher tecnologia para implementao de microsservios

Neste quinto passo, deve-se optar pela tecnologia de construo dos microsservios
que mais atenda s necessidades do sistema, obedecendo ao princpio da responsabilidade
nica, discutido na sesso 2.1 Microsservios, segregao de interfaces e inverso de controle
e dependncia. Nos prximos tpicos so apresentadas as principais tecnologias utilizadas para
 46

desenvolvimento com microsservios, seguido de ferramentas de anlise de logs,

monitoramento e localizao e descoberta, para complementar os conceitos propostos neste
mtodo.

5.5.1 Principais tecnologias de microsservios

Nesta sesso so listadas as principais tecnologias de microsservios consolidadas

e em produo no mercado, elas podem ou no ser equivalentes ou complementares, cada uma
com sua particularidade e adaptabilidade ao contexto de aplicao.
9
Spring Boot : um framework no intrusivo, que auxilia a produtividade e o
desenvolvimento de aplicaes Java independentes. Ele foi desenvolvido baseado nos padres
de projeto de injeo de dependncia e inverso de controle, possuindo uma arquitetura baseada
em interfaces que oferecem mecanismos de controle de transaes e segurana, alm de facilitar
o desenvolvimento com testes unitrios. Por fornecer uma ferramenta de linha de comando que
executa scripts, o Spring Boot proporciona uma experincia de desenvolvimento rpido e
acessvel, fornecendo funcionalidades comuns a uma grande categoria de projetos, como:
servidores embutidos, segurana, mtricas e configuraes exteriorizadas programticas sem
exigncia de configurao via arquivos XML.
Dropwizard10: um framework Java para o desenvolvimento baseado em operaes
amigveis ou ops-fiendly, de alto desempenho e com suporte a servios web RESTfull. Ele rene
bibliotecas maduras e estveis do ecossistema Java em um pacote simplificado e leve,
permitindo aos desenvolvedores se concentrar no desenvolvimento. O Dropwizard possui
configurao sofisticada, com mtricas de aplicao, logging e ferramentas operacionais que
auxiliam a desenvolver servios de qualidade com menor tempo de produo.
Play 211: um framework de alta velocidade para Java e Scala12, ele facilita a
construo de aplicaes por possuir uma arquitetura leve, sem estado e voltada web.
Desenvolvido em Akka13, um toolkit de desenvolvimento concorrente, distribudo e resiliente
baseado em JVM, ou Mquina Virtual Java, o framework proporciona um consumo mnimo de
recursos previsveis (CPU, memria, threads) para aplicaes altamente escalveis.

9
http://projects.spring.io/spring-boot/
10
http://www.dropwizard.io/0.9.2/docs/
11
https://www.playframework.com
12
http://www.scala-lang.org
13
http://akka.io
 47

Hystrix14: uma biblioteca de tolerncia a falhas desenvolvida pela Netflix OSS,

ela foi projetada para isolar os pontos de acesso a sistemas remotos, servios e bibliotecas de
terceiros. A biblioteca ainda possui suporte a tratamento de falhas e possibilita resilincia em
sistemas distribudos complexos, onde falhas geralmente so inevitveis.
Netflix OSS15: O Netflix Open Source Software Center um repositrio de sistemas
de cdigo fonte aberto, aproveitados, desenvolvidos, utilizados e mantidos pela Netflix, nele
so disponibilizadas ferramentas para gerenciamento e controle de dados (persistentes e semi-
persistentes) e ainda ferramentas para anlise que auxiliam a tomada de deciso e a melhoria
contnua dos servios fornecidos ao cliente final. Os sistemas foram planejados para operar os
servios com mximo desempenho, segurana e confiabilidade, concentrando-se na construo
contnua e integrao das aplicaes.

5.5.1.1 Anlise de logs

Kibana16: uma ferramenta open source, multiplataforma, web based, projetada

para anlise, pesquisa e visualizao de logs utilizando o Elasticsearch17 um engine, ou motor
de busca escalvel. A ferramenta foi desenvolvida para ser rpida de configurar e comear a
usar, sendo poderosa e flexvel assim como o Elasticsearch. Ela tambm pode ser utilizada
como um plugin para visualizao de dados abertos, fornecendo recursos de visualizao de
contedo e indexando grandes volumes de dados.
Logstash18: uma ferramenta open source para gerenciar eventos e logs, ela pode
ser utilizada para coletar, analisar e armazenar logs para uso posterior. Caso o utilize com o
Elasticsearch ele facilmente integrado para visualizao e anlise com o Kibana.
Loggly19: um servio proprietrio baseado em nuvem, para minerao de grandes
volumes de dados de logs em tempo real que auxilia ao produzir e analisar a qualidade de cdigo
de sistemas e melhorar a experincia do usurio.

14
https://github.com/Netflix/Hystrix
15
http://netflix.github.io
16
https://github.com/elastic/kibana
17
https://www.elastic.co
18
https://www.elastic.co/products/logstash
19
https://www.loggly.com/
 48

5.5.1.2 Tecnologias de monitoramento

Pagerduty20: um sistema proprietrio de gesto de incidentes e monitoramento de

tecnologias da informao, ele fornece alertas, polticas de escalonamento e monitoramento
para aumentar a disponibilidade de aplicativos, servidores, sites e banco de dados.
Servo21: um projeto da Netflix OSS que oferece uma biblioteca para
monitoramento de aplicaes escritas em Java. Ele fornece uma interface padro de
monitoramento que pode ser consultada por diversas ferramentas existentes e auxilia ao expor
e publicar mtricas sem ter que escrever cdigo do zero.
22
Atlas : tambm um projeto da Netflix OSS que fornece uma infraestrutura para
o monitoramento e gerenciamento de dados em srie temporal dimensional.
Graphite23: uma ferramenta open source, web based para acompanhar e
representar graficamente o desempenho de sistemas, ela coleta, armazena e exibe dados de srie
temporal em tempo real e renderiza os grficos sob demanda para o usurio final.
Zipkin24: um sistema de rastreamento distribudo open source desenvolvido pelo
Twitter25, ele auxilia a reunir dados necessrios para solucionar problemas de latncia em
arquiteturas baseadas em microsservios.

5.5.1.3 Localizao e descoberta de servios

Zookeeper26: um servio centralizado criado e mantido pela Apache Software

Fountation27 para persistir informaes de configurao, proporcionando sincronia distribuda
e prestao de servios de software em grupo. Com ele possvel desenvolver e manter um
servidor de cdigo aberto que permite coordenao distribuda altamente confivel.
Curator28: tambm mantido pela Apache, um conjunto de bibliotecas que tornam
o uso do Zookeeper mais simples. O Curator um substituto para o cliente do Zookeeper que

20
https://www.pagerduty.com/
21
https://github.com/Netflix/Servo
22
https://github.com/Netflix/Atlas
23
http://graphite.wikidot.com
24
https://github.com/openzipkin/zipkin
25
https://twitter.com
26
https://zookeeper.apache.org
27
http://apache.org
28
http://curator.apache.org
 49

se aplica a tarefas de baixo nvel com utilitrios que viabilizam funcionalidades a fim de
simplificar a complexidade do gerenciamento de operaes em cluster.
Eureka29: outro projeto criado e mantido pela Netflix OSS, um registrador e
localizador de servios para balanceamento de carga resiliente mid-tier, ou, disposto entre
intermdio do cliente e servidor, com suporte a failover, ou seja, projetado com suporte para
proteo de falhas disponibilizando recursos em espera a fim de assumir o controle quando
ocorrer interrupes no sistema principal.

5.5.1.4 Gerenciamento de configuraes

Archaius30: outro projeto da Netflix OSS, ele fornece um conjunto de APIs para
gerenciamento de arquivos de configuraes que auxilia a criar e customizar propriedades
dinmicas em aplicaes escritas em Java podendo ser customizadas em tempo de execuo.

5.6 Definir alocao dos microsservios

Na sexta etapa deste mtodo, projeta-se a alocao dos microsservios em

ambientes individuais, com mecanismos leves, que simplifiquem a escalabilidade,
portabilidade e a replicao. Como evidenciado na sesso 4.6 Implantar os microsservios
construdos, a alocao dos microsservios em um ambiente de continer uma alternativa
inicial ideal, partindo da necessidade da gesto de isolamento, controle do ciclo de vida,
velocidade de publicao e disponibilizao, tarefas relativamente comuns da administrao de
sistemas. Tecnologias de continer, como o Docker, facilitam o empacotamento,
gerenciamento, execuo e atualizao da aplicao, visto que, ao incluir as dependncias de
um microsservio a um continer, permite port-lo para plataformas distintas, tornando a
utilizao dos recursos mais eficiente em comparao com as plataformas tradicionais de
virtualizao, proporcionando assim construir um ambiente com recursos rigorosamente
planejados e controlados.
Utilizar a soluo tcnica de continer exige uma avaliao das motivaes para o
desenvolvimento baseado em microsservios e principalmente a propenso inovao futura.
O uso desta abordagem no necessariamente obrigatrio e depende dos princpios

29
https://github.com/Netflix/eureka
30
https://github.com/Netflix/Archaius
 50

arquitetnicos adotados, das polticas de segurana, do controle de acesso e da complexidade

do sistema; deve-se buscar utilizar tecnologias que agreguem valor ao sistema em sua
completude e que favoream sua evoluo.

5.7 Testar microsservios

A stima etapa recomenda atividades de testes durante e aps o desenvolvimento

baseado em microsservios proposto, visto que falhas podem ser motivadas por razes variadas.
Segundo Myers et al. (2011), no se pode garantir que todo software funcione corretamente e
sem a presena de erros, portanto, utilizar no mnimo a abordagem de testes de unidade ou TDD
durante a construo dos microsservios uma alternativa altamente recomendvel e
desempenha um papel importante, sendo que ela acomete classes e componentes isolados para
cada microsservio projetado, no entanto, utilizar somente a abordagem de testes unitrios no
fornece garantias sobre o comportamento do sistema.
Deve-se escolher dentre os tipos de testes de software as estratgias que
preferencialmente adicionem valor ao sistema, seguindo o objetivo proposto pelo teste e
gerenciando a complexidade adicional pela sua adoo. A seguir, so elencados os 13 principais
tipos de teste de software que podem ser aplicados em microsservios:
1. Testes de caixa branca e caixa preta.
2. Testes de configurao.
3. Testes funcionais.
4. Testes de instalao.
5. Testes de integridade.
6. Testes de integrao.
7. Testes de manuteno.
8. Testes de performance.
o Testes de carga.
o Testes de stress.
9. Testes de regresso.
10. Testes de segurana.
11. Testes de unidade.
12. Testes de usabilidade.
13. Testes de volume.
 51

Mais detalhes e aplicaes prticas sobre cada tipo de testes de software citados
acima esto amplamente disponveis na literatura31 32
. A seguir so elencadas algumas
tecnologias e ferramentas para desenvolvimento orientado testes.
JUnit33: um framework open source para criao de testes automatizados
utilizando Java como linguagem de programao.
Cucumber34: uma ferramenta de software para automatizar testes de aceitao
escritos no estilo Behavior-Driven Development ou BDD.
Selenium35: um framework de testes de software porttil para aplicaes web.

5.7.1 Entrega contnua

Dependendo da abordagem de testes empregada e da necessidade de adies e

modificaes frequentes de funcionalidades, neste contexto de desenvolvimento baseado em
microsservios, optar pela entrega contnua pode simplificar a liberao e refatorao de
funcionalidades para o cliente de maneira segura, sem a necessidade de haver interveno
manual dos desenvolvedores, atualizao de ambientes e verificao/validao da integridade
dos testes unitrios. Apesar dessa tcnica prover uma complexidade adicional aos projetos de
software e possivelmente exigir profissionais capacitados, pode ser uma alternativa crucial
baseando-se na necessidade de liberao e nas polticas de entrega de software empregadas.

5.8 Implementao

A implementao de um microsservio a etapa final deste mtodo proposto, tendo

em vista uma abordagem focada no desenvolvimento; uma das vantagens dessa metodologia
poder escolher a tecnologia que mais se adequa para solucionar um determinado problema, no
impondo mesma os demais servios. importante que a tecnologia adotada suporte as
definies de comunicao e negociao de contedo atravs da rede, sem afetar a estruturao
da aplicao e se adaptando ao ambiente de negcio dinmico.

31
http://martinfowler.com/articles/microservice-testing/
32
https://www.oreilly.com/learning/building-microservices-testing
33
http://junit.org/
34
https://cucumber.io
35
http://docs.seleniumhq.org
 52

5.8.1 Implementao dos microsservios

Os microsservios construdos para o estudo de caso, aprofundado no prximo

captulo, foram desenvolvidos utilizando o framework Spring Boot, em que cada servio possui
seu prprio mecanismo de persistncia e uma estrutura genrica pronta para ser distribuda. A
utilizao do Spring Boot com o Maven36 neste contexto simplifica a estruturao da
arquitetura, a construo da aplicao e viabiliza sua execuo gerando um nico arquivo JAR
executvel e portvel do microsservio (com todas dependncias necessrias), que pode ser
facilmente inicializado via linha de comando ou replicado para ambientes distintos. A estrutura
desse framework tambm permite a criao de testes unitrios automatizados a partir da
inicializao do projeto, sendo assim, possvel desencadear aes para testar funcionalidades
e comportamentos. O Spring Boot tambm conta com uma srie de endpoints que permite
monitorar e interagir com os microsservios com base em informaes bsicas de memria,
lista de configuraes, ambiente de execuo, mtricas, mapeamento de requisies e
informaes de trace para pedidos de requisies. O framework se mostrou uma tima
alternativa para entusiastas da abordagem de microsservios e maduro no mesmo mbito para
suportar o desenvolvimento de aplicaes robustas e complexas.
Complementando a proposta do captulo quinto, este mtodo foi projetado para
minimizar tanto o nmero de solicitaes, quanto a quantidade de dados transmitidos entre
microsservios. Essa eficincia deve ser priorizada ao longo do tempo, desde que se evite
comprometer a legibilidade e a flexibilidade dos microsservios.

5.9 Monitoramento dos microsservios

Para esta etapa semifinal, com base nas ferramentas citadas na sesso 5.5.1.2
Tecnologias de monitoramento, deve-se monitorar a utilizao e acompanhar a execuo
tanto quanto o fluxo de dados dos microsservios essenciais para verificar a performance e a
necessidade de escala. Essa etapa apresenta uma srie de desafios, principalmente para
aplicaes escalveis que adotam tecnologia de continer, e pode ter a complexidade de adoo
influenciada pela utilizao de protocolos de troca e enfileiramento de mensagens entre
diferentes servios.

36
https://maven.apache.org
 53

Uma ferramenta indicada para este contexto o spigo37, ou seja, Simulate Protocol
Interactions in Go using nanoservice actors, ele um protocolo em desenvolvimento de
simulao de interaes, que tambm auxilia a visualizao tanto da rede de interaes quanto
do fluxo de requisies, gerando um mapa visual em forma de grafo baseado no contexto das
trocas de mensagens, o que pode simplificar o entendimento da arquitetura e da comunicao
entre servios.
Para monitorar microsservios de maneira efetiva, deve-se lidar com mudanas
frequentes, uma tarefa corriqueira em ambientes em que se adota o desenvolvimento baseado
em microsservios podendo vir a ser um dos principais desafios para manter a adaptabilidade
s ferramentas de monitoramento.

37
https://github.com/adrianco/spigo
 54

6 ESTUDO DE CASO

Este estudo de caso consiste em implementar uma aplicao funcional bsica no

contexto de auxlio ao tratamento mdico com o uso de fototerapia, utilizando o mtodo de
desenvolvimento de software baseado em microsservios proposto neste projeto de pesquisa e
trilhando os requisitos funcionais elementares necessrios para a construo do sistema.
Enquanto sistemas monolticos possuem suas funcionalidades e regras de negcio
desenvolvidas e implementadas sob uma nica base de cdigo ou unidade, uma aplicao
baseada em microsservios desagrega as responsabilidades em servios leves, coesos,
independentes e especializados. Dessa maneira, h um sistema principal, neste estudo definido
como a interface grfica com o usurio, e outros sistemas baseados em microsservios que
gravitam em torno deste sistema principal.
Sendo assim, quando um evento disparado em virtude de uma interao do usurio
atravs do sistema principal, os diferentes microsservios essenciais so notificados. Como
definido na sesso 2.3 REST como modelo arquitetural, essas notificaes so encapsuladas
nas requisies HTTP e os microsservios responsveis operam em conjunto, compartilhando
dados em mensagens no formato JSON. Cada um dos microsservios decide o que deve ser
realizado com base nos dados recebidos e conforme a necessidade de negcio do sistema como
um todo. Essa abordagem caracterstica contribui para o desacoplamento dos microsservios,
pois a independncia entre eles reduz a existncia de um nico ponto de falha e, caso ocorra
alguma intermitncia em algum dos servios ou entre os canais de comunicao, a
disponibilidade do sistema principal no comprometida.
A abordagem supracitada tambm facilita a adoo de tecnologias distintas, os seja,
pode-se dispor de servios do prprio sistema principal e inclusive de mecanismos de
persistncia de dados utilizados pelos servios sendo mantidos em tecnologias distintas.
Um fator observado durante o desenvolvimento com microsservios foi a
interseco de cdigo entre os servios independentes. Classes que desempenham papel de
modelo frequentemente deveriam ser replicadas entre os servios para tratamento dos objetos
comuns, causando duplicidade de informao. Para atacar esse problema foi adotada a
abordagem de criao de bibliotecas compartilhadas entre projetos.
Para o cenrio especfico deste estudo de caso foram desenvolvidas cinco
funcionalidades de negcio que englobam os microsservios de middleware (bright-
ms_middleware), autenticao (bright-ms_auth) e gerenciamento de clientes (bright-
ms_cliente) em conjunto, onde os microsservios fazem parte do pacote de domnio
 55

completamente expressado br.com.bright, com o intuito de simplificar a referncia

aplicao que representa o servio e ambos possuem como padro a arquitetura planejada e
apresentada na Figura 18 a seguir.

Figura 18 - Explorador de projetos do Eclipse Java EE IDE 4.5.1

Fonte: Elaborado pelo autor

Cada microsservio foi desenvolvido seguindo a estruturao de cdigo modelo-

viso-controlador ou MVC, um padro arquitetural que facilita a separao entre interao do
usurio e a representao da informao no sistema.
O microsservio de middleware age como um registrador bsico de recursos, ele
encontra, conhece e verifica o status de execuo a partir das informaes de sade dos
microsservios disponveis e indisponveis que compem a aplicao em sua totalidade. Cada
microsservio no contexto deste estudo de caso possui uma srie de mapeamentos default para
seus pontos de extremidade, contendo informaes de monitoramento diversas convencionadas
pela comunidade. Estes mapeamentos so nomeados de endpoints atuadores, e facilitam tanto
 56

a interao quanto o prprio monitoramento da aplicao. Por exemplo, informaes de sade,

como quando o servio requisitado atravs de um canal de comunicao seguro ou no para
o microsservio bright-ms_cliente so mapeados para a URL /heath, como mostra a Tabela 2,
que tambm expe uma srie de mapeamentos habilitados para este mesmo servio.

Tabela 2 Mapeamento padro de endpoint do microsservio bright-ms_cliente

ID Descrio
actuator Provides a hypermedia-based discovery page for the other endpoints
autoconfig Displays an auto-configuration report showing all auto-configuration
candidates
beans Displays a complete list of all the Spring beans in your application
dump Performs a thread dump
env Exposes properties from Springs Configurable Environment
health Shows application health information
info Displays arbitrary application info
metrics Shows metrics information for the current application
mappings Displays a collated list of all Request Mapping paths
trace Displays trace information (by default the last few HTTP requests)
Fonte: Elaborado pelo autor

O microsservio de autenticao estabelece e confirma a autenticidade do usurio,

processa requisies de login, logout, cria e verifica o token de autenticidade e checa a
procedncia dos clientes, com a finalidade de preservar a sesso entre os contextos distintos de
cada servio.
O microsservio de cliente persiste e gerencia os dados pessoais dos clientes,
permitindo novos cadastros, visualizao, alteraes e excluso dos registros existentes e
tambm disponibiliza a informao referente aos dados pessoais e fisiolgicos dos pacientes
aos demais microsservios.
Na Figura 19 a seguir, apresentado o dashboard, uma interface de administrao
que exige autenticao, desenvolvida com o intuito de exibir informaes sintetizadas sobre o
status de execuo dos microsservios individuais que compem o sistema em sua completude.
 57

Figura 19 - Dashboard de monitoramento bsico de microsservios

Fonte: Elaborado pelo autor

A Figura 20 apresenta a interface de administrao para gerenciamento de

pacientes. Nela, aps realizar autenticao, so exibidas informaes resumidas de todos os
clientes registrados, as operaes que podem ser realizadas para os registros individuais sendo
possvel tambm realizar uma busca para facilitar a localizao de um registro especfico.

Figura 20 - Interface de gerenciamento de pacientes

Fonte: Elaborado pelo autor

A Figura 21 apresenta mais uma interface de administrao para efetuar o cadastro

de pacientes, ela tambm exige autenticao. Nela so preenchidos os dados pessoais de uma
 58

pessoa definida atravs de um formulrio web a fim de se persistirem as informaes pessoais

e fisiolgicas dos pacientes, neste cenrio, uma responsabilidade igualmente do microsservio
bright-ms_cliente.

Figura 21 - Interface para incluso de paciente

Fonte: Elaborado pelo autor

Seguindo os conceitos propostos e os nove passos recomendados ao longo deste

projeto de pesquisa, a interface grfica com o cliente e o core do sistema principal foram
desenvolvidos utilizando as tecnologias PHP (PHP: Hypertext Preprocessor), Javascript e
CSS, diferente da tecnologia Java empregada na construo dos microsservios. A utilizao
destas tecnologias opcional, e no contexto deste trabalho foram adotadas para agilizar o
desenvolvimento. Cada microsservio individual e o sistema principal foram divididos em
projetos isolados com o intuito de inteligibilidade, simplificar o gerenciamento, aumentar a
manutenibilidade e favorecer sua evoluo. A utilizao do sistema principal pelo usurio final
torna transparente o backend do sistema em sua totalidade, j que ele no precisa conhecer,
localizar, nem verificar a disponibilidade dos microsservios que o orbitam para mant-lo
disponvel em sua totalidade. Os microsservios foram testados local e geograficamente e
distribudos com o intuito de avaliar o comportamento da interface principal, como ela lida com
a divergncia de latncia ponto a ponto e com atrasos na comunicao, mostrou-se apta a operar
 59

sob conexes com baixa taxa de transferncia de dados, sempre exibindo um feedback ao
usurio final em relao ao carregamento assncrono dos contedos sem comprometer o
carregamento das pginas ou pageload do sistema principal no afetando em termos de latncia
a experincia do usurio final.

6.1 Repositrio de cdigo do estudo de caso

O cdigo fonte do projeto deste estudo de caso, incluindo casos de uso,

microsservios, aplicao principal e diagramas das estruturas de banco de dados com
instrues SQL esto disponveis no seguinte repositrio:

https://bitbucket.org/kamihouse/bright_microservices
 60

7 CONCLUSO

O mtodo de desenvolvimento proposto neste trabalho de concluso de curso possui

um conjunto de passos que auxilia a criao e o projeto de sistemas de software complexos e
confiveis baseados em microsservios, pois leva em considerao as fases que antecedem o
desenvolvimento, como elicitao e definio de requisitos, e fases ps desenvolvimento, como
testes e manuteno, particularmente orientadas servios.
Como este mtodo se apoia na abordagem de desenvolvimento gil, ele considera
a modularizao e granulao de servios durante as fases de planejamento e implementao.
Ao se tratar de gerenciamento de projeto, ele auxilia o planejamento, a definio e a alocao
de atividades entre o time de desenvolvimento, levando em considerao os pontos
identificados como cruciais para a abordagem de desenvolvimento voltado microsservios,
como a separao de interesses, a diferenciao de domnios de negcio na identificao de
relacionamentos, o reconhecimento de grupos de funcionalidades que so bons candidatos a se
tornar um microsservio, e ainda, atrai a ateno para as estruturas de comunicao e interao
entre servios.
Este mtodo em integralidade pode ser considerado demasiado complexo,
dispendioso, e em termos de processo, pesado para construo de sistemas cuja tendncia de
crescimento e disponibilidade seja considerada constante, com menor exigncia de desempenho
e de baixa elasticidade. Para aplicaes demasiadamente simples, esse mtodo exige uma
heterogeneidade tecnolgica e como consequncia, camadas adicionais so necessrias para
suportar a execuo do sistema como um todo. E por fim, para abordar diferente tipos e
contextos de software, foi elencado um conjunto de tecnologias de desenvolvimento, logging,
monitoramento, localizao, descoberta e gerenciamento de microsservios, atualmente em
evidncia e adotadas no cenrio empresarial, a fim de orientar o leitor s tecnologias
consolidadas no mercado.
Para trabalhos futuros, utilizar o protocolo AMQP ou Advanced Message Queueing
Protocol em lugar do REST, visto que o AMQP um padro para troca de mensagens
assncronas interopervel, devido seu formato de mensagens e transmisso padronizados ele
permite escrever bibliotecas utilizando linguagens, tecnologias distintas e principalmente
executar aplicaes multiplataforma, no atrelando o desenvolvimento de aplicaes
arquitetura de CPU ou a sistemas operacionais especficos. O AMQP um mecanismo que
coordena o envio e recepo de mensagens em uma estrutura de fila, o que permite projetar um
 61

padro para o protocolos de mensageria, sendo assim, pode-se optar pela utilizao de Remote
Procedure Call ou Chamada Remota de Procedimento, encapsulada de maneira transparente
pelo prprio AMQP; No contexto do estudo de caso deste TCC, a tecnologia open source
RabbitMQ38 especializada em efetuar a comunicao entre servios via plataforma de
mensageria seria uma forte candidata a ser adotada.
O principal beneficio dessa abordagem, mesmo integrando uma camada adicional
de tecnologia a capacidade de monitorar em tempo real a utilizao, performance e a troca de
mensagens entre os microsservios, auxiliando a tomada de decises sobre escalabilidade.
Ainda como trabalhos futuros, para aplicaes de baixa latncia e altamente disponveis, ou
para aplicaes de tempo real, a utilizao da abordagem de programao reativa, com
utilizao de frameworks como o Meteor39, ou o Vert.x40 aplicados nas camadas de servios e
principalmente no front-end, podem influenciar positivamente a estrutura, o fluxo de dados,
apoiar a propagao de mudanas e facilitar a escala com utilizao de mltiplas instancias de
componentes.

38
https://www.rabbitmq.com
39
https://www.meteor.com
40
http://vertx.io
 62

REFERNCIAS

BERNERS-LEE, Tim et al. Uniform Resource Locators (URL). In: Network Working
Group, University of Minnesota, 1994. Disponvel em: <http://www.ietf.org/rfc/rfc1738.txt>.
Acesso em: 23 set. 2015.

Cunningham & Cunningham, Inc. Monolithic Design. Disponvel em:

<http://c2.com/cgi/wiki?MonolithicDesign>. Acesso em: 12 jan. 2016.

Docker. Disponvel em: <https://www.docker.com>. Acesso em: 17 fev. 2016.

ELMANGOUSH, Asma; AL-HEZMI, Adel; MAGEDANZ, Thomas. Towards Standard

M2M APIs for Cloud-based Telco Service Platforms. In: Proceedings of International
Conference on Advances in Mobile Computing & Multimedia. ACM, 2013. p. 143.

EUROPEAN TELECOMMUNICATIONS STANDARDAS INSTITUTE. ETSI Machine-

to-Machine Communications info and drafts. Disponvel em:
<http://docbox.etsi.org/M2M/Open/>. Acesso em: 17 abr. 2015.

FIELDING, Roy Thomas. Architectural styles and the design of network-based software
architectures. 2000. Tese de Doutorado. University of California, Irvine.

FIELDING, Roy T.; TAYLOR, Richard N. Principled design of the modern Web
architecture. ACM Transactions on Internet Technology (TOIT), v. 2, n. 2, p. 115-150,
2002.

FOWLER, Martin. The New Methodology. Disponvel em:

<http://www.martinfowler.com/articles/newMethodology.html#N8B>. Acesso em: 2 mai.
2015.

FOWLER, Martin. Patterns of enterprise application architecture. Addison-Wesley

Longman Publishing Co., Inc., 2002.

GARLAN, David; SHAW, Mary. An introduction to software architecture. 1994.

Disponvel em:
<http://repository.cmu.edu/cgi/viewcontent.cgi?article=1720&context=compsci>. Acesso em:
20 abr.2015.

JEN, Lih-ren; LEE, Yuh-jye. Working Group. IEEE recommended practice for architectural
description of software-intensive systems. In: IEEE Architecture. 2000. Disponvel em
<https://standards.ieee.org/findstds/standard/1471-2000.html>. Acesso em: 7 mai. 2015.

Json:api. Disponvel em: <http://jsonapi.org>. Acesso em: 23 set. 2015.

KUNZE, J. Functional Requirements for Internet Resource Locators. Work in Progress,

December, 1994.

LEWIS, James; FLOWER, Martin. Microservices. Disponvel em:

<http://martinfowler.com/articles/microservices.html>. Acesso em: 3 abr. 2015.
 63

LEVCOVITZ, Alessandra; TERRA, Ricardo; VALENTE, Marco Tulio. Towards a

Technique for Extracting Microservices from Monolithic Enterprise Systems.

MARINESCU, Dan C. Cloud computing: Theory and practice. 1 ed. Waltham: Newnes,
2013.

MARTIN, Robert Cecil. Agile software development: principles, patterns, and practices.
Prentice Hall PTR, 2003.

MARTIN, Robert Cecil. The Clean Architecture. Disponvel em:

<http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html>. Acesso em: 25
mai. 2015.

MARTIN, Robert C. The single responsibility principle. The Principles, Patterns, and
Practices of Agile Software Development, p. 149-154, 2002.

Microservices, Docker and Containers, an Overview. Disponvel em:

<http://www.simplicityitself.com/articles/microservices-docker-and-containers-an-overview>.
Acesso em: 25 jan. 2016.

Microxchg - The Microservices Conference in Berlin. Disponvel em: <http://microxchg.io>.

Acesso em: 23 jan. 2016.

MYERS, Glenford J.; SANDLER, Corey; BADGETT, Tom. The art of software testing.
John Wiley & Sons, 2011.

NAMIOT, Dmitry; SNEPS-SNEPPE, Manfred. On M2M Software. International Journal of

Open Information Technologies, v. 2, n. 6, p. 29-36, 2014.

NAMIOT, Dmitry; SNEPS-SNEPPE, Manfred. On micro-services architecture.

International Journal of Open Information Technologies, v. 2, n. 9, p. 24-27, 2014.

NEWMAN, Sam. Building Microservices. 1 ed. O'Reilly Media, Inc., 2015.

PRESSMAN, Roger S. Engenharia de Software. 6 ed. McGraw-Hill, 2006.

RICHARDSON, Chris. Microservices architecture. Disponvel em:

<http://microservices.io/patterns/microservices.html>. Acesso em: 20 mai. 2015.

RICHARDSON, Chris. Microservices: Decomposing applications for deployability and

scalability. 2014.

ROBERTS, Wendy E. Skin type classification systems old and new. Dermatologic clinics, v.
27, n. 4, p. 529-533, 2009.

SCRUM. Disponvel em: <http://www.desenvolvimentoagil.com.br/scrum>. Acesso em: 22

jan. 2016.

SOUSA, Flvio RC; MOREIRA, Leonardo O.; MACHADO, Javam C. Computao em

 64

nuvem: Conceitos, tecnologias, aplicaes e desafios. II Escola Regional de Computao

Cear, Maranho e Piau (ERCEMAPI), p. 150-175, 2009.

TEAM, CMMI Product. CMMI for Development, version 1.2. 2006.

Testing Strategies in a Microservice Architecture. Disponvel em:

<http://martinfowler.com/articles/microservice-testing>. Acesso em: 17 fev. 2016.

The Twelve-Factor App. Disponvel em: <http://12factor.net>. Acesso em: 13 mai. 2015.

THONES, Johannes. Microservices. Software, IEEE, v. 32, n. 1, p. 116-116, 2015.

VERNON, Vaughn. Implementing domain-driven design. 1 ed. Westford: Addison-

Wesley, 2013.

VIENNOT, Nicolas et al. Synapse: a microservices architecture for heterogeneous-database

web applications. In: Proceedings of the Tenth European Conference on Computer
Systems. ACM, 2015. p. 21.

VMware buys into Docker containers. Disponvel em:

<http://www.zdnet.com/article/vmware-buys-into-docker-containers/>. Acesso em: 16 fev.
2016.