O documento explora a arquitetura de microsserviços, destacando seu conceito, desenvolvimento, implementação e desafios como falhas, sobrecargas e comunicação via mensagens. Propõe padrões e soluções como circuit breakers, service discovery, load balancing e API gateways para mitigar esses problemas, integrando ainda a relação entre microsserviços e IoT. Conclui que, embora ofereçam escalabilidade e tolerância a falhas, os microsserviços não são uma solução ideal em todas as situações, dependendo de fatores diversos.

1. RA 009677 - Rafael Pereira de Sousa
Microservices

2. AGENDA
● Origem e Conceito
● Desenvolvimento e Deploy
● Problemas
● Circuit Breaker
● Service Discovery
● Load Balancing
● API Gateway
● Microservices + IoT
● Caso de uso: Circulino
● Demo
● Conclusão
● Referências
2

3. Origem
3
De acordo com James Lewis and Martin Fowler, o termo “microservices” foi
discutido pela primeira vez em um workshop de arquitetura de software em maio
de 2011.
Werner Vogels (Amazon) - “encapsulating the data with the business logic that
operates on the data, with the only access through a published service interface”.
Adrian Cockcroft (Netflix) - “loosely coupled Service-Oriented Architecture with
bounded contexts”.
Outros termos usados na indústria na época para transmitir conceitos
semelhantes foram “fine-grained SOA” and “SOA done right.”

4. Conceito
4
Microservices ou arquitetura de microsserviços é uma técnica de
desenvolvimento de software que utiliza o conceito de modularização;
Microservices são similares a arquitetura orientada a serviços (SOA - Service
Oriented Architecture);
Diferentemente de SOA, microservices utilizam tecnologias leves e nativas
para desenvolvimento web;
A arquitetura de microsserviços não foi
inventada, ela emergiu de boas práticas.

5. Desenvolvimento
5
O desenvolvimento de microsserviços fazem uso de tecnologias leves de
container na nuvem, aplicação de práticas DevOps, escalabilidade tanto
para atender diversos clientes, quanto durante sua construção;
Cada microserviço executa
seu próprio processo e se
comunica com mecanismos
leves, bem diferente de um
monolito.

6. Deploy
6
● Os componentes podem ser implantados separadamente, permitindo o
gerenciamento independente de seus respectivos ciclos de vida.
● Novas versões de componentes podem ser gradualmente introduzidas
em um sistema, implantando-as lado a lado com versões prévias. Essa
vantagem pode ser incorporada em integração contínua.
● Os componentes podem ser mais especializados, pois podem ser
escritos em diferentes tecnologias - desde que essas tecnologias
trabalhem com outras tecnologias usadas, via troca de mensagens.
● Escalar uma arquitetura de microserviço não implica uma duplicação
de todos os seus componentes, os desenvolvedores podem fazer o
deploy / dispose de instâncias de serviços de acordo com a carga.

7. Embora muitos dos problemas sejam herdados diretamente dos sistemas
distribuídos, microsserviços possuem seus próprios problemas que
são exacerbados pelo alto grau de distribuição da arquitetura.
● As interações entre microsserviços acontecem via troca de mensagens
que introduz as possibilidades de falhas de comunicação e timeouts
entre os componentes.
● Os serviços podem ficar sobrecarregados devido a muitos solicitações
simultâneos ou recursos de clientes sendo mantidos ocupados
enquanto aguarda respostas de outros serviços. Isso pode
desencadear facilmente falhas em cascata desastrosas.
● Os microsserviços são otimizados para computação em nuvem,
portanto alguns serviços podem ser realocados em tempo de
execução.
Problemas
7

8. Soluções - Patterns
8
● Circuit Breakers
● Service Discovery
● Load Balancing
● Api Gateways

9. Circuit Breaker
9
Responsável por prevenir que uma falha de um único componente se
espalhe para fora de seus limites e comprometa todo o sistema.
Solução: Falhar rápido!

10. Circuit Breaker
10

11. Service Discovery
11
Funciona como um DNS de serviços, permitindo que os microsserviços
busquem informações de localização dos demais.
Service Registry é o banco de dados contendo a localização das instâncias.
● A localização dos microsserviços pode não ser conhecida em tempo de
desenvolvimento (IP, porta);
● Por rodar normalmente em ambiente de nuvem eles podem ser
replicados e realocados em tempo de execução.

12. Load Balancing
12
Permite distribuir as requisições uniformemente entre as instâncias,
otimizando a utilização de recursos, diminuindo o tempo de resposta e
minimizando sobrecargas.

13. API Gateway
13
Uma arquitetura de microsserviços deve estar preparada para servir
diferentes tipos de clientes, como web browsers e smart devices.
Cada cliente pode ter necessidades especiais que podem mudar ao longo
do tempo, dependendo da qualidade de conexão pode ser necessário
utilizar uma API que utiliza mais ou menos rede.

14. Microservices + IoT
14
Dados do artigo:
● A Gartner prevê cerca de 21 bilhões de dispositivos até 2020
● A Cisco prevê até 50 bilhões de dispositivos conectados até 2020
Previsões mais atuais:
● A Gartner prevê cerca de 25 bilhões de dispositivos até 2021
● A Cisco prevê até 12 bilhões de dispositivos conectados até 2022
É difícil pensar em um aplicativo monolítico para lidar com todos os dados
que são produzidos e consumidos por todas essas coisas.
Microsserviços e Internet das Coisas possuem objetivos comuns:
• Comunicação leve,
• Software implantável independente,
• Um mínimo de gerenciamento centralizado, e
• Técnicas e tecnologias independentes de desenvolvimento.

15. Padrões e melhores práticas da arquitetura de
microsserviços comparado com as práticas de IoT
15
Self-Containment
● serviços devem conter tudo que precisam para cumprir suas
tarefas,
● serviços podem representar dispositivos físicos como sensores e
atuadores.
Benefícios:
● os dados mantidos pelo serviço não são acessados diretamente
pelo cliente, permitindo uma evolução dos serviços, a
representação interna dos dados pode ser alterada, mantendo
ainda a interoperabilidade.
● Ter cada serviço fornecendo sua própria interface de usuário
também permite uma evolução independente
● Menos dependências e dissociação entre os serviços aumenta a
autonomia e reduz a quantidade de comunicação necessária na
rede.

16. Padrões e melhores práticas da arquitetura de
microsserviços comparado com as práticas de IoT
16
Monitoring and Prevention of Fault Cascading
● Cada serviço deve fornecer uma interface para entregar as
informações de monitoramento, em particular, o estado de saúde:
ok e broken;
● Outros serviços poderem verificar o status de integridade e impedir
a chamada de serviços interrompidos;
Benefícios:
● O padrão Circuit Breaker previne envio de mensagens para
serviços "quebrados" reduzindo o tráfego geral na rede e
economizando energia que seria gasta na (re) transmissão;
● O padrão Load Balancer pode aumentar a vida útil dos sensores
sem fio, pois a carga de trabalho é compartilhada entre vários
dispositivos, o que lhes permite permanecer mais tempo em
modos de baixa energia.

17. Padrões e melhores práticas da arquitetura de
microsserviços comparado com as práticas de IoT
17
Choreography over Orchestration
● Coreografia: cada participante faz sua parte por conta própria e o
aplicativo resultante é criado pela soma dos indivíduos. As partes
individuais realizam suas atividades com base em eventos;
● Orquestração: uma instância, o condutor, está no controle dos
serviços a serem chamados e faz isso de maneira centralizada;
● Microsserviços podem utilizar ambas abordagens, enquanto em
IoT o estilo orquestração é mais utilizado pela facilidade de
implementação com protocolos HTTP que não possuem suporte
nativo a comunicação baseada em eventos.

18. Padrões e melhores práticas da arquitetura de
microsserviços comparado com as práticas de IoT
18
Container
● Mais conhecido pelo Docker, porém Docker é apenas uma das
várias soluções para container também chamada operating-
system-level-virtualization;
● Outras soluções: openVZ, lxc / lxd e rkt para Linux, e ”Windows
Server Containers” or ”Hyper-V Containers” para Windows;
● Containers compartilham um sistema operacional instalado no
servidor e são executados como processos isolados.
Benefícios:
● Esse método de virtualização é bem mais leve em comparação
com a virtualização de hypervisor e, portanto, permite melhor
desempenho, menores tempos de inicialização e menos requisitos
de armazenamento;
● Melhor testabilidade, facilidade de deployment de serviços, melhor
escalabilidade.

19. Caso de uso: Circulino
19
Resultado de um teste de requisições HTTP feito com Apache Jmeter
sob as mesmas condições para ambas arquiteturas. Percebe-se que o
número de requisições atendidas na arquitetura de microsserviços é cerca
de 10 vezes maior que na arquitetura monolítica

20. Caso de uso: Circulino
20
Após o período de um mês de uso em produção constatamos a
diminuição de uso de processamento.
Monolito
Microservice

21. Demo
21

22. Conclusão
22
● Arquitetura de microsserviços não é
uma bala de prata, ela tem suas
vantagens e desvantagens e não há
uma resposta precisa para quando
usar ou não, depende de vários fatores
como tempo para desenvolvimento,
experiência das pessoas envolvidas e
demais recursos.
● Fornecem escalabilidade, incluindo
disponibilidade e tolerância a falhas,
porém isto tem um custo que pode ser
alto, pois ter várias entidades
independentes introduz uma
sobrecarga administrativa extra,
principalmente para implantação,
administração, monitoramento e
segurança.

23. Referências
23
● P. Jamshidi, C. Pahl, N. C. Mendonça, J. Lewis and S. Tilkov, "Microservices: The
Journey So Far and Challenges Ahead," in IEEE Software, vol. 35, no. 3, pp. 24-35,
May/June 2018.
● Montesi, Fabrizio and Janine Weber. “Circuit Breakers, Discovery, and API Gateways
in Microservices.” ArXiv abs/1609.05830 (2016).
● B. Butzin, F. Golatowski and D. Timmermann, "Microservices approach for the internet
of things," 2016 IEEE 21st International Conference on Emerging Technologies and
Factory Automation (ETFA), Berlin, 2016, pp. 1-6.
● Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, Manuel Mazzara,
Fabrizio Montesi, Ruslan Mustafin, and Larisa Safina. Microservices: yesterday,
today, and tomorrow. arXiv preprint arXiv:1606.04036, 2016.
● J. Lewis and M. Fowler, “Microservices,” 01/10/2019,
https://martinfowler.com/articles/microservices.html.
● E. Lupander, Go microservices, part 7 - Service Discovery & Load-balancing,
05/10/2019. https://callistaenterprise.se/blogg/teknik/2017/04/24/go-blog-series-part7/