{"id":31124,"date":"2019-10-31T21:39:36","date_gmt":"2019-10-31T18:39:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie\/"},"modified":"2019-10-31T21:39:36","modified_gmt":"2019-10-31T18:39:36","slug":"stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/stroitelnye-bloki-raspredelennyh-prilozhenij-vtoroe-priblizhenie","title":{"rendered":"Componentes b\u00e1sicos de aplica\u00e7\u00f5es distribu\u00eddas. Segunda aproxima\u00e7\u00e3o","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

An\u00fancio<\/strong><\/p>\n

<\/p>\n

Colegas, no meio do ver\u00e3o, planejo lan\u00e7ar mais um ciclo de artigos sobre o design de sistemas de atendimento em massa: \u201cExperimento VTrade\u201d \u2014 uma tentativa de desenvolver uma estrutura para sistemas de negocia\u00e7\u00e3o. O ciclo abordar\u00e1 a teoria e a pr\u00e1tica da constru\u00e7\u00e3o de uma bolsa de valores, leil\u00e3o e loja. No final do artigo, convido todos a votarem nos temas que mais lhes interessam.
\n<\/em><\/p>\n

<\/p>\n

\"Componentes<\/p>\n

<\/p>\n

Este \u00e9 o artigo final do ciclo sobre aplicativos reativos distribu\u00eddos em Erlang\/Elixir. No primeiro artigo<\/a><\/noindex> pode-se encontrar as bases te\u00f3ricas da arquitetura reativa. O segundo artigo<\/a><\/noindex> ilustra os principais padr\u00f5es e mecanismos de constru\u00e7\u00e3o de sistemas dessa natureza.<\/p>\n

<\/p>\n

Hoje, abordaremos quest\u00f5es sobre o desenvolvimento da base de c\u00f3digo e dos projetos como um todo. <\/p>\n

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

Organiza\u00e7\u00e3o de servi\u00e7os<\/h2>\n

<\/p>\n

Na vida real, ao desenvolver um servi\u00e7o, muitas vezes \u00e9 necess\u00e1rio combinar v\u00e1rios padr\u00f5es de intera\u00e7\u00e3o em um \u00fanico controlador. Por exemplo, o servi\u00e7o de usu\u00e1rios, que lida com a gest\u00e3o de perfis dos usu\u00e1rios do projeto, deve responder a solicita\u00e7\u00f5es req-resp e informar sobre atualiza\u00e7\u00f5es de perfis atrav\u00e9s de pub-sub. Este caso \u00e9 bastante simples: para mensageria, existe um controlador que implementa a l\u00f3gica do servi\u00e7o e publica atualiza\u00e7\u00f5es.<\/p>\n

<\/p>\n

A situa\u00e7\u00e3o se complica quando precisamos implementar um servi\u00e7o distribu\u00eddo tolerante a falhas. Suponhamos que os requisitos para os usu\u00e1rios mudaram: <\/p>\n

<\/p>\n

    \n
  1. agora, o servi\u00e7o deve processar solicita\u00e7\u00f5es em 5 n\u00f3s do cluster, <\/li>\n
  2. ter a capacidade de executar tarefas em segundo plano, <\/li>\n
  3. e tamb\u00e9m ser capaz de gerenciar dinamicamente listas de assinatura para atualiza\u00e7\u00f5es de perfis.<\/li>\n<\/ol>\n

    <\/p>\n

    Observa\u00e7\u00e3o:<\/em> A quest\u00e3o da consist\u00eancia de armazenamento e replica\u00e7\u00e3o de dados n\u00e3o ser\u00e1 abordada. Suponha que essas quest\u00f5es tenham sido resolvidas anteriormente e que j\u00e1 exista um camada de armazenamento confi\u00e1vel e escal\u00e1vel no sistema, e os manipuladores disponham de mecanismos para interagir com ela.<\/p>\n

    <\/p>\n

    A descri\u00e7\u00e3o formal do servi\u00e7o de usu\u00e1rios se tornou mais complexa. Do ponto de vista do programador, devido ao uso de mensageria, as mudan\u00e7as s\u00e3o m\u00ednimas. Para atender ao primeiro requisito, precisamos configurar o balanceamento no ponto de troca req-resp. <\/p>\n

    <\/p>\n

    A exig\u00eancia de processamento de tarefas em segundo plano surge frequentemente. Em users, isso pode incluir verifica\u00e7\u00f5es de documentos dos usu\u00e1rios, processamento de multim\u00eddia carregada ou sincroniza\u00e7\u00e3o de dados com redes sociais. Essas tarefas precisam ser distribu\u00eddas de alguma forma dentro do cluster e monitoradas durante a execu\u00e7\u00e3o. Portanto, temos duas op\u00e7\u00f5es de solu\u00e7\u00e3o: usar o modelo de distribui\u00e7\u00e3o de tarefas do artigo anterior ou, se n\u00e3o for adequado, escrever um planejador de tarefas personalizado que gerencie o pool de processadores da forma que precisamos. <\/p>\n

    <\/p>\n

    O ponto 3 requer a expans\u00e3o do modelo pub-sub. Para sua implementa\u00e7\u00e3o, ap\u00f3s criar o ponto de troca pub-sub, precisamos ativar adicionalmente o controlador desse ponto no contexto do nosso servi\u00e7o. Assim, como se estiv\u00e9ssemos transferindo a l\u00f3gica de assinatura e desinscri\u00e7\u00e3o da camada de messaging para a implementa\u00e7\u00e3o de users.<\/p>\n

    <\/p>\n

    No final, a decomposi\u00e7\u00e3o da tarefa revelou que, para atender aos requisitos, precisamos lan\u00e7ar 5 inst\u00e2ncias do servi\u00e7o em diferentes n\u00f3s e criar uma entidade adicional \u2013 um controlador pub-sub respons\u00e1vel pela assinatura.
    \nPara iniciar 5 processadores, n\u00e3o \u00e9 necess\u00e1rias modifica\u00e7\u00f5es no c\u00f3digo do servi\u00e7o. A \u00fanica a\u00e7\u00e3o adicional \u00e9 configurar as regras de balanceamento no ponto de troca, o que discutiremos um pouco mais tarde.
    \nAl\u00e9m disso, surgiu uma complexidade adicional: o controlador pub-sub e o planejador de tarefas personalizado devem operar em uma \u00fanica inst\u00e2ncia. Novamente, o servi\u00e7o de messaging, como elemento fundamental, deve fornecer um mecanismo para a escolha do l\u00edder.<\/p>\n

    <\/p>\n

    Escolha do l\u00edder<\/h3>\n

    <\/p>\n

    Em sistemas distribu\u00eddos, a escolha do l\u00edder \u00e9 o procedimento de nomea\u00e7\u00e3o de um \u00fanico processo respons\u00e1vel pelo planejamento do processamento distribu\u00eddo de alguma carga. <\/p>\n

    <\/p>\n

    Em sistemas que n\u00e3o s\u00e3o propensos \u00e0 centraliza\u00e7\u00e3o, encontram-se algoritmos universais e algoritmos baseados em consenso, como o paxos ou raft.
    \nUma vez que o messaging \u00e9 um broker e um elemento central, ele est\u00e1 ciente de todos os controladores do servi\u00e7o \u2013 candidatos a l\u00edderes. O messaging pode nomear um l\u00edder sem a necessidade de vota\u00e7\u00e3o.<\/p>\n

    <\/p>\n

    Todos os servi\u00e7os, ap\u00f3s iniciar e se conectar ao ponto de troca, recebem uma mensagem do sistema #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}<\/code>. No caso de LeaderPid<\/code> corresponder ao pid<\/code> do processo atual, ele \u00e9 nomeado l\u00edder, e a lista Servers<\/code> inclui todos os n\u00f3s e suas configura\u00e7\u00f5es.
    \nNo momento da chegada de um novo n\u00f3 e da desativa\u00e7\u00e3o de um n\u00f3 ativo no cluster, todos os controladores do servi\u00e7o recebem #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> e #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts}<\/code> respectivamente.<\/p>\n

    <\/p>\n

    Assim, todos os componentes est\u00e3o cientes de todas as mudan\u00e7as, e em cada momento, h\u00e1 garantidamente um l\u00edder no cluster.<\/p>\n

    <\/p>\n

    Intermedi\u00e1rios<\/h2>\n

    <\/p>\n

    Para implementar processos de processamento distribu\u00eddos complexos e em tarefas de otimiza\u00e7\u00e3o de uma arquitetura j\u00e1 existente, \u00e9 conveniente usar intermedi\u00e1rios.
    \nPara n\u00e3o alterar o c\u00f3digo dos servi\u00e7os e resolver, por exemplo, tarefas de processamento adicional, roteamento ou registro de mensagens, pode-se inserir um manipulador proxy antes do servi\u00e7o, que realizar\u00e1 todo o trabalho adicional.<\/p>\n

    <\/p>\n

    Um exemplo cl\u00e1ssico de otimiza\u00e7\u00e3o pub-sub \u00e9 um aplicativo distribu\u00eddo com um n\u00facleo de neg\u00f3cios que gera eventos de atualiza\u00e7\u00e3o, como altera\u00e7\u00f5es nos pre\u00e7os do mercado, e uma camada de acesso \u2014 N servidores que fornecem uma API websocket para clientes web.
    \nSe a abordagem for direta, o atendimento ao cliente se apresenta da seguinte forma:<\/p>\n

    <\/p>\n