{"id":80035,"date":"2020-05-02T13:42:54","date_gmt":"2020-05-02T11:42:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny"},"modified":"2020-05-02T13:42:54","modified_gmt":"2020-05-02T11:42:54","slug":"udobnye-arhitekturnye-patterny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/udobnye-arhitekturnye-patterny","title":{"rendered":"Padr\u00f5es arquiteturais convenientes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1, Habr!<\/p>\n

<\/p>\n

\u00c0 luz dos eventos atuais devido ao coronav\u00edrus, v\u00e1rios servi\u00e7os online come\u00e7aram a receber uma carga aumentada. Por exemplo, uma das redes de varejo no Reino Unido simplesmente parou o site de pedidos online<\/a><\/noindex>, pois n\u00e3o havia capacidade suficiente. E nem sempre \u00e9 poss\u00edvel acelerar o servidor apenas adicionando hardware mais potente, no entanto, \u00e9 necess\u00e1rio processar as solicita\u00e7\u00f5es dos clientes (ou eles ir\u00e3o para os concorrentes).<\/p>\n

<\/p>\n

Neste artigo, eu irei contar brevemente sobre as pr\u00e1ticas populares que permitir\u00e3o criar um servi\u00e7o r\u00e1pido e resiliente. Entretanto, entre os esquemas de desenvolvimento poss\u00edveis, selecionei apenas aqueles que agora s\u00e3o f\u00e1ceis de utilizar.<\/strong>Para cada item, voc\u00ea j\u00e1 possui bibliotecas prontas ou tem a possibilidade de resolver a tarefa utilizando uma plataforma em nuvem.<\/p>\n

<\/a><\/noindex><\/p>\n

Escalonamento horizontal<\/h1>\n

<\/p>\n

O item mais simples e conhecido. Condicionalmente, as duas esquemas de balanceamento de carga mais comuns s\u00e3o o escalonamento horizontal e vertical. No primeiro caso,<\/a><\/noindex> voc\u00ea permite que os servi\u00e7os operem em paralelo, distribuindo assim a carga entre eles. No segundo,<\/a><\/noindex> voc\u00ea encomenda servidores mais potentes ou otimiza o c\u00f3digo.<\/p>\n

<\/p>\n

Para exemplificar, vou usar um armazenamento de arquivos em nuvem abstrato, ou seja, algo como OwnCloud, OneDrive, e assim por diante.<\/p>\n

<\/p>\n

A imagem padr\u00e3o desse esquema \u00e9 abaixo, no entanto, ela apenas demonstra a complexidade do sistema. Precisamos encontrar uma forma de sincronizar os servi\u00e7os. O que acontece se o usu\u00e1rio salvar um arquivo de um tablet e, em seguida, quiser visualiz\u00e1-lo a partir de um telefone?<\/p>\n

<\/p>\n

\"Padr\u00f5es
\nA diferen\u00e7a entre as abordagens: no escalonamento vertical, estamos prontos para aumentar a capacidade dos n\u00f3s, enquanto no horizontal \u2014 adicionamos novos n\u00f3s para distribuir a carga.<\/p>\n

<\/p>\n

CQRS<\/h1>\n

<\/p>\n

Command Query Responsibility Segregation<\/a><\/noindex> \u00e9 um padr\u00e3o bastante importante, pois permite que diferentes clientes n\u00e3o apenas se conectem a diferentes servi\u00e7os, mas tamb\u00e9m recebam correntes de eventos id\u00eanticas. Seus benef\u00edcios n\u00e3o s\u00e3o t\u00e3o evidentes para um aplicativo simples, mas s\u00e3o extremamente importantes (e simples) para um servi\u00e7o sobrecarregado. Sua ess\u00eancia \u00e9: fluxos de dados de entrada e sa\u00edda n\u00e3o devem se cruzar. Ou seja, voc\u00ea n\u00e3o pode enviar uma solicita\u00e7\u00e3o e esperar uma resposta, em vez disso, voc\u00ea envia uma solicita\u00e7\u00e3o para o servi\u00e7o A, mas recebe a resposta no servi\u00e7o B.<\/p>\n

<\/p>\n

O primeiro b\u00f4nus dessa abordagem \u00e9 a capacidade de desconectar (em um sentido amplo) durante a execu\u00e7\u00e3o de uma requisi\u00e7\u00e3o longa. Para exemplificar, vamos considerar uma sequ\u00eancia mais ou menos padr\u00e3o:<\/p>\n

<\/p>\n

    \n
  1. O cliente enviou uma requisi\u00e7\u00e3o ao servidor.<\/li>\n
  2. O servidor iniciou o processamento longo.<\/li>\n
  3. O servidor respondeu ao cliente com o resultado.<\/li>\n<\/ol>\n

    <\/p>\n

    Vamos imaginar que, no item 2, aconteceu uma quebra de conex\u00e3o (ou a rede reconectou, ou o usu\u00e1rio navegou para outra p\u00e1gina, interrompendo a conex\u00e3o). Nessa situa\u00e7\u00e3o, ser\u00e1 dif\u00edcil para o servidor enviar a resposta ao usu\u00e1rio com as informa\u00e7\u00f5es sobre o que foi processado. Ao aplicar CQRS, a sequ\u00eancia ser\u00e1 um pouco diferente:<\/p>\n

    <\/p>\n

      \n
    1. O cliente se inscreveu para receber atualiza\u00e7\u00f5es.<\/li>\n
    2. O cliente enviou uma requisi\u00e7\u00e3o ao servidor.<\/li>\n
    3. O servidor respondeu 'requisi\u00e7\u00e3o recebida'.<\/li>\n
    4. O servidor respondeu com o resultado atrav\u00e9s do canal do 'item 1'.<\/li>\n<\/ol>\n

      <\/p>\n

      \"Padr\u00f5es<\/p>\n

      <\/p>\n

      Como pode ser visto, o esquema \u00e9 um pouco mais complexo. Al\u00e9m disso, a abordagem intuitiva de request-response aqui est\u00e1 ausente. Contudo, como \u00e9 evidente, a quebra de conex\u00e3o durante o processamento da requisi\u00e7\u00e3o n\u00e3o levar\u00e1 a um erro. Al\u00e9m disso, se o usu\u00e1rio estiver realmente conectado ao servi\u00e7o de v\u00e1rios dispositivos (por exemplo, de um celular e de um tablet), \u00e9 poss\u00edvel fazer com que a resposta chegue a ambos os dispositivos.<\/p>\n

      <\/p>\n

      \u00c9 interessante notar que o c\u00f3digo para o processamento das mensagens recebidas torna-se semelhante (n\u00e3o 100%) tanto para os eventos que foram afetados pelo pr\u00f3prio cliente quanto para os demais eventos, inclusive de outros clientes.<\/p>\n

      <\/p>\n

      No entanto, na pr\u00e1tica, obtemos b\u00f4nus adicionais devido ao fato de que o fluxo unidirecional pode ser processado de maneira funcional (usando RX e similares). E isso j\u00e1 \u00e9 uma grande vantagem, pois, essencialmente, o aplicativo pode se tornar completamente reativo, al\u00e9m de aplicar uma abordagem funcional. Para aplicativos mais robustos, isso pode significar uma economia significativa de recursos em desenvolvimento e manuten\u00e7\u00e3o.<\/p>\n

      <\/p>\n

      Se combinarmos essa abordagem com escalabilidade horizontal, teremos como b\u00f4nus a capacidade de enviar requisi\u00e7\u00f5es a um servidor e receber respostas de outro. Assim, o cliente pode escolher o servi\u00e7o que lhe for mais conveniente, enquanto a sistema internamente ainda poder\u00e1processar os eventos corretamente.<\/p>\n

      <\/p>\n

      Event Sourcing.<\/h1>\n

      <\/p>\n

      Como voc\u00ea sabe, uma das principais caracter\u00edsticas de um sistema distribu\u00eddo \u00e9 a aus\u00eancia de tempo comum e de uma se\u00e7\u00e3o cr\u00edtica compartilhada. Para um \u00fanico processo, voc\u00ea pode fazer a sincroniza\u00e7\u00e3o (com os mesmos mutexes), dentro da qual voc\u00ea tem certeza de que ningu\u00e9m mais est\u00e1 executando aquele c\u00f3digo. No entanto, para um sistema distribu\u00eddo, isso \u00e9 arriscado, pois isso exige sobrecarga, al\u00e9m de aniquilar toda a beleza da escalabilidade \u2014 todos os componentes ainda estar\u00e3o esperando um s\u00f3.<\/p>\n

      <\/p>\n

      Daqui obtemos um fato importante \u2014 um sistema distribu\u00eddo r\u00e1pido n\u00e3o pode ser sincronizado, pois isso diminuiria o desempenho. Por outro lado, muitas vezes precisamos de uma certa consist\u00eancia entre os componentes. E para isso, podemos usar a abordagem de consist\u00eancia eventual<\/a><\/noindex>, onde \u00e9 garantido que na aus\u00eancia de altera\u00e7\u00f5es nos dados, ap\u00f3s um certo per\u00edodo de tempo desde a \u00faltima atualiza\u00e7\u00e3o (\u201cem \u00faltima inst\u00e2ncia\u201d), todas as solicita\u00e7\u00f5es retornar\u00e3o o \u00faltimo valor atualizado.<\/p>\n

      <\/p>\n

      \u00c9 importante entender que para bancos de dados cl\u00e1ssicos, \u00e9 frequentemente aplicada a consist\u00eancia estrita<\/a><\/noindex>, onde cada n\u00f3 possui as mesmas informa\u00e7\u00f5es (isso geralmente \u00e9 alcan\u00e7ado quando uma transa\u00e7\u00e3o \u00e9 considerada estabelecida apenas ap\u00f3s a resposta de um segundo servidor). Aqui h\u00e1 algumas flexibiliza\u00e7\u00f5es devido aos n\u00edveis de isolamento, no entanto, a ess\u00eancia geral permanece a mesma \u2014 voc\u00ea pode viver em um mundo totalmente consistente.<\/p>\n

      <\/p>\n

      No entanto, voltemos \u00e0 tarefa inicial. Se parte do sistema puder ser constru\u00edda com consist\u00eancia eventual<\/a><\/noindex>, ent\u00e3o podemos construir o seguinte esquema.<\/p>\n

      <\/p>\n

      \"Padr\u00f5es<\/p>\n

      <\/p>\n

      Caracter\u00edsticas importantes dessa abordagem:<\/p>\n

      <\/p>\n