31/10/2021

Dicas de Arquitetura de Sistema

Por wcalazans


Por algumas vezes trabalhando com arquitetura de soluções de Tecnologia da Informação, aprendi que definir o problema com perguntas esclarecedoras, é a chave de tudo:

  • Definir os casos de uso,
  • Objetivos do sistema,
  • O quê é necessário para o sucesso do projeto?
  • Quais são as restrições,
  • Confiabilidade desejada,
  • Redundância,
  • Estabilidade,
  • Segurança,
  • Disponibilidade % up-time,
  • Simplicidade vs. Complexidade,
  • Manutenção e Consistência.

Lembra do Teorema de Cap? Aplique em seus projetos.

Uma vez que o componentes necessários ao projeto seja definido com base nas respostas das questões anteriores, os próximos passos são as definições de:

  • WebServer,
  • Load balancer,

Esses elementos são pontos de falha do projeto e devem receber total atenção.
Para design de sistema móvel, é importante ainda pensar em:

  • Acesso offline,
  • Cache,
  • Como ocorre a atualização das páginas, e
  • Otimização round trip.

Como escalar servidores da web? >Balanceadores de carga

Load Balancers Architecture
  • É possível usar um ou vários balanceadores de carga em paralelo,
  • Também é possível dividir as aplicações pelos recursos, dessa forma, pode-se equilibrar cada recurso em um grupo de servidores.

Como dimensionar o banco de dados? > Cache

Depois de projetar a distribuição de cargas e balancear os servidores web, é preciso pensar no próximo problema: a Base de dados!

Data Base

Uma boa prática é armazenar em cache os resultados do banco de dados; para isso seria importante adicionar uma camada de cache extra entre os servidores e o banco de dados:

Cache Level

Pode-se usar o cache na memória ou salvar em disco. Por exemplo, o Redis permite salvar conteúdo/ativos do cache da memória no disco (mas lembre-se: o disco é muito mais lento do que a memória). Existem duas abordagens básicas a se seguir: write-back cache ou write-through cache.

Outra forma de dimensionar o banco de dados é vertical e horizontalmente. Para saber mais, veja aqui.

Como preparar nossos ativos para entregar mais rápido em todo o mundo? > CDNs

A CDN (Content Delivery Network ou Rede de Distribuição de Conteúdo) é muito boa para entregar ativos (js, png, mpeg4, etc) de forma muito rápida, porque ela geralmente estará mais próxima do usuário, fazendo com este, tenha uma experiência de usabilidade e navegação no site, e-commerce ou aplicação, mais fluida e dinâmica.

A arquitetura de CDN irá ajudar sua aplicação da seguinte maneira: o usuário acessa a URL da CDN, o servidor CDN verifica se seu servidor, mais próximo ao requisitante, possui os ativos requisitados; se ele tiver, fará a entrega dos ativos; caso contrário, o servidor CDN acessará o servidor que possui o ativo E carregará e salvará o ativo em seu cache. Então, na próxima consulta a este conteúdo/ativo, será usado o ativo armazenado em cache no servidor CDN.

Existem duas estratégias básicas de CDNs: PULL ou PUSH.

Estratégia Pull:

Nessa técnica, o usuário acessa a URL da CDN e o servidor CDN verifica se o servidor mais próximo à requisição, possui o ativo; caso contrário, o servidor acessará o servidor origem, que possui o ativo; a CDN irá carregar o ativo e salvá-lo em seu cache. Então, da próxima vez que houver uma consulta a este ativo, será usado o ativo armazenado no cache da CDN. Isso permite uma experiência mais dinâmica, como citado anteriormente.

Estratégia Push:

Nessa técnica, os arquivos são carregados no servidor CDN, portanto, a primeira solicitação será mais rápida, mas custará mais, porque você precisará pagar pelo armazenamento carregado. Uma técnica comum é usar domínios personalizados ao lidar com CDN. O que você precisa fazer é configurar sua CDN para acessar seu provedor de CDN. No momento de pagar por um certificado SSL, você poderia pagar por *.myapp para estar pronto para lidar com diferentes subdomínios, evitar problemas de CORS, e também atuar como balanceador manual de suas solicitações.

Atualização de conteúdo na CDN

Uma técnica comum para atualizar seu conteúdo na sua CDN é anexar um parâmetro de consulta ao seu ativo para criar uma versão dele, como por exemplo: cnd.myapp.com/scripts/app.js?version=1 neste caso, assim que precisar atualizar seus arquivos, você pode mudar a versão do ativo. Isso ajuda a criar uma abordagem de controle de versão (versionamento) automática ou automatizada, dependendo de como irá usá-la.

Dicas de design de API

Finalizando o post, vamos falar sobre APIs e quais são os padrões de comunicação entre o cliente e o back-end?
As APIs são um conjunto de padrões que fazem parte de uma interface e que permitem a criação de plataformas de maneira mais simples e prática para desenvolvedores. A partir de APIs é possível criar softwares, aplicativos, programas e plataformas diversas. Por exemplo, apps desenvolvidos para celulares Aindroid e IOS são criados a partir de padrões definidos e disponibilizados pelas APIs de cada sistema operacional. Existem diferentes estratégias e abordagens; e o cliente pode ser um navegador da web e IOS ou Andriod. E esses clientes podem ser comunicados ao back-end do seu servidor web.

O objetivo das APIs é tornar a experiência mais simples possível e uma maneira de ser simples e comum é fazer CRUDs. E aqui você encontra um conjunto de práticas recomendadas sobre APIs. Além disso, você precisa pensar sobre suas Entradas e Saídas, e como passar os parâmetros corretos para suas APIs. Lembre-se de usar sempre uma chave para autenticação segura, um mecanismo muito comum é usar tokens JWT. Outra consideração é decidir se o aplicativo será um driver cliente ou driver servidor. Por exemplo, se o APP for uma UX muito importante ou tenha necessidade crítica de desempenho, a aplicação precisa ser mais responsiva e haverá necessidade de desenvolvimento nativo para a plataforma desejada. As limitações incluem necessidade de duplicar o código lógico para cada nova aplicação nativa. Por exemplo, no caso de você precisar algo muito específico para Android, ou para IOS, etc. Além disso, outra limitação para o aplicativo móvel, é que geralmente um aplicativo de driver de servidor os recursos de memória e CPU são realmente limitados.

Outra consideração importante é dividir os pedidos de requisições ao servidor; por exemplo: poderíamos fazer um único pedido grande ao servidor e isso levaria vários milissegundos / segundos de resposta; ou podemos dividir esse pedido gigante em vários pedidos pequenos, para fazer um carregamento progressivo com melhor autonomia de resposta do servidor.

</>

Conte aos amigos