Arquitetura de Software

Prévia do material em texto

10202503298-A02
Transcrito	por	TurboScribe.	Atualize	para	Ilimitado	para	remover	esta	mensagem.
Continuando	a	nossa	aula,	hoje	vamos	falar	um	pouco	sobre	os	tipos	de	padrões	de	arquitetura
que	temos	dentro	da	engenharia	de	software.	Vamos	 lá	conhecer,	então,	quais	são	os	 temas
que	nós	iremos	estudar	hoje?	Bom,	então,	o	objetivo	deste	estudo	hoje	é	conhecer	os	principais
tipos	 de	 arquitetura	 desses	 temas	 e	 suas	 aplicabilidades	 dentro	 da	 engenharia	 de	 software.
Não	 só	 da	 engenharia	 de	 software,	 tá,	 pessoal,	 mas,	 no	 contexto	 geral,	 em	 diversas	 áreas
também,	 nós	 vamos	 ter	 ali	 as	 aplicações	 das	 arquiteturas,	 tá?	 Voltando,	 então,	 aos	 nossos
slides.
E	 aí,	 então,	durante	este	estudo,	 serão	explorados	os	 seguintes	 temas.	Primeiro,	 arquitetura
em	 camadas	 e	 arquitetura	 cliente-servidor	 são	 as	 mais	 conhecidas.	 Arquitetura	 orientada	 a
serviços	SOAP	ou	a	SOAP,	né,	que	nós	vamos	falar	também.
E	 arquitetura	 baseada	 em	 microserviços.	 O	 próximo	 tema,	 arquitetura,	 seria	 modelo	 visão
controlador,	né,	MVC,	REST,	RESTful	e	arquitetura	de	micro	front-end.	E	arquitetura	orientada	a
eventos	e	arquitetura	a	dados.
Então,	nós	vamos	contextualizar	um	pouco,	né,	de	uma	maneira	simples,	de	o	que	são	essas
arquiteturas,	quais	são	suas	aplicabilidades,	né,	para	compreendermos	melhor	como	podemos
fazer	uma	boa	arquitetura.	Hoje,	agora,	vamos	falar	um	pouco	sobre	a	arquitetura	de	camadas
e	a	arquitetura	cliente-servidor.	Vamos	compreender	o	funcionamento	dessas	duas	camadas	e
vou	 dar	 um	 exemplo	 ali	 de	 aplicação	 delas,	 né?	 Vamos	 lá	 comigo	 nos	 slides?	 De	 maneira
sucinta,	 quando	 eu	 falo	 em	 camadas,	 arquitetura	 em	 camada,	 ela	 vai	 facilitar	 o
desenvolvimento	 incremental	 de	 sistemas	 de	 software,	 onde	 consegue	 permitir	 a	 entrega
iterativa	de	funcionalidades	à	medida	que	cada	camada	é	concluída.
Ou	 seja,	 se	 eu	 vou	 da	 última	 camada,	 né,	 um	 exemplo,	 até	 ali,	 a	 primeira	 camada,	 o	 topo,
então,	 conforme	 eu	 for	 concluindo	 a	 atividade	 daquela	 camada,	 da	 camada	 inferior,	 nós
conseguimos,	 então,	 ter	 algo	 integrável,	 né?	 Ou	 seja,	 nós	 vamos	 entregar	 algo	 e	 aí	 vamos
concluir	essa	etapa	e	vamos	poder	avançar	para	as	próximas	camadas.	Para	compreender	um
pouco	melhor	essa	parte	de	incremental,	ou	seja,	nós	podemos	adicionar	algo	e	sempre	estar
interagindo,	né?	Ou	seja,	vai	ter	uma	interação	ali	com	as	demais	camadas.	No	próximo	slide,
vou	explicar	um	pouco	melhor	para	vocês.
E	aí,	nós	temos	aqui	a	 interface	com	o	usuário,	o	gerenciamento	de	 interface	com	o	usuário,
que	 seria	 a	 autenticação	 e	 autorização,	 a	 lógica	 principal	 do	 negócio,	 funcionalidade	 da
aplicação,	 componentes	 utilitários	 para	 o	 sistema,	 o	 apoio	 ao	 sistema,	 que	 seria	 o	 sistema
operacional	e	o	banco	de	dados.	Como	que	isso	funcionaria?	Eu	estou	indo	da	camada,	né,	da
camada	de	nível	mais	baixo,	ou	seja,	da	parte	inferior	para	a	parte	superior,	ou	seja,	nós	vamos
subir,	né?	Então,	aí	nós	vamos	para	o	nível	mais	alto.	Então,	ali	na	primeira	camada,	voltando
https://turboscribe.ai/pt/?ref=pdf_export_upsell
https://turboscribe.ai/pt/subscribed?ref=pdf_export_upsell
aqui	nos	slides,	né?	Na	primeira	camada,	nós	temos	aqui	o	sistema	operacional	e	o	banco	de
dados.
Então,	nessa	camada,	vai	ser	armazenado	os	dados	ali.	E	ali,	olhando	na	próxima	camada,	nós
temos	a	lógica	principal,	ou	seja,	é	a	regra	de	negócio.	A	funcionalidade	vai	estar	ali	dentro,	a
aplicação,	em	relação	aos	componentes,	aos	frameworks,	ela	está	ali	na	segunda	camada,	de
baixo	para	cima,	vejam	só.
E	aí,	voltando	para	os	nossos	slides.	A	próxima	camada,	que	seria	a	terceira	camada,	de	baixo
para	cima,	nós	temos	a	interface.	É	onde	ocorre	o	gerenciamento	da	interface	com	o	usuário.
Ou	 seja,	 antes	 do	 usuário	 ter	 ali	 acesso	 mesmo	 ao	 programa,	 né?	 Ele	 precisa	 fazer	 a	 sua
autenticação.	Quando	 ele	 faz	 essa	 autenticação,	 ele	 sobe	 para	 o	 nível	mais	 alto,	 que	 seria	 a
nossa	última	camada,	que	é	o	nível	alto.	Que	seria	o	quê?	A	interface	de	usuário.
Agora,	ele	vai	ter	acesso	ali	ao	software	definitivamente,	certo?	Voltando	para	os	nossos	slides.
E	aí,	falando	de	uma	aplicabilidade	da	arquitetura	genérica	em	camadas,	eu	coloquei	aqui	um
simples	 sistema	 de	 gerenciamento	 de	 bibliotecas.	 Então,	 nós	 temos	 que	 pensar	 em	 alguns
aspectos.
O	que	nós	 vamos	 ter	 dentro	 desse	 gerenciamento	de	uma	biblioteca?	Nós	 precisamos	 ter	 o
usuário,	seja	ele	o	usuário	quem	vai	alocar	o	livro,	a	bibliotecária,	o	que	mais?	Precisamos	ter
os	dados	dos	livros	para	ter	dentro	do	banco	de	dados	as	informações,	até	também,	se	fulano,
bom,	 fulano	 não.	 Eu	 vou	 lá	 na	 biblioteca,	 eu	 quero	 fazer	 o	 quê?	 Eu	 vou	 querer	 fazer	 um
empréstimo	de	um	livro.	Então,	eu	preciso	verificar?	Eu	não,	né?	Mas	a	bibliotecária,	ela	precisa
verificar	se	ele	está	disponível	ou	não.
Porque,	às	vezes,	é	uma	unidade	só	que	tem	ali	dentro	da	biblioteca,	mas	aquela	unidade	física
que	não	sai	da	biblioteca,	que	ela	fica	lá,	você	só	pode	ler	lá	dentro,	você	não	pode	realizar	um
empréstimo.	E	aí,	os	outros	dois	 livros	 iguais	dele	estão	alugados	 já.	Então,	não	vou	 ter	essa
disponibilidade.
Então,	a	gente	precisa	ter	essas	informações.	Essas	informações	podem	ser	o	nome,	o	nome	do
livro,	o	ano,	algum	código	que	nós	podemos,	lá	dentro	da	biblioteca,	pode	ter.	O	que	mais?	O
ano	dele,	o	autor	desse	livro.
Por	que	é	 importante	ter	 isso?	Porque	quando	nós	formos	até	atualizar	esse	banco	de	dados
futuramente,	então	a	gente	vai	mexer	na	última	camada,	que	é	ali	que	vai	estar	 todas	essas
informações	referentes	aos	livros.	Voltando	aqui	para	os	nossos	slides,	e	aí	nós	temos	a	gestão
da	biblioteca	e	depois	a	apresentação	da	interface	do	usuário.	A	gestão	da	biblioteca	é	ali	quem
são	esses	usuários.
O	que	esse	usuário	ali	da	biblioteca,	 a	bibliotecária,	 ela	 vai	 ter	acesso.	 E	o	que	ela	 vai	 fazer?
Editar,	excluir	os	dados.	O	que	mais?	Salvar	dados	novos.
Então,	por	isso	que	nós	vamos	fazer	toda	essa	gestão	ali	na	segunda	camada.	E	quando	formos
para	a	terceira	camada,	que	é	a	última	camada,	nós	temos	a	interface	de	usuário.	É	o	nível	mais
alto	ali	do	software.
Então,	 vejam	 só,	 essa	 interface	 de	 usuário	 é	 quando	 vai	 retornar	 o	 que	 nós	 acabamos	 de
pesquisar,	o	que	nós	atualizamos	já	de	uma	maneira	mais	simplificada.	Veja	que	esse	padrão
arquitetônico,	 ele	 é	um	dos	mais	 simples	e	não	 tem	muita	 confusão.	 Se	 vocês,	 então,	 forem
fazer	um	outro	tipo	de	projeto,	um	exemplo,	um	stream	art,	uma	Netflix	da	vida,	então	vocês
poderiam	estar	sempre	pensando	em	quantas	camadas	vai	ter.
Claro	que	vai	depender	do	projeto	de	vocês,	se	vocês	precisam	ser	separadamente.	Mas	uma
coisa	que	eu	falo	para	vocês,	se	o	banco	de	dados	não	estiver	funcionando,	estiver	fora	do	ar,
nós	 não	 vamos	 conseguir	 fazer	 a	 gestão	 da	 biblioteca.	 Então,	 acaba	 rompendo	 ali	 uma
interação	da	outra.
Então,	por	isso	que	a	gente	precisa	testar	primeiro	o	banco	de	dados	e	para	depois	fazer	esse
gerenciamento	 do	 stream	 art,	 como	 nós	 estávamos	 falando	 da	 Netflix,	 ou	 seja,	 fazer	 o
gerenciamento	da	inclusão	de	filmes,	da	inclusão	de	musicais.	E	assim	por	diante.	Então,	uma
camada	 vai	 depender	 da	 outra,	 ou	 seja,	 uma	 precisa	 estar	 bem	 definida,	 funcionando
corretamente,	para	que	as	próximas	camadas	nos	retornem	o	esperado.
Voltando	 aqui	 para	 os	 nossos	 slides.	 E	 aqui,	 falando	 um	 pouco	 sobre	 a	 arquitetura	 cliente-
servidor.	 A	 arquitetura	 cliente-servidor	 é	 um	 padrão	 de	 software	 distribuído	 no	 qual	 os
recursos	e	dados	são	centralizados	em	um	servidor.
Ou	seja,	em	uma	máquina	servidora.	Enquanto	os	clientes	acessam	esses	recursos	através	de
uma	 rede.	 Então,	 essa	 arquitetura	 se	 tornou	 dominante	 devido	 à	 sua	 capacidade	 de
compartilhar	recursos	e	dados	de	forma	eficiente.
De	uma	maneira	simples,	vou	usar	o	mesmo	exemplo	que	eu	falei	ali	do	stream	art	da	Netflix.
Aqui	 caberia	muito	bem	uma	 locadora	defilmes	 estar	 utilizando	a	 camada	 cliente-servidora.
Por	quê?	Se	eu	vou	pesquisar	se	um	musical	ou	se	um	filme	está	alocado	ou	não	para	colocar
ali	para	assistir	online.
Alocado	não,	perdão.	Para	ter	acesso,	se	 tem	ali	dentro	do	repositório	do	servidor.	Então,	eu
vou	pesquisar	ali.
Só	que	vejam	só,	dentro	da	minha	casa	eu	tenho	cinco	TVs.	Um	exemplo.	E	aí,	essas	cinco	TVs
simultaneamente	também	estão	assistindo	a	Netflix.
E	aí,	elas	vão	ter	acesso	normal	ao	mesmo	filme.	Se	eu	quero	assistir,	aí	meu	pai	e	minha	mãe
querem	assistir	o	mesmo	filme	por	coincidência.	Então,	eu	vou	estar	lá	assistindo	na	sala	e	eles
vão	estar	lá	assistindo	lá	no	outro	cômodo	da	casa.
O	que	eu	estou	querendo	dizer?	Vários	clientes	vão	ter	acesso	simultaneamente	sem	que	um
derrube	o	outro.	Que	não	vai	ter	ali	problema	nenhum.	Claro,	dentro	das	regras	de	negócio,	no
caso,	um	exemplo	que	eu	estava	dando	da	Netflix.
Então,	voltando	para	os	nossos	slides.	E	aí,	aqui	de	uma	maneira	simplificada.	Então,	o	que	nós
temos?	Pense	lá	o	que	nós	temos.
Então,	se	eu	tenho	cinco	TVs	em	casa.	Então,	eu	vou	ter	cinco	clientes.	E	aí,	esses	cinco	clientes
vão	estar	acessando	um	único	servidor.
Esse	servidor,	que	seria	a	Netflix,	que	é	lá	da	base	deles,	vai	estar	transmitindo	para	essas	cinco
TVs	todo	o	conteúdo	que	eles	têm.	De	maneira	igual.	Ah,	no	Cliente	1,	ou	seja,	na	minha	TV	A,
vai	estar	só	apenas	dez	filmes.
E	aí,	na	TV	B,	vai	estar	seis	filmes.	Não.	Todos	os	filmes	que	a	minha	TV	A,	dali,	tem	acesso,	a
minha	TV	B	também	vai	ter	acesso.
Então,	essa	é	a	essência.	É	que	se	de	uma	maneira	ali,	um	cliente	tem	acesso	ao	servidor,	todos
eles	ali	que	estão	ligados	a	esse	servidor	vão	ter	acesso	aos	dados.	E	aí,	o	que	nós	precisamos
pensar	também?	Uma	outra,	ir	um	pouquinho	a	mais.
Na	Cliente	Servidor,	nós	temos	também	várias	camadas.	Ou	seja,	nós	temos	ali	como	repartir.
Os	clientes	é	onde	vão	estar	as	regras	de	negócio.
Vamos	pensar,	sim,	é	a	camada	de	regras	de	negócio.	E	o	servidor	principal,	que	seria	o	banco,
o	nosso	banco	de	dados.	Todas	as	informações	vão	estar	ali	naquele	servidor.
E	aí,	nós,	claro,	mas,	professor,	eu	posso	usar	só	um	servidor?	Eu	posso	utilizar	outro	servidor?
Nós	podemos	colocar	mais	um	servidor	para	separar	as	regras	de	negócio,	vamos	dizer	assim,
um	exemplo,	da	interface	de	usuário.	Onde	ali	eu	deixo	o	Cliente	Servidor	com	a	interface	de
usuário	e	toda	a	aplicação	do	projeto,	ou	seja,	da	Netflix,	eu	deixo	no	único	servidor.	Ou	seja,	a
parte	gerenciável	eu	deixo	no	segundo	servidor	e	aí	 todas	as	 informações	eu	deixo	no	outro
servidor	para	ser	o	banco	de	dados.
Voltando	aqui	para	os	nossos	slides,	e	aí	nós	temos	algumas	variações	da	arquitetura,	então,
da	Cliente	Servidor.	Como	eu	me	antecipei,	nós	podemos	ter	várias	camadas.	Então,	nós	temos
arquitetura	Cliente	Servidor	de	duas	camadas,	de	três	camadas	ou	então	de	múltiplas	camadas,
que	seria	N	camadas.
Quando	nós	temos	ali	de	duas	camadas,	é	 igual	o	que	eu	peguei	e	falei.	Primeiro,	eu	vou	ter
um	único	servidor.	Então,	eu	só	tenho	o	servidor	e	o	cliente.
Então,	 aqui	 a	 gente	 define	 que	 nós	 temos	 apenas	 duas	 camadas,	 que	 é	 o	 servidor,	 que	 é	 o
banco	de	dados,	que	seria	a	primeira	camada,	e	a	segunda	camada	nossa,	que	seria	o	cliente,	é
onde	 tem	as	 regras	de	negócio	e	a	apresentação	ali	do	projeto.	Ou	seja,	do	projeto	mesmo.
Quando	eu	entro	em	três	camadas,	Cliente	Servidor,	eu	estou	colocando	mais	um	servidor.
É	onde	que	eu	estou	ramificando,	separando	as	regras	de	negócios,	a	aplicação	do	negócio,	eu
estou	separando	dali	da	minha	camada	Cliente.	Ou	seja,	agora	a	camada	Cliente,	ela	só	vai	ter
ali	a	 interface	de	usuário,	e	a	aplicabilidade	do	projeto	vai	estar	no	segundo	servidor.	Então,
com	isso,	agora	eu	tenho	uma	camada	que	contém,	vamos	dizer	assim,	o	banco	de	dados,	que
é	o	servidor,	banco	de	dados,	aí	eu	tenho	o	servidor	de	aplicação	do	projeto,	que	é	a	regra	do
negócio,	ali	do	projeto	nosso,	e	aí	eu	tenho	a	terceira	camada,	que	seria	os	clientes.
Então,	toda	vez	que	tiver	alguma	alteração,	não	muda	nada,	vamos	dizer	assim,	o	contexto,	a
essência	 do	Cliente	 Servidor	 não	muda.	 A	 definição,	 eu	 digo,	 a	 gente	 só	 vai	 estar	 fazendo	 a
quebra	 dali	 das	 camadas.	 Eu	 estou	 incluindo	 mais	 servidores	 para,	 vamos	 dizer	 assim,
ramificar,	para	ter	uma	organização	melhor	quando	eu	for	fazer	uma	manutenção.
Mas	o	que	isso	implicaria,	quanto	mais	camada	eu	tiver,	o	que	isso	implicaria,	professora,	nos
projetos?	 Bom,	 talvez,	 em	 algum	 momento,	 isso	 pode	 implicar	 em	 quê?	 Se	 o	 servidor	 cai,
vamos	dizer	assim,	o	banco	de	dados	cai,	então	os	outros,	os	clientes,	eles	não	vão	ter	acesso.
Então,	o	seu	sistema,	ele	para.	E	uma	outra	informação,	que	talvez	seja	alguma	desvantagem,	é
que	quanto	mais	servidor	nós	tivermos,	a	gente	vai	diminuir	o	fluxo	dos	dados,	ou	seja,	a	gente
vai	 ter	uma	 leve	 lentidão,	dependendo	ali	 se	 for	uma	empresa	que	ela	depende	de	um	fluxo
alto	de	informações	entrando	dentro	do	banco	de	dados,	então	isso	acaba	implicando.
Quando	 eu	 falo,	 então,	 só	 resumindo	 também,	 de	múltiplas	 camadas	 ou	N	 camadas,	 é	 que
dizer,	então,	que	eu	vou	ter	outros	servidores,	e	aí	eu	vou	estar	ramificando	cada	vez	mais	o
nosso	 projeto.	 Claro,	 como	 eu	 vou	 saber	 disso,	 professora?	 Vai	 depender	 do	 projeto	 e	 da
necessidade	 da	 empresa	 que	 vocês	 estão	 desenvolvendo	 esse	 projeto.	 Então,	 não	 se
preocupem	que	vocês,	ah,	o	fulano	quer	que	eu	faça	um	projeto	de	software	para	um	hospital,
um	gerenciamento	de	hospital,	e	agora,	qual	que	eu	vou	ter	que	usar?	Quando	eu	chegar	lá	na
arquitetura,	qual	que	eu	vou	ter	que	usar?	Então,	vocês	vão	estar	com	a	coleta	de	requisitos	ali
em	mãos,	e	com	a	equipe	de	vocês,	vocês	irão	ter	o	feedback	de	projetos	anteriores,	e	aí	vocês
vão	escolher	qual	que	é	a	melhor	arquitetura	para	se	aplicar.
Visando	 o	 quê?	 O	 custo,	 porque	 às	 vezes	 o	 cliente	 não	 quer	 gastar	 muito,	 agilidade	 e
segurança.	Então,	agilidade	conta	muito.	Igual	que	eu	peguei	e	falei,	para	um	sistema	que	tem
grande	fluxo	de	dado,	às	vezes,	a	cliente-servidor	não	é	o	mais	ideal.
A	gente	pode	usar	de	microserviços	que	se	tornam	muito	mais	ágeis	em	vista	da	arquitetura
cliente-servidor	de	N	camadas,	mas	as	duas	suprem	as	necessidades	para	o	gerenciamento	de
um	 hospital	 tranquilamente.	 Não	 tem	 problema.	 Também	 vai	 do	 gosto	 de	 vocês	 e	 da
experiência	profissional	que	vocês	já	vêm	desenvolvendo	esses	patrões.
Voltando	 para	 os	 nossos	 slides,	 a	 arquitetura	 cliente-servidor	 é	 um	 tipo	 de	 rede	 de
computadores	em	que	vários	clientes	solicitam	e	recebem	arquivos	e	serviços	de	um	servidor
centralizado	por	meio	de	uma	conexão	local	ou	de	uma	internet.	Então,	vejam	só,	dependendo
do	tanto	de	camada	que	vocês	têm,	ou	seja,	de	tantos	servidores,	vai	estar	sempre	conectado	a
todos	os	clientes.	Todos	os	clientes	terão	acesso	a	esses	servidores	tranquilamente.
Ou	 é	 por	meio	 de	 uma	 rede	 local	 ou	 por	 internet,	 certo?	 Voltando	 para	 os	 nossos	 slides,	 a
escolha	 da	 arquitetura	 ideal	 depende	 das	 necessidades	 específicas	 do	 projeto	 em
desenvolvimento,	 incluindo	 o	 tamanho,	 a	 complexidade	 e	 os	 requisitos	 não	 funcionais	 de
escalabilidade	e	manutenibilidade.	Isso,	gente,	de	modo	geral	para	todos	os	tipos	de	projetos
que	 nós	 formos	 escolher	 uma	 arquitetura	 de	 projetos,	 nós	 temos	 que	 pensar	 na	 coleta	 de
requisitos	e	nesses	dois	requisitos	não	funcionais.	É	muito	importante.
Igual	que	eu	falei,	a	manutenção	precisa	ser	algo	fácil	e	ágil.	Não	adianta	nada	nós	fazermos
um	projeto	de	arquitetura	e	nós	não	conseguimos	depois	dar	manutenção.	Igual	que	eu	falei,
as	empresas	estão	em	constante	evolução.
Então,	as	nossas	arquiteturas	precisam	ser	adaptáveis.	Ou	seja,	ter	uma	manutenção	rápida	e
fácil,	 mas	 sem	 perder	 a	 segurança	 ali	 do	 projeto	 em	 si.	 Então,	 nos	 vemos	 nos	 próximos
capítulos.
Agora	 vamos	 falar	 sobre	 a	 arquitetura	 orientada	 a	 serviços	 e	 baseadas	 em	 microserviços.
Vamos	entenderum	pouco	o	que	se	refere	a	esses	serviços	e	também	a	aplicação	delas.	Vamos
lá	nos	nossos	slides.
E	aí	nós	temos	aqui,	o	que	seria	orientada	a	serviços?	Uma	arquitetura	orientada	a	serviços,	nós
podemos	chamar	de	SOA,	assemelha-se	a	uma	arquitetura	baseada	em	componentes,	porém
suas	partes	são	implementadas	como	serviços.	Ou	seja,	nós	vamos	fazer	a	implementação	dos
componentes	e	dos	seus	subcomponentes,	e	aí	nós	vamos	consumir	esses	serviços.	Ou	seja,
esses	serviços	nós	vamos	pegar,	vai	ter	interação	um	com	o	outro.
Se	 um	 falha,	 então	 ele	 pode	 continuar	 ali	 sendo	 manipulado	 normalmente.	 Vamos	 lá	 no
próximo	slide.	 Falando	um	pouco	 sobre	 interoperabilidade,	que	 seria	o	quê?	Vários	 sistemas
detectáveis	ou	descobertos,	a	componibilidade,	facilidade	em	relação	à	manutenção	e	também
na	atualização	do	software,	a	escalabilidade	do	sistema	também	é	importante.
Por	que	 isso?	Vai	 tornar	esse	sistema,	essa	arquitetura,	mais	 robusta	em	relação	ali.	 Então	a
SOA	vem	para	agregar	dentro	dessa	arquitetura.	Por	 isso	que	a	gente	fala	que	ela	usa	muito
essa	sigla.
Então	se	a	gente	 for	pensar	em	algo	ágil,	ou	quando	a	gente	 tem	vários	 tipos	de	sistemas	e
quer	fazer	algo	escalável,	então	a	gente	está	na	arquitetura	correta.	Então	nós	podemos	utilizar
essa	perfeitamente	e	nós	vamos	ter	sucesso	ali	em	relação	a	algo	robusto.	Para	entender	um
pouco	melhor,	vamos	para	o	próximo	slide.
Aí	 nós	 temos	 aqui.	 Além	 do	 SOA,	 nós	 temos	 uma	 variação	 do	 SOA,	 que	 é	 o	 SOAP,	 que	 é	 o
protocolo	 SOAP,	 o	 RASH	 e	 o	 RASHful.	 O	 RASH	 seria	 uma	 representação	 de	 transferência	 de
estado	de	dados.
Ou	seja,	ele	é	utilizado	em	grande	escala	quando	estamos	referindo	a	sistemas	de	hipermídia,
que	 vai	 estar	 utilizando	 a	web.	 Então	 eles	 devem	 funcionar	 constantemente.	O	 RASHful,	 por
exemplo,	ele	vai	enviar	as	requisições	via	internet	usando	ali	URLs,	especialmente	formatados,
e	recebe	como	resposta	um	playload	contendo	os	dados	em	XML	ou	HTML	ou	JSON,	que	são	os
formatos	que	nós	temos	de	documentos.
Aí	 o	 que	 acontece?	 Nesse	 caso	 aqui,	 estamos	 trabalhando	 com	web.	 Nesses	 três	 casos,	 são
protocolos	 muito	 famosos	 quando	 nós	 queremos	 fazer	 desenvolvimento	 web	 ou
desenvolvimento	mobile,	 que	 também	pode	estar	utilizando.	 Então	nós	utilizamos	esses	 três
tipos	de	protocolos.
O	SOAP,	que	é	o	mais,	vamos	dizer	assim,	vantajoso.	Aí	tem	o	RASH	e	o	RASHful.	O	RASH	e	o
RASHful	também	são	variações,	que	conforme	foram	surgindo	os	problemas	ali	da	web,	então
o	RASHful	vem	para	agregar,	que	seria	a	gente	utiliza	até	os	protocolos	HTTP,	que	é	quando	a
gente	 faz	a	 inclusão,	a	exclusão	de	documento,	a	alteração	desses	documentos,	que	é	o	get,
put,	delete,	que	nós	podemos	utilizar	ali	em	si	dentro	da	programação.
Então	 esse	 contexto	 vocês	 também	 já	 viram	 ali	 em	 algum	momento	 ao	 longo	 das	 aulas,	 já
estudaram	isso.	Então	a	gente	só	está	trazendo	que	nós	podemos	utilizar	esses	três	protocolos
dentro	das	arquiteturas.	E	aí,	o	que	eu	falo?	Nós	temos	ali	os	formatos	que	nos	resultam	o	quê?
A	interface	de	usuário,	que	é	os	documentos,	o	formato	XML,	HTML,	o	JSON.
Há	quem	diga	que	o	JSON	acaba	sendo	mais	eficiente	do	que	o	HTML,	porque	ele	é	um	pouco
mais	ágil	e	trata	melhor	com	um	fluxo	maior	de	dados	para	ser	apresentados.	E	claro	que	vai
depender	ali	do	projeto	que	vocês	forem	também	desenvolvendo.	Voltando	aqui	para	o	nosso
projeto,	aqui	a	arquitetura	é	baseada	em	microserviço?	Ela	acaba	sendo	um	pouco	semelhante
com	o	anterior	que	nós	vimos	agora.
A	 arquitetura	 de	 microserviços	 é	 um	 padrão	 arquitetural	 muito	 poderoso	 e	 ela	 vem	 sendo
utilizada	cada	vez	mais.	Ela	serve	para	desenvolver,	implantar	e	entregar	aplicações	e	serviços
de	 software	 atualmente,	 utilizando	 microserviços	 para	 deixar	 de	 uma	 maneira	 mais	 ágil.
Destaca-se	como	a	principal	forma	de	construir	aplicações	corporativas	e	de	missão	crítica.
Então,	 o	 que	 o	 de	 serviços	 talvez	 não	 consiga	 lidar	 devido	 à	 grande	quantidade	de	 fluxo	 de
dados	que	a	empresa	tem,	a	de	microserviços	ela	consegue.	Por	quê?	É	como	se	eu	estivesse
fazendo	 a	 repartição	 desses	 serviços.	 Então,	 eu	 consigo	 ter	 uma	 resposta	mais	 ágil	 do	meu
fluxo	de	dados.
Então,	ela	 traz	uma	missão	mais	 crítica.	Ou	seja,	 se	nós	 temos	projetos	grandes,	ou	 seja,	de
grande	 escala,	 então	 ele	 fica	 ali,	 igual	 eu	 falei,	 da	 Netflix,	 ele	 cabe	 perfeitamente	 e	 nós
utilizarmos	ele	sem	problema	nenhum.	Voltando	para	os	nossos	slides,	as	de	microserviços	são
serviços	granulares,	geralmente	com	uma	única	finalidade	e	fracamente	acoplados.
Ele	vai	facilitar	a	implementação	independente	e	a	escalabilidade	horizontal.	Então,	ou	seja,	nós
vamos	fazer	a	implementação	desses	microserviços	e	nós	não	vamos	ter	a	dependência	de	um
serviço	 do	 outro.	 Então,	 no	 caso	 do	 e-mail,	 se	 o	 e-mail	 for	 enviado	 ou	 não,	 vamos	 usar	 um
outro	exemplo	para	ficar	um	pouco	mais	claro.
Então,	pense	lá	que	nós	temos	o	e-mail	e	nós	temos	o	PicPay	da	vida,	que	é	onde	nós	fazemos
os	 pagamentos.	 Se	 a	 gente	 usa	 o	 PicPay	 para	 fazer	 o	 pagamento,	 ele	 pode	 enviar	 o	 meu
comprovante	para	o	e-mail	avisando	se	o	pagamento	foi	feito	com	sucesso	ou	se	o	pagamento
não	foi	feito	com	sucesso.	Mas	se	eu	pensar,	eu	realmente	preciso	dessa	ligação	do	PicPay	com
o	e-mail?	Não,	não	vai	interferir.
Porque	se	tiver	algum	atraso	no	PicPay	em	relação	ao	enviar	esse	e-mail	para	mim,	mas	eu	já
vou	saber	que	ele	foi	pago	dentro	do	aplicativo.	Então,	mesmo	que	ocorra	um	atraso,	não	vai
implicar	no	meu	processo	de	pagamento.	Então,	veja,	tem	uma	independência	ali	dos	serviços.
É	 isso	que	eu	estou	querendo	dizer.	Voltando	para	os	nossos	slides,	uma	desvantagem	dessa
arquitetura	 é	 que	 o	 aumento	 da	 complexidade	 no	 gerenciamento	 e	 no	 monitoramento.	 E,
havendo	a	necessidade	de	coordenar	múltiplos	serviços,	monitorar	as	interações	e	lidar	com	as
falhas	individuais,	é	significativamente	maior	do	que	em	uma	aplicação	monolítica.
A	aplicação	monolítica,	nós	podemos	dizer	que	é	quando	nós	temos	um	único	serviço.	Então,
pense	lá.	Então,	por	isso	que	ela	acaba	sendo	desvantagem.
Lembra	 que	 eu	 falei	 que	 elas	 são	 independentes,	 esses	microserviços?	 Pois	 é.	 Então,	 se	 um
falha,	 ou	 seja,	 se	 lá	 no	 e-mail	 não	 recebi,	 então	 eu	 vou	 ter	 que	 tratar	 ali	 daquele	 problema.
Agora,	você	imagina,	se	nós	tivéssemos	10	microserviços,	vamos	pensar	na	pior	das	hipóteses,
oito	microserviços	falham	ao	mesmo	tempo.	Eu	vou	ter	que	lidar	individualmente	com	cada	um
desses	serviços.
Então,	pode	ocorrer	uma	falha	na	manutenção.	Não	uma	falha,	mas	um	atraso.	Então,	talvez,
quando	eu	tenho	um	único	serviço,	eu	acabo	tendo	uma	maior	agilidade.
Então,	quanto	maior	for	o	nosso	problema	para	ser	aplicado	a	esse	tipo	de	arquitetura,	então
nós	vamos	ter	esse	problema.	Que	é	o	quê?	Tratar	de	solucionar	esses	problemas	com	diversos
tipos	de	microserviços	que	estão	ali	com	falha,	com	erros.	Certo?	Voltando	para	os	slides.
Aqui,	de	uma	maneira	sucinta,	nós	temos,	primeiro,	a	caixinha	de	requisição	do	cliente,	que	é	a
nossa	primeira	camada.	Então,	nós	temos	ali	o	que	o	cliente	está	solicitando	para	a	camada	de
API,	que	é	a	segunda	camada.	Essa	segunda	camada,	que	seria	a	interface	de	usuário.
E	aí,	a	interface	de	usuário,	ela	vai	estar	interagindo	com	os	microserviços,	que	nós	vamos	ter
quem?	Que	é	o	 serviço	1,	 que	 vai	 ter	 ali...	 Cada	microserviço	 vai	 ter	um	banco	de	dados,	 tá,
gente?	 Então,	 eu	 tenho	 o	 serviço	 1	 ligado	 na	 segunda	 camada,	 que	 é	 a	 camada	 de	 API.	 O
serviço	2,	serviço	3,	serviço	4,	serviço	5.	Então,	é	como	se	eu	estivesse	fazendo	a	ramificação	da
minha	aplicação	em	vários	serviços.	Por	isso	que	nós	temos	microserviços.
Então,	 eu	 tenho	vários	 tipos	de	 serviço.	Primeiro,	 eu	 tenho	enviar	 e-mail,	 eu	 tenho	o	PicPay,
confirmar	pagamento	e	assim	por	diante.	Então,	se	um	falha,	o	outro	vai	operar	normalmente.
Só	 que	 aí,	 se	 todos	 eles	 começarem	 a	 falhar,	 aí	 oque	 acontece?	 Nós	 vamos	 ter	 trabalho
redobrado,	 porque	 nós	 vamos	 ter	 que	 tratar	 de	 todas	 essas	 camadas.	 Camada	 não,	 por
exemplo.	 De	 todos	 esses	 serviços,	 certo?	 Então,	 é	 isso	 que	 traz	 ali,	 vamos	 dizer	 assim,	 um
diferencial,	que	seria	algo	mais	chato	de	vocês	lidarem	no	dia	a	dia,	vamos	dizer.
Porque	 vocês	 vão	 ter	mais	 trabalho	para	 solucionar	um	problema	ali	 dentro,	 utilizando	esse
tipo	 de	 arquitetura,	 arquitetura	 de	 microserviços.	 Voltando	 para	 os	 slides.	 E	 aí,	 uma
aplicabilidade	de	microserviços.
Nós	temos	gerenciamento	de	projetos	de	construção,	cada	microserviço	vai	operar	de	maneira
independente,	esse	comunicar	por	meio	de	APIs.	Ou	seja,	lembra	que	eu	peguei	e	falei?	Então,
nós	temos	ali	a	primeira	camada,	que	é	ali	o	cliente,	vamos	dizer,	que	vai	ter	acesso	à	API.	Essa
camada	de	API,	quem	que	é?	Essa	camada	de	API	é	a	interface	de	usuário,	gente.
Aí,	 essa	 interface	 de	 usuário,	 ela	 vai	 ter	 a	 comunicação,	 ela	 recebe,	 ou	 seja,	 o	 que	 o	 cliente
requisitou	para	a	camada	de	API,	então,	a	camada	de	API	vai	verificar	ali	dentro	dos	servidores,
qual	que	é	o	servidor	que	está,	ou	seja,	o	serviço,	perdão,	qual	que	é	o	serviço	que	está	com
essa	tarefa.	E	aí,	eu	quero	que	ele	me	retorne	para	plotar.
Este	arquivo	tem	mais	de	30	minutos.
Atualize	para	Ilimitado	em	https://turboscribe.ai/pt/	para	transcrever	arquivos	de	até	10
horas.
https://turboscribe.ai/pt/subscribed?ref=pdf_export_upsell
https://turboscribe.ai/pt/?ref=pdf_export_upsell