Arquitetura de Sistemas para Internet
Requisitos Básicos
- Protocolo HTTP (HyperText Transfer Protocol) É um protocolo de camada de aplicação no modelo de conjunto de protocolos da Internet para sistemas de informação hipermídia distribuídos e colaborativos.
- Proxy Em redes de computadores, um servidor proxy é um aplicativo de servidor que atua como intermediário entre um cliente que solicita um recurso e o servidor que fornece esse recurso.
- Rest (Representational state transfer) A transferência de estado representacional é um estilo de arquitetura de software que foi criado para orientar o projeto e o desenvolvimento da arquitetura para a World Wide Web. REST define um conjunto de restrições de como a arquitetura de um sistema de hipermídia distribuído em escala da Internet, como a Web, deve se comportar.
- Docker É um conjunto de produtos de plataforma como serviço que usam virtualização no nível do sistema operacional para entregar software em pacotes chamados contêineres. Os contêineres são isolados uns dos outros e agrupam seus próprios softwares, bibliotecas e arquivos de configuração; eles podem se comunicar uns com os outros por meio de canais bem definidos
- Computer programming A programação de computadores é o processo de realizar uma computação específica, geralmente projetando/construindo um programa de computador executável. A programação envolve tarefas como análise, geração de algoritmos, precisão de algoritmos de perfil e consumo de recursos, e a implementação de algoritmos.
Tipo de Arquitetura: Monolito
É uma aplicação única, geralmente começa com um único serviço e vai ganhando funcionalidades ao longo do tempo. São várias instânicas da mesma app executadando no servidor, consumindo um ou mais banco de dados locais, e seus clientes (web, mobile) acessando-a através de um Proxy HTTP.
Vantagens
- Complexidade Baixa
- Monitoramento Simplificado
Desvantagens
- Stack única (tecnologia)
- Recursos Compartilhados
- Acoplamento
- Escalabilidade mais complexa
Tipo de Arquitetura: Microservices
Existem diversas maneiras, meios e estratégias para implementar uma arquitetura com microservices.Cada microserviço tem uma única responsabilidade, representa uma única operação e podem conversar entre si ou com apps externas.
O Proxy HTTP é o responsável por encaminhar as solicitações que chegam para os microservices corretos.
Conforme o aumento de microservices ocorre dentro de um cluster, a complexidade aumenta e podemos ter uma arquitetura caótica.
Exemplo com chamada direta entre os microservices.
- Vantagens
- Stack dinâmica
- Escalabilidade simples
- Desvantagens
- Acoplamento
- Monitoramento mais complexo
- Provisionamento mais complexo
Exemplo sem chamada direta entre os microservices
A comunicação é totalmente assíncrona, via mensagens pelo MessageBroker, sendo este o único ponto de comunicação.Importante ressaltar aqui as operações ficam refém do MessageBroker
- Vantagens
- Stack dinâmica
- Escalabilidade simples
- Desacoplamento
- Desvantagens
- Monitoramento mais complexo
- Provisionamento mais complexo
Exemplo sem chamada direta entre os microservices
Toda a comunicação é realizada através de um gerenciador de pipeline, onde o Proxy HTTP vai passar a requisição para o gerenciador de pipeline, ao invés de passar diretamente para o microservice, isto é útil para operações que precisam seguir determinados passos.O gerenciador de pipeline precisar estar apto a tratar as requisições caso algum microservice quebre, realizar tentativas ou trabalhar com rollback para que não haja inconsistências nas operações.
- Vantagens
- Stack dinâmica
- Escalabilidade simples
- Desacoplamento
- Complexidade Menor Como não temos mais a comunicação assíncrona entre os serviços (ex. 2), fica muito mais fácil saber qual é o fluxo completo de determinadas operações, facilita identificar as falhas.
- Desvantagens
- Provisionamento mais complexo
- Plataforma inteira depende do gerenciador de pipeline O gerenciador de pipeline pode vir a se tornar um gargalo na app.