Arquitetura de Microsserviços - Arquiteturas de Software - Parte VI

Olá, sejam bem-vindos ao canal Engenharia de Software com ênfase ML. Eu sou professor Ganes Guedes e eu já atuo na área de modelagem de software há vários anos. Eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras de cursos técnicos sobre modelagem de software utilizando a linguagem OMR.

Na aula de hoje, eu vou dar continuidade ao tema de arquiteturas de software, dessa vez falando sobre arquitetura de microsserviços, que é uma arquitetura relativamente recente, que se caracteriza por ser composta por diversos componentes pequenos, cada um implementando um pequeno serviço independente. Então, vamos dar início à nossa aula. Então, como eu falei, arquitetura de microsserviços, ela é formada por uma estrutura de pequenos componentes que são capazes de se comunicar entre si.

Cada um desses componentes irá implementar um serviço específico. Essa arquitetura, ela permite a gerência de software e facilita a manutenabilidade, reusabilidade, extensibilidade e escalabilidade do sistema. Bom, antes de falar sobre a arquitetura de microsserviços, é necessário entender os conceitos da arquitetura monolítica e da arquitetura multicerviços.

Então, vamos falar sobre arquitetura monolítica, que é uma arquitetura bastante antiga, que já existe há muito tempo, e ela ainda tem as suas próprias qualidades. Ah, uma arquitetura monolítica, ela possui uma base de código eh localizada em único lugar. existe eh basicamente um um único eh grande arquivo de contendo código fonte.

Então, todos os serviços que compõe o sistema, eles estão organizados, logicamente, nesse código fonte, possuem um uma única instalação, um único ponto de instalação. Ah, a dependência entre os serviços era gerenciada dentro do mesmo ambiente de execução. E esse tipo de arquitetura costuma ser dividido logicamente em três partes: apresentação, regras de negócio e base de dados.

A divisão é lógica, mas todos eh todas essas eh características do software estão contidas no mesmo código. Bom, aqui nós temos uma figura representando arquitetura monolítica. Nós temos um navegador web externo que interage com a camada de apresentação ou visão.

Ah, depois nós temos a divisão lógica de negócio e finalmente nós temos a divisão de acesso a dados que, como não já disse, eles eh entram em contato, eh, interagem com uma base de dados responsável pela persistência das informações do sistema, persistência e recuperação. E é uma base de dados única. Bom, ah, aqui nós temos um exemplo de planejamento de recurso empresarial, enterprise research planning ou RP, utilizando arquitetura monolítica.

Então, nós temos uns módulos de compras, vendas, recursos humanos e contabilidade. Todos eles compondo ah a o software que eh está estruturado sobre uma arquitetura monolítica. e acessando um único banco de dados.

Bom, a arquitetura monolítica, ela também sua tem suas vantagens. Ela permite uma forte coesão da equipe, uma vez que todos trabalham no mesmo código. Existe uma padronização da tecnologia, já que o código, a base a base do código é única.

Não é possível utilizar tecnologias diferentes para partes do sistema, tem que ser uma tecnologia única. H, geralmente não há duplicidade de código e existe apenas um ponto, um único ponto de implantação do software. Bem, agora a arquitetura monolítica, ela também possui suas desvantagens.

Se um único módulo do sistema falhar, o sistema todo ficará comprometido, deixará de funcionar. H, além disso, eh, esse tipo de arquitetura costuma gerar uma base de código bastante grande. Ah, os novos integrantes nas equipes, eles possuem, costumam apresentar uma demora maior em se integrarem as a equipe de desenvolvimento, a até se acostumar com esse tipo de arquitetura, até entender ah o que está sendo desenvolvido, conseguir entender o código e os padrões de codificação até poder se integrar na equipe a uma demora maior.

Ah, esse tipo de arquitetura, ela pode gerar um desperdício de esforço, porque qualquer alteração, por mínima que seja, mesmo que seja simplesmente alteração de um texto e uma tela, irá implicar que todo código terá que ser recompilado e reimplantado, para poder para a alteração eh ser efetivada. Ah, além disso, esse tipo de arquitetura, ele dificulta muito a adoção de novas tecnologias, porque isso exige mudanças fortes no código. Uma mudança de tecnologia implica em alteração do código inteiro.

Todo código precisa se alter se adaptar à nova tecnologia. Ah, agora falando um pouco sobre a arquitetura de microsserviços, ela é composta por um conjunto de pequenos componentes. Esses componentes eles são desenvolvidos e implementados independentemente, ou seja, po eh mais de uma equipe pode trabalhar no projeto, cada uma desenvolvendo um ou mais componentes, independentemente esses componentes, eles podem ser facilmente substituídos.

Uma vez que eles são pequenos e concentrados num serviço único, cada componente, como eu falei, implementa um único serviço. Esse serviço ele deve ser pequeno, autônomo e com pouca responsabilidade. E cada componente pode trabalhar de maneira totalmente independente ou ele pode ah trocar solicitações, trocar informações, solicitar ou fornecer eh funções para os outros componentes.

Bom, ah, existe uma pergunta, quão pequeno um microsserviço deve ser? A recomendação é que eles sejam pequenos. H, basicamente o microsserviço ele deve suportar de maneira única uma determinada funcionalidade, uma determinada função.

Aqui nós temos o mesmo exemplo de RP, dessa vez utilizando arquitetura de microsserviços. Então, existe um um serviço para o módulo de compras, um serviço responsável pelas vendas da empresa, um serviço responsável pelo módulo de recursos humanos e um serviço responsável pela contabilidade. Notem que cada serviço possui o seu próprio banco de dados e eles se comunicam entre si, mas são independentes.

[Música] Ah, arquitetura de microsserviços apresenta diversas vantagens, entre as entre as quais cada serviço, ele provê uma uma fronteira bem definida entre os módulos. Sabe-se claramente qual é a função de cada serviço e se evita que um serviço invada a a função de outro. Ah, além disso, ah, cada serviço pode ser escrito em uma linguagem de programação independente, aliás, diferente, porque eles são independentes entre si.

Então eu posso ter alguns componentes escritos numa linguagem, outros componentes escritos em outras e eu posso adicionar novos componentes, novos serviços eh escritos numa terceira linguagem se isso for considerado válido. Então, ah, o software não precisa estar amarrado, ligado a uma tecnologia única. Além disso, uma outra vantagem, cada serviço pode ser administrado por uma equipe diferente.

Isso é útil porque ah permite o desenvolvimento paralelo. Então, as funcionalidades do sistema podem ser distribuídas a várias equipes. Ah, uma vez que os serviços são pequenos, ah, o tempo de aprendizado e integração na equipe costuma ser menor.

Existe uma maior heterogeneidade tecnológica, como eu falei, cada microsserviço pode ser inscrito numa tecnologia diferente, se isso for considerado útil. Ah, novas tecnologias, então, podem ser utilizadas sem problemas. Então isso permite o uso de ferramentas certas para cada serviço.

Não é necessário utilizar uma única tecnologia para desenvolver o software inteiro. A a arquitetura de microsserviços, ela fornece uma maior resiliência. Isso significa que o software ele é bastante, costuma ser bastante confiável em termos que ele tem uma capacidade maior de recuperação de falhas.

Quando ocorre uma falha, ela pode ser facilmente isolada para que seja corrigida e os demais serviços não são afetados. Normalmente eles podem seguir funcionando. Então isso permite uma degradação amena do software quando ocorre uma falha e também permite um tempo de recuperação maior, uma vez que é necessário recuperar apenas um serviço.

Então esse tipo de arquitetura, ela é bastante adequada para sistemas críticos que exigem um nível de confiabilidade muito alto. Outra vantagem, essa arquitetura, ela permite escalabilidade bastante fácil entre os módulos do sistema. Ahã.

Isso significa que diferente das aplicações monolíticas, que ou se escalava tudo ou não se escalava nada, na arquitetura de microsserviços é possível eh escalar um a um único microsserviço ou um pequeno conjunto de microsserviços se isso for considerado ah útil. Então, cada serviço pode ser escalado separadamente de acordo com a demanda. Então eu posso de repente escalar muito o microsserviço enquanto outros permanecem como estavam originalmente.

Ainda eh é mais fácil implantar e atualizar um sistema baseado na arquitetura de microsserviços. Eu posso atualizar apenas um serviço específico, posso implantar um um serviço novo a sem precisar afetar os outros serviços. Eu posso fazer várias rodadas de atualizações em tempos diferentes e eu não preciso que os outros serviços estejam concluídos para subir as atualizações.

Eu posso ir eh adicionando serviços ao longo do tempo à medida que o sistema vai sendo construído. Agora, a arquitetura de microsserviços também possui suas desvantagens, principalmente quando essa arquitetura é aplicada para sistemas distribuídos, o que é comum quando se usa arquitetura de microsserviços. O problema é que sistemas distribuídos eles possuem uma dificuldade de programação maior do que os sistemas de outras de outros tipos.

E com relação às chamadas remotas que são necessárias entre os serviços, elas podem eventualmente ser lentas e elas podem elas têm um nível de falha um pouco maior, elas correm o risco de de apresentarem mais falhas. Além disso, nós temos o problema de consistência virtual, que ocorre sobre sistemas que trabalham, que foram construídos com arquitetura de micosserviços. O que é a consistência eventual?

A consistência eventual significa que as bases de dados eventualmente estarão consistentes entre si, mas não necessariamente eh de forma imediata. Uma vez que cada serviço tem o seu próprio o seu próprio banco de dados, a atualização de informações entre os microsserviços pode ser um pouco demorada. Então, às vezes, essa consistência eventual pode ocorrer e para sistemas que precisam de uma atualização online de todas as suas informações, uma atualização imediata de todas as suas informações, talvez uma arquitetura de microsserviços pode não ser a mais adequada, a não ser que se encontre uma forma de eh que os microsserviços sempre estejam ah, trocando informações de tal maneira que as suas que as suas informações possam ser atualizadas em cada uma das bases de dados.

Então, a consistência eventual ela pode ser difícil de manter ah em aplicações de microsserviços. Eh, é preciso um maior gerenciamento da consistência virtual, porque os dados eles vão ser mantidos em vários locais diferentes. Então, eh, a consistência dos dados pode demorar um pouco e dependendo do sistema, ele pode, essa arquitetura, essa característica não pode ser bem-vinda.

Pode ser bem-vinda, pode não ser adequada. Ah, nós temos também uma complexidade operacional. Quando se trata de sistemas distribuídos, eh, é necessário uma equipe de operação madura para gerenciar muitos serviços.

Eh, cada serviço também pode ter o seu próprio conjunto de versões. Então, é preciso um sistema de versionamento particular serviço, um controle de versionamento particular para cada serviço. E também uma vez que são vários ah microsserviços e eles podem estar distribuídos em múltiplos servidores, às vezes até distantes geograficamente, podem haver diversos pontos de implantação para uma aplicação.

Então são pontos de atenção com relação à arquitetura de microerviços. E é preciso um certo nível de atenção. Eh, no início de um projeto pode haver uma certa dificuldade em determinar todas as fronteiras e as responsabilidades dos serviços.

E é preciso cuidado para que os serviços permaneçam pequenos, permaneçam micros. Eles não devem eh abarcar mais processos do que deveriam. Aqui nós temos uma arquitetura de microsserviços aplicada para um sistema de controle de vídeos no estilo do YouTube.

Essa arquitetura foi construída utilizando o diagrama de pacotes da UML. Então aqui nós temos três microsserviços. O primeiro da esquerda para a direita representa o serviço de adição de vídeos.

Quando um produtor de vídeos sobe os seus vídeos na plataforma, eu tenho um serviço de visualização de vídeos que permite que os usuários do sistema visualiz a a visualização desses vídeos, juntamente com anúncios associados aos vídeos, ela precisa ser computada. Ah, e nós temos um um serviço de pagamento de visação que no momento que um canal, um conjunto de vídeos de um canal, ele produz uma quantidade mínima de horas de visualização, ã, ele recebe um pagamento por isso. Ah, então aqui se utilizou o diagrama de pacotes da OML.

Nós temos então três grandes pacotes, cada um representando três serviços. Lembrando que essa que esse sistema ele está simplificado devido ao tamanho que esse tipo de diagrama gera. Ah, obviamente haveriam mais serviços e eventualmente haveriam mais eh classes internas.

Então, cada serviço foi representado como um pacote. Eu tenho um pacote por serviço de adição de vídeos, um pacote para visualização de vídeos, outro pacote para pagamento e visualização. Cada banco de dados de cada serviço também foi representado com um pacote.

Notem que dentro de cada pacote de serviço existem quatro subpacotes, onde cada um deles ah assume uma uma função da do serviço. Então eu tenho um pacote responsável pela a apresentação ou visão daquele serviço, ou seja, basicamente o front end, a interface com o usuário. Eu tenho um pacote que representa o controle de eventos que ocorre sua apresentação, um pacote que contém a lógica do negócio e um pacote responsável pela persistência, basicamente contendo classes D, que irá se comunicar com a base de dados daquele serviço específico.

Ah, como os microsserviços eles costumam ser relativamente simples, na verdade poderia haver um pacote somente de negócio, abarcando o controle e as classes da entidade, mas aqui eu preferi dividir. Nota então que internamente cada eh microsserviço pode se comportar com uma pequena eh arquitetura em camadas. Bom, então cada um desses eh microsserviços possui as suas classes necessárias a implementação do serviço.

Vocês podem notar que em alguns casos essas classes se repetem. Por exemplo, entre o processo de entre o serviço de adição de vídeo e o processo de pagamento e visualização, ã, a classe vídeo e produtor estão repetidas, tá? Então isso pode eventualmente acarrectar a o problema de consistência virtual, mas para esse sistema específico isso não seria um problema grave.

Isso aí a a consistência poderia ser razoavelmente administrada. Bom, então isso aqui é um pequeno exemplo de arquitetura de microsserviços utilizando ah o diagrama de pacotes da OML. Ah, então a adição de vídeo, ela vai ter uma interface para visão para para adição de vídeos.

Obviamente poderia ter mais de uma, se fosse considerar necessário. Tem uma classe para controlar os eventos dessa nessa interface. Eu tenho classe de entidade.

Aqui no caso da adição, eu trabalho com as classes de produtor e vídeo, que basicamente determina quem é o produtor eh de cada vídeo e aí armazena informações a respeito dos vídeos produzidos por ele. Depois nós temos uma camada de persistência com classes do tipo D, que tem a lógica de persistência e que se comunicam com a base de dados, fazem a persistência, contém a lógica para persistir a os os objetos produzidos dentro dessa base de dados. Da mesma forma, a visualização de vídeos segue a mesma lógica.

tem uma camada de apresentação, uma camada de controle, uma camada de negócio. Os vídeos não são exatamente, aliás, os o as classes entidades não são exatamente as mesmas, mas vídeo se repete, mas adiciona-se anúncio, tá? Na própria classe de vídeo vão ter atributos para determinar as horas que eles foi visualizado, as horas de anúncio que ele que foram recebidas, esse tipo de coisa.

também tem uma camada de persistência igual ao outro pacote. Ã, nós temos também um pacote de visualização que também contém uma camada de apresentação, uma camada de controle, uma camada de negócio. Só as classes de entidade eh não são exatamente as mesmas, algumas são.

No caso, a a classe de vídeo é praticamente a mesma, certo? Ela é re ela é implementada novamente em cada serviço, mas eh é necessário a transmissão de informações para atualização do banco de dados particular de cada serviço. Então a o serviço de pagamento e visualizações, como o nome já diz, ele gerencia o pagamento de visualizações do conjunto de vídeos de um produtor quando ele atingir um determinado número de horas.

Bom, hã, falar um pouquinho sobre o problema de comunicação com microsserviços. Isso é um problema original que já foi superado, mas podia acontecer de muitos eh de muitas páginas cliente eh fazerem muitas solicitações ah aos mesmos a um a um mesmo conjunto de serviços e isso deixar ah a aplicação lenta. Então, uma única página web, ela pode eventualmente precisar exibir informações que vão ser oriundas de muitos serviços distintos.

Então, e se o frontend ele fizer requisições do tipo HTTP REST diretamente a cada um desses serviços, o número de chamadas pode aumentar significativamente e isso pode acorretar problemas como alta latência sobre carga de rede ou experiência do usuário comprometida. Vamos falar um pouquinho sobre cada uma delas. Com relação à alta latência, sempre que é feita uma requisição individual, isso adiciona um certo tempo de resposta.

E se essas requisições forem muitas, isso irá prejudicar a velocidade de carregamento da página. Também a sobrecarga de rede. No momento que há múltiplas chamadas simultâneas, obviamente o tráfego irá aumentar e isso pode causar eh eventualmente falhas parciais.

E nós temos a experiência do usuário comprometida, ou seja, o usuário ele fica insatisfeito porque as páginas ficam lentas, eventualmente com dados incompletos ou faltantes, e isso vai gerar uma insatisfação do cliente. Ele vai se sentir frustrado e vai perder a confiança no sistema. Bom, e qual é a solução para esse problema de comunicação?

Para solucionar esse problema, se passou a utilizar APIs Gateways, que são um ponto intermediário entre as páginas clientes e os serviços oferecidos pelo sistema. Então, API Gateway, ela fornece APIs, ou seja, application program interfaces, interface de programa de aplicação para ah os ah os clientes que fazem solicitações ao serviço. Ah, então como eu falei, uma API Gateway, ela se localiza entre os clientes e os microserviços.

é um um elemento intermediário e ela possui um conjunto de APIs adaptadas para necessidades de diferentes clientes. Ah, com relação aos mecanismos de comunicação, ah, bom, como eu falei, como vocês já viram, a arquitetura de microsserviços, ela possui vários serviços e e vários e vários desses serviços eles são executados em diferentes processos e para isso eles precisam utilizar comunicação entre processos. ou seja, interprocess communication ou IPC.

Então, alguns tipos de comunicações são HTTP síncrono e mensagens assíncronas. Vamos falar um pouco sobre cada uma delas. Com relação ao mecanismo de comunicação HTTP Síncrome, o grupo de de de mecanismo de comunicação HTTP5, porque pode-se utilizar mecanismos como rest, ou seja, representational state transfer ou transferência de estado representacional ou SOP, que significa simple object protocol, protocolo de acesso de objeto simples.

Então são mecanismos de comunicação do tipo HTTPCR. São opções simples, conhecidas e que são passíveis de serem gerenciadas por firewalls e que trabalham com comunicação no formato request reply. Aqui nós temos um exemplo, ah, utilizando BPMN para representar o mecanismo de comunicação HTT HTTP síncrono do tipo HTTP rest.

Aqui nós utilizamos uma aplicação angular. Aqui eu coloquei um comentário, uma aplicação angular. É uma plataforma e framework que permite a construção de interface de aplicação ã do tipo single page applications ou aplicações de página única.

Ele, esse tipo de aplicação utiliza HTML, utiliza CSS e sobretudo JavaScript. Bom, aqui nesse exemplo, um exemplo simples, nós temos dois microsserviços, um microsserviço para controle de notas e o microsserviço para controle de aluno. A aplicação ela faz uma solicitação do tipo get notas, ou seja, ela tá pedindo a recuperação das notas de um determinado aluno.

Isso é capturado pelo Gateway, que repassa esse pedido pro microsserviço de controle de aluno, de controle de nota, que irá consultar a sua base de dados, recuperar a nota do aluno em questão. Ah, e ele vai precisar de outras informações, de outros detalhes a respeito do aluno. Então, ele vai fazer uma requisição para buscar esses detalhes na no outro microsserviço de controle de aluno que tem sua própria base de dados.

Então, eh, a partir dessa requisição, esse microsserviço irá, eh, recuperar as informações do aluno, repassá-la pro microsserviço de controle de nota por meio de uma mensagem do tipo responsa e o microsserviço, então, irá retornar a nota e os dados do aluno pro gateway, que irá que irá responder, irá repassar paraa aplicação. Ah, nós também temos um outro mecanismo de comunicação que é se baseia em mensagens assíncronas, que como nome já diz é um mecanismo assíncrono baseado em mensagens, ã, como por exemplo, um message broker que seja compatível com o protocolo AMQP, ou seja, advanced message quim protocolou o protocolo de lista de mensagens avançado. Então esse Message Broker ele age com Midware, um ah software intermediário para desacoplar as mensagens dos produtores, das mensagens do de das mensagens dos consumidores.

Ah, então esse broker, como já falei, ele atua como intermediário. Ele enfilera e armazena as mensagens esperando o momento em que elas possam ser processadas pelos ah consumidores. E esse broker, esse intermediário, ele garante confiabilidade e tolerância a falhas na comunicação entre os serviços.

Ah, um tipo de desse mecanismo de comunicação é o é a mensageria, que é um conceito que estabelece que sistemas distribuídos possam se comunicar eh por meio de troca de mensagens. Essas mensagens elas são gerenciadas por um message broker, um intermediário de mensagens, ã, ou seja, um servidor ou um módulo de mensagens, um um servidor responsável por gerir essas mensagens. Ah, alguns servidores de mensageria podem ser, como exemplo, podem ser Rapt MQ, o Apch Kafka e o Active MQ, entre outros.

Então aqui nós temos o exemplo de mecanismo de comunicação de processo utilizando mecanismo de comunicação por mensagem assíncrona. Então, nós temos uma aplicação onde um professor vai inserir uma nota no no sistema. Isso será recebido pelo Gateway, que irá repassar pro microsserviço de controle de notas.

Esse microsserviço irá atualizar a nota no seu banco de dados. Ah, e paralelamente ele irá solicitar a um eh broker de mensageria que transmita uma mensagem que irá ser recebida pelo microsserviço de controle de e-mail, que irá enviar uma mensagem para o aluno avisando que a sua nota foi atualizada. E enquanto isso, o microsserviço de controle nota avisa ao gateway que a nota foi atualizada no sistema e esse e essa informação é repassada para a aplicação.

Bom, agora nós vamos falar sobre quando usar a arquitetura de microsserviços. Essa arquitetura ela é mais útil quando, primeiro, há domínios claramente divisíveis para os microsserviços. Se não é claro definir as fronteiras entre os microsserviços, fica difícil aplicar essa arquitetura.

Ahã. Em se tratando de sistemas críticos que exigem alta confiabilidade, como já foi falado, essa arquitetura costuma ser útil. E também essa aplicação, ela é adequada quando existe uma tolerância à consistência virtual, pelo menos em parte do sistema.

Se não há tolerância à consistência virtual, se as atualizações entre entre as bases de dados tm que ser imediata, essa arquitetura pode não ser a mais adequada. Ainda outras características que podem ser consideradas válidas para esse tipo de arquitetura é que seja possível eh que seja necessário ou que seja desejável que se possa escalar parte do sistema de maneira independente, enquanto outras permanecem sem escalabilidade durante um determinado tempo. E também eh quando for possível alocar equipes autônomas para desenvolver serviços destinos.

Então, há isso, isso são características que eh são promissoras paraa aplicação da arquitetura de microsserviços. Então, nós concluímos mais essa aula sobre arquitetura de software. Eu espero que vocês tenham considerado essa aula útil.

Espero que vocês tenham gostado dessa aula. Se vocês gostarem, eu peço que vocês curtam o canal, compartilhem com quem possa ter interesse. E se vocês ainda não estão inscritos, eu peço que se inscrevam no canal.

Obrigado pela atenção. Nós nos vemos na próxima aula.