{"id":5046,"date":"2022-07-04T08:04:19","date_gmt":"2022-07-04T11:04:19","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=5046"},"modified":"2024-01-11T18:02:36","modified_gmt":"2024-01-11T21:02:36","slug":"fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/","title":{"rendered":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0"},"content":{"rendered":"

Com a transforma\u00e7\u00e3o digital, sistemas est\u00e3o cada vez mais conectados. Clientes, parceiros e fornecedores t\u00eam cada vez mais acesso a sistemas que at\u00e9 bem pouco tempo eram acessados apenas “dentro de casa”. As “janelas para\u00a0downtime<\/em>” est\u00e3o ficando cada vez menores. Nunca disponibilidade e confiabilidade foram t\u00e3o importantes.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Entendendo disponibilidade<\/p>\r\n

Ainda confuso sobre o significa disponibilidade, enquanto atributo de qualidade arquitetural? Acesse o t\u00f3pico onde explicamos o conceito.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nSob o ponto de arquitetura de software, \u00e9 cada vez mais relevante identificar que funcionalidades dos sistemas “n\u00e3o devem parar”, assim como quais podem ficar eventualmente indispon\u00edveis e em que “janelas”. A partir dessas informa\u00e7\u00f5es, \u00e9 poss\u00edvel criar propostas de design<\/em> de componentes que colaborem com a solu\u00e7\u00e3o, sem custos desnecess\u00e1rios.\n

\nH\u00e1 tempos, a ind\u00fastria de software tem mantido sistemas dispon\u00edveis adotando redund\u00e2ncia, com replica\u00e7\u00f5es (eventualmente em mais de uma regi\u00e3o) e clusters <\/em>de processamento. A ideia \u00e9 que a escala horizontal previne a satura\u00e7\u00e3o de recursos e cria um “backup” operante se algo vai mal. Entretanto, essa n\u00e3o pode ser a \u00fanica medida adotada\n
\r\n

Defini\u00e7\u00e3o: Resili\u00eancia<\/p>\r\n

<\/p>\n

Resili\u00eancia, como propriedade da f\u00edsica, implica \u00e9 a propriedade que alguns corpos apresentam de retornar \u00e0 forma original ap\u00f3s terem sido submetidos a uma deforma\u00e7\u00e3o el\u00e1stica. Informalmente, \u00e9 a\u00a0capacidade de se recobrar facilmente ou se adaptar \u00e0 m\u00e1 sorte ou \u00e0s mudan\u00e7as<\/strong>.<\/p>\n

<\/p>\r\n<\/div>\n

Redund\u00e2ncia ainda \u00e9 fundamento para resili\u00eancia<\/h2>\n

Considere um sistema que precise suportar, consistentemente, 1.000 requisi\u00e7\u00f5es por segundo. Cada servidor de aplica\u00e7\u00e3o deste sistema demonstra capacidade para suportar 300 requisi\u00e7\u00f5es por segundo. Da\u00ed, infere-se a necessidade de quatro inst\u00e2ncias.<\/p>\n

\"\"<\/p>\n

O problema \u00e9 que uma eventual indisponibilidade em um dos servidores implica em sobrecarga para as demais inst\u00e2ncias.<\/p>\n

\"\"<\/p>\n

Com o traffic intensity\u00a0<\/em>desfavor\u00e1vel (arrival rate<\/em> > departure rate<\/em>) ocorre, ent\u00e3o, prov\u00e1vel satura\u00e7\u00e3o de recursos (falha) levando a erros e defeitos (indisponibilidade do servi\u00e7o) em, provavelmente, pouco tempo.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Filas geram satura\u00e7\u00e3o<\/p>\r\n

A forma\u00e7\u00e3o de filas, invariavelmente, gera satura\u00e7\u00e3o de recursos, eventualmente gerando indisponibilidades. Interessado em saber mais?<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A estrat\u00e9gia para resili\u00eancia, no exemplo, consiste em adicionar redund\u00e2ncia. Em termos simples, um quinto servidor “sobrando” seria a forma evidente para tolerar falhas.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Redund\u00e2ncia, essencial para resili\u00eancia, implica em aumento de custos.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

N\u00e3o h\u00e1 resili\u00eancia sem redund\u00e2ncia. Entretanto, esta \u00e9 apenas a primeira medida e, provavelmente, a mais cara.<\/p>\n

Diferenciando falhas, erros e defeitos<\/h2>\nO que voc\u00ea pensa quando v\u00ea uma rachadura pequena na tela de um celular? Geralmente, \u00e9 quest\u00e3o de pouco<\/del> tempo\u00a0 para que ela se propague tornando o dispositivo in\u00fatil (defeituoso). Se h\u00e1 algo que possa ser feito para conten\u00e7\u00e3o, deve ser feito. Algo semelhante acontece com sistemas de software.\n
\n

Em sistemas de software, toda falha \u00e9 uma esp\u00e9cie de rachadura pequena que, se n\u00e3o for contida, eventualmente, ir\u00e1 se espalhar at\u00e9 deixar o sistema o sistema defeituoso.<\/p>\n

Pequenas falhas (faults<\/em>)<\/strong> – como bugs\u00a0<\/em>ou valida\u00e7\u00f5es insuficientes em “entradas” fornecidas por usu\u00e1rios – podem deixar o sistema em estado inconsistente, o que, ocasionalmente, d\u00e1 origem a erros (errors<\/em>)<\/strong>, ou seja, comportamentos indesejados do software que, eventualmente, culminam em defeitos\u00a0(failures<\/em>)<\/strong>, geralmente indisponibilidades.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Sistemas resilientes s\u00e3o tolerantes a falhas.<\/strong> Isso significa, impedir que elas se convertam em erros que, eventualmente, se convertem em defeitos.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Falhas provocam erros que provocam defeitos. <\/strong>Consultas SQL mal escritas s\u00e3o falhas que, eventualmente, geram lentid\u00e3o no banco para responder outras consultas que, por sua vez, causam o aumento nas filas de requisi\u00e7\u00f5es que, se prolongadas, “topam” mem\u00f3ria que, finalmente, tornam um sistema indispon\u00edvel.<\/p>\n

Rela\u00e7\u00e3o com confiabilidade<\/h2>\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" <\/p>\n

Esperan\u00e7a n\u00e3o \u00e9 estrat\u00e9gia.<\/em><\/p>\n

\r\n

Frase popular entre praticantes de SRE<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

\r\n

Defini\u00e7\u00e3o: Confiabilidade<\/p>\r\n

<\/p>\n

Confiabilidade trata da capacidade de um sistema desempenhar uma determinada fun\u00e7\u00e3o, sem erros ou defeitos, sob condi\u00e7\u00f5es pr\u00e9-estabelecidas por um per\u00edodo de tempo.<\/p>\n

<\/p>\r\n<\/div>\n

Tolerar falhas \u00e9, tamb\u00e9m, fundamento para a confiabilidade.<\/p>\n

A \u00eanfase em adicionar resili\u00eancia permite\u00a0velocity\u00a0<\/em>para a adi\u00e7\u00e3o de mudan\u00e7as no software, mitigando riscos de comprometer os objetivos de neg\u00f3cio, por isso s\u00e3o importantes. Manter preocupa\u00e7\u00e3o com resili\u00eancia \u00e9 comportamento pr\u00f3-ativo e preventivo.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Site Reliability Engineering: How Google Runs Production Systems <\/p>\r\nEste livro j\u00e1 pode ser considerado um cl\u00e1ssico. Ele formaliza SRE – conjunto de pr\u00e1ticas para resili\u00eancia da Google.\r\n

Acessar livro<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Falhas s\u00e3o inevit\u00e1veis (e cada vez mais comuns)<\/h2>\n

Sistemas est\u00e3o ficando maiores, logo, mais complexos nos \u00faltimos anos.<\/strong> Esse “crescimento” associado com tecnologias como a nuvem, conduziram ao desenvolvimento de solu\u00e7\u00f5es com cada vez mais componentes, cada vez menores, mais f\u00e1ceis de manter e distribuir. Entretanto, “n\u00e3o h\u00e1 almo\u00e7o gr\u00e1tis”, maior a fragmenta\u00e7\u00e3o, maiores as probabilidades de ocorr\u00eancia de falhas.<\/p>\n

\"\"<\/p>\n

Em termos simples, em sistemas cada vez mais distribu\u00eddos, falhas, al\u00e9m de inevit\u00e1veis, devem ocorrer com frequ\u00eancia cada vez maior. <\/strong>Por isso, implementa\u00e7\u00f5es ing\u00eanuas resultam em sistemas cada vez menos confi\u00e1veis.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Abordagens arquiteturais “ing\u00eanuas” ignoram que sistemas distribu\u00eddos enfrentam mais falhas, permitindo maior incid\u00eancia de erros e defeitos.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Resili\u00eancia implica em conten\u00e7\u00e3o de falhas<\/p>\n

A estrat\u00e9gia mais efetiva para evitar defeitos \u00e9 impedir que falhas se convertam em erros. <\/strong>Para isso, \u00e9 importante, al\u00e9m de tentar minimiz\u00e1-las, impedir que seus efeitos “se espalhem”.<\/p>\n

Em sistemas complexos, sem o devido cuidado, falhas em um componente “se espalham” rapidamente gerando erros em componentes com acoplamento eferente mais alto.<\/strong> Por isso, sob ponto de vista arquitetural, \u00e9 importante cuidar dos integration points\u00a0<\/em>adotando estrat\u00e9gias que mitiguem impactos de falhas, erros ou defeitos de um componente nos demais.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Release It!<\/p>\r\nSem d\u00favidas, um dos melhores livros j\u00e1 escritos sobre projeto de sistemas resilientes.\r\n

Acessar livro<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

As falhas em componentes remotos podem assumir diversas formas, incluindo falhas de comunica\u00e7\u00e3o ou comportamento. Componentes remotos podem se tornar inesperadamente indispon\u00edveis ou, o que \u00e9 muito pior, incrivelmente lentos. Por isso, \u00e9 essencial que pr\u00e1ticas defensivas sejam adotadas.<\/p>\n

M\u00e9tricas importantes para confiabilidade<\/h2>\nA defini\u00e7\u00e3o de m\u00e9tricas \u00e9 de extrema import\u00e2ncia para o projeto arquitetural.<\/strong> Afinal, as decis\u00f5es que ser\u00e3o tomadas ir\u00e3o na dire\u00e7\u00e3o de obter melhores resultados para estas m\u00e9tricas. Assim, a escolha da m\u00e9trica errada pode comprometer a qualidade das decis\u00f5es.\n
\n

H\u00e1 dois pares de m\u00e9tricas fundamentais para o\u00a0design <\/em>arquitetural de software com disponibilidade e confiabilidade.<\/p>\n

    \n
  1. Sob a perspectiva funcional, MTTR e MTBF;<\/li>\n
  2. Sob a perspectiva de dados, RPO e RTO.<\/li>\n<\/ol>\n
    \n

    MTTR e MTBF<\/h4>\n

    MTTR (Mean time to recover – <\/em>tempo m\u00e9dio para recupera\u00e7\u00e3o) tem rela\u00e7\u00e3o com o tempo em que uma falha <\/i>destr\u00f3i valor em produ\u00e7\u00e3o. MTBF (Mean time between failures<\/em> \u2013 tempo m\u00e9dio entre falhas) tem rela\u00e7\u00e3o com o intervalo de tempo at\u00e9 falhas serem que destroem valor serem observadas em produ\u00e7\u00e3o.<\/p>\n

    \n

    Historicamente, \u00e9 mais comum dar \u00eanfase a medidas como MTBF<\/strong>, principalmente, quando se adota pr\u00e1ticas mais focadas em disponibilidade do que em confiabilidade. Entretanto, para ser efetiva, demanda sistemas menos complexos e menos fragmentados. Quando a \u00eanfase \u00e9 confiabilidade, a m\u00e9trica mais apropriada \u00e9 MTTR.<\/strong><\/p>\n<\/div>\nM\u00e9tricas criam \u201ctens\u00f5es\u201d na opera\u00e7\u00e3o que direcionam decis\u00f5es e padr\u00f5es operacionais. A \u201ctens\u00e3o\u201d gerada pelo MTBF, que \u00e9 uma m\u00e9trica bem intencionada, \u00e9 espa\u00e7ar problemas em produ\u00e7\u00e3o o m\u00e1ximo poss\u00edvel, evitando preju\u00edzos percebidos. O problema \u00e9 que, implicitamente, essa m\u00e9trica acaba encorajando, tamb\u00e9m, o prolongamento dos intervalos entre deploys<\/i>, afinal, em um sistema que est\u00e1 funcionando bem, toda mudan\u00e7a \u00e9 fonte potencial de problemas. Indiretamente, em fun\u00e7\u00e3o de menos entregas em produ\u00e7\u00e3o, h\u00e1 aumento do\u00a0lead time\u00a0<\/i>e tamb\u00e9m do tamanho de cada entrega, gerando, curiosamente, aumento nas chances de falhas no ambiente produtivo, mais dif\u00edceis de identificar, prejudicando o MTTR.\n

    Os riscos do MTBF podem ser bastante mitigados se o\u00a0deploy\u00a0<\/i>acontecer em \u201can\u00e9is\u201d e a m\u00e9trica ficar restrita apenas ao anel mais amplo.<\/div>\n
    \n

    RPO e RTO<\/h4>\n

    Pensar sobre disponbilidade para dados \u00e9 mais desafiador do que para outros artefatos. Afinal, quando n\u00e3o h\u00e1 perda de dados, solu\u00e7\u00f5es mais cr\u00edticas tem rela\u00e7\u00e3o, apenas, com replica\u00e7\u00e3o ou reinicializa\u00e7\u00e3o.<\/p>\n

    As m\u00e9tricas associadas com dados s\u00e3o, respectivamente RPO (recovery point objective<\/em>) e RTO (recovery time objective<\/em>)<\/strong>.<\/p>\n

    RPO tem rela\u00e7\u00e3o com o volume de dados que podem ser perdidos no caso de ocorr\u00eancia de uma falha. RTO define quanto tempo \u00e9 tolerado para recuperar dados para devolver o sistema ao RPO, impactando diretamente o MTTR.<\/p>\n

    Geralmente o RPO \u00e9 indicado pela “janela de tempo” m\u00e1xima onde perdas s\u00e3o toleradas.<\/p>\nUma estrat\u00e9gia para reduzir impactos no RPO e RTO \u00e9 estabelecer pr\u00e1ticas de gest\u00e3o de dados conforme temperatura, mantendo apenas os dados mais “quentes”, ou seja, usados com mais frequ\u00eancia, pr\u00f3ximos do ambiente produtivo onde os defeitos acontecem. Nessa linha, dados mais “frios” (menos utilizados) podem ser movidos para estruturas de armazenamento menos flex\u00edveis.\n

    \n<\/div>\n

    Abordagens gen\u00e9ricas para lidar com falhas<\/h2>\n

    Boa parte dos esfor\u00e7os arquiteturais para desenvolvimento de sistemas resilientes t\u00eam, ent\u00e3o, vincula\u00e7\u00e3o direta com a capacidade de suportar falhas. Da\u00ed, nascem tr\u00eas preocupa\u00e7\u00f5es inerentes:<\/p>\n

      \n
    1. Como identificar a ocorr\u00eancia de falhas?<\/li>\n
    2. Como prevenir a ocorr\u00eancia de falhas?<\/li>\n
    3. Como evitar a propaga\u00e7\u00e3o dos efeitos de uma falha?<\/li>\n<\/ol>\n

      Identificando a ocorr\u00eancia de falhas<\/h2>\n

      Health Checks\u00a0<\/em>(verifica\u00e7\u00e3o de integridade)<\/h4>\n

      A melhor forma de saber que um componente est\u00e1 funcionando bem \u00e9 “perguntando” para ele<\/strong>. Sob o ponto de vista arquitetural, isto implica em adicionar uma fun\u00e7\u00e3o de verifica\u00e7\u00e3o para a “sa\u00fade” em cada componente, geralmente acess\u00edvel atrav\u00e9s de um endpoint\u00a0<\/em>espec\u00edfico.<\/p>\n

      \"\"<\/p>\nA ideia \u00e9 fazer com que cada componente execute alguma rotina de auto-verifica\u00e7\u00e3o, geralmente alguma atividade sem efeitos colaterais duradouros, retornando um valor que indique seu “n\u00edvel de sa\u00fade”. Obviamente, caso o componente n\u00e3o consiga processar a requisi\u00e7\u00e3o, isso indica problema.\n

      \n

      As\u00a0health checks\u00a0<\/em>devem ser utilizadas tanto por\u00a0load balancers,<\/i>\u00a0orquestrados de cont\u00eaineres e por ferramentas de monitoramento.<\/p>\n

      \r\n

      Readiness e Liveness<\/p>\r\n<\/p>\n

      A ado\u00e7\u00e3o de tecnologias como Kubernetes levaram a uma amplia\u00e7\u00e3o do conceito de health checking<\/em>. Modernamente admite-se dois tipos diferentes de verifica\u00e7\u00e3o: readiness<\/em> e liveness<\/em>.<\/p>\n

      Readiness\u00a0<\/em>trata da “prontid\u00e3o” de um\u00a0pod\u00a0<\/em>para tratar workload<\/em>. Tal prontid\u00e3o \u00e9 impactada pelo\u00a0pod\u00a0<\/em>em si, mas, tamb\u00e9m, por suas depend\u00eancias.<\/p>\n

      Liveness\u00a0<\/em>trata da sa\u00fade de um\u00a0pod.\u00a0<\/em>\u00c9 indicativo para a necessidade de “reciclagem”.<\/p>\n

      <\/div>\n

      Eventualmente, as verifica\u00e7\u00f5es podem incluir as principais depend\u00eancias dos componentes, como bancos de dados, servi\u00e7os remotos, etc.<\/p>\n

      \u00c9 importante configurar adequadamente mecanismos de health check<\/em> com intervalos e alguma estrutura de caching<\/em> para evitar sobrecargas desnecess\u00e1rias.<\/p>\n

      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" Considere ter duas vers\u00f5es de healthcheckers: <\/em>para consumo interno e para consumo externo.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      Watchdogs<\/em><\/h4>\n

      Enquanto health checks<\/em> operam passivamente, fornecendo informa\u00e7\u00f5es sobre a “sa\u00fade” dos componentes,\u00a0watchdogs\u00a0<\/em>atuam ativamente, muitas vezes acionando\u00a0health checks,\u00a0<\/em>para, sob determinadas circunst\u00e2ncias, disparar algum tipo de a\u00e7\u00e3o.<\/p>\n

      Um watchdog<\/em> \u00e9 um programa, frequentemente associado a ferramentas de APM e m\u00e9tricas de infraestrutura. Seu objetivo \u00e9 detectar automaticamente poss\u00edveis problemas de aplicativo e infraestrutura, observando continuamente tend\u00eancias e padr\u00f5es nas m\u00e9tricas e procurando comportamento at\u00edpico.<\/p>\nWatchdogs\u00a0<\/em>devem ser planejados na arquitetura, mas raramente devem ser implementados “dentro de casa”. Todos os fornecedores do nuvem oferecem alternativas altamente configur\u00e1veis e flex\u00edveis.\n

      Poison Queues<\/h4>\n

      Em sistemas baseados em mensageria, eventualmente, o processamento de determinadas mensagens acabam gerando falhas (e reciclagem) de maneira recorrente. Essas mensagens s\u00e3o “envenenadas”.<\/p>\n

      O ideal \u00e9 que sistemas tenham condi\u00e7\u00f5es de identificar tais mensagens e direciona-las para processamento apartado.<\/p>\n

      Mitigando a propaga\u00e7\u00e3o de falhas<\/h2>\n

      Comunica\u00e7\u00e3o ass\u00edncrona<\/h4>\n

      Substituir chamadas diretas por trocas de mensagens \u00e9, provavelmente, a medida mais eficiente para aumentar a resili\u00eancia de sistemas de software.\u00a0<\/strong>A ideia \u00e9 substituir chamadas a componentes potencialmente inst\u00e1veis por mecanismos de mensageria comprovadamente s\u00f3lidos e est\u00e1veis.<\/p>\n

      A abordagem mais simples \u00e9 utilizar filas\u00a0p<\/em>oint-to-point. <\/i>Uma\u00a0alternativa mais sofisticada (e menos acoplada) \u00e9 a ado\u00e7\u00e3o de \u00a0pub\/sub<\/em>.<\/p>\n

      \"\"<\/p>\n

      A alternativa tradicional \u00e9 utilizar estrat\u00e9gias de alta-disponibilidade com replica\u00e7\u00f5es e load balancers.<\/em><\/p>\n

      Bulkheads<\/em><\/h4>\n

      Considere um sistema com tr\u00eas componentes: \u201cA\u201d, \u201cB\u201d e \u201cC\u201d. Onde \u201cA\u201d e \u201cB\u201d dependem sincronamente de \u201cC\u201d para funcionar.<\/p>\n

      \"\"<\/p>\n

      Caso \u201cC\u201d fique inst\u00e1vel, \u201cA\u201d e \u201cB\u201d podem ter dificuldades para continuar funcionando bem, o que pode espalhar falhas em \u201cefeito domin\u00f3\u201d. Ou seja, a instabilidade de \u201cC\u201d pode acabar gerando instabilidades em \u201cA\u201d e \u201cB\u201d que, eventualmente, ir\u00e3o causar instabilidades em outros componentes.<\/p>\n

      \nA maioria dos projetos de sistemas onde h\u00e1 depend\u00eancia forte entre componentes t\u00eam conting\u00eancia para falhas mais graves.<\/strong> No exemplo, provavelmente \u201cA\u201d e \u201cB\u201d est\u00e3o preparados para cen\u00e1rios onde \u201cC\u201d simplesmente pare de responder. Entretanto, poucas vezes encontramos arquiteturas preparadas para lidar com response times <\/em>mais altos.<\/strong> Geralmente, lentid\u00e3o, mais do que indisponibilidade total, \u00e9 a causa raiz da maioria dos problemas mais cr\u00edticos em produ\u00e7\u00e3o.\n
      \n

      Uma forma comum de tentar mitigar os impactos de instabilidades em um componente \u00e9 torn\u00e1-lo escal\u00e1vel na horizontal para, ent\u00e3o, levantar v\u00e1rias inst\u00e2ncias com demanda distribu\u00edda por um load balancer.<\/em><\/p>\n

      \n

      \"\"<\/p>\n

      O problema, entretanto, \u00e9 que, com frequ\u00eancia, instabilidades, sobretudo de lentid\u00e3o, s\u00e3o ocasionadas por dificuldades de um componente para atender \u201crequisi\u00e7\u00f5es envenenadas\u201d provenientes de um \u201cofensor externo\u201d. Em nosso exemplo, caso \u201cA\u201d gere \u201crequisi\u00e7\u00f5es envenenadas\u201d para \u201cC\u201d, estas podem acabar afetando todas as inst\u00e2ncias do servi\u00e7o, mesmo escalados na horizontal, apenas retardando os efeitos ruins, sem evit\u00e1-los.<\/p>\n

      \"\"<\/p>\n<\/div>\n

      \n
      Uma alternativa eficiente para mitigar o risco dessa situa\u00e7\u00e3o \u00e9 compartimentar inst\u00e2ncias para as diversas origens de requisi\u00e7\u00e3o. Ou seja, \u201clevantar\u201d inst\u00e2ncias espec\u00edficas para cada natureza de solicita\u00e7\u00e3o, mantendo-as apartadas.<\/figure>\n

      \"\"<\/p>\n<\/div>\n

      \n

      Dessa forma, a \u201cpress\u00e3o\u201d de \u201cA\u201d sobre \u201cC\u201d n\u00e3o impactar\u00e1 \u201cB\u201d. Nesse mesmo racioc\u00ednio, a \u201cpress\u00e3o\u201d de \u201cB\u201d sobre \u201cC\u201d tamb\u00e9m n\u00e3o causar\u00e1 problemas para \u201cA\u201d.<\/p>\n<\/div>\nNo \u201cmundo real\u201d, j\u00e1 vimos essa solu\u00e7\u00e3o ser aplicada, por exemplo, em grandes varejistas para apartar o tratamento de requisi\u00e7\u00f5es de aplica\u00e7\u00f5es m\u00f3veis, site, <\/em>rob\u00f4s de compara\u00e7\u00e3o de pre\u00e7os e o Google (como voc\u00ea pode imaginar, para um varejista, \u00e9 tremendamente prejudicial ser \u201cpenalizado\u201d pelo gigante das buscas).\n

      \n

      O nome dessa t\u00e9cnica de design<\/em> \u00e9 bulkhead, <\/em>em alus\u00e3o a forma como navios eram projetados para impedir que danos em uma parte do cascos causassem um naufr\u00e1gio.<\/p>\nBulkheads <\/em>obviamente, introduzem ociosidade desnecess\u00e1ria (leia-se desperd\u00edcio) de recursos a uma arquitetura, tornando-a economicamente menos interessante. Entretanto, essa inefici\u00eancia pode ser necess\u00e1ria e, geralmente, \u00e9 mais do que compensada com a minimiza\u00e7\u00e3o e isolamento de downtimes. <\/em>Um de seus principais atrativos \u00e9 que pode ser adotada, frequentemente, com poucas altera\u00e7\u00f5es (ou at\u00e9 nenhuma) de c\u00f3digo.\n

      Prevenindo falhas<\/h2>\n

      Back pressure<\/em><\/h4>\n

      Sempre o traffic intensity\u00a0<\/em>for desfavor\u00e1vel para um componente, o ideal \u00e9 que este passe a recusar novas demandas (usando load shedding <\/em>ou\u00a0rate limiting<\/em>),<\/em> devolvendo a “press\u00e3o” para o cliente que dever\u00e1 implementar alguma estrat\u00e9gia de retentivas ou, at\u00e9 mesmo, reduzir o volume de demandas com alguma estrat\u00e9gia de\u00a0gracefully degradation.<\/em><\/p>\n

      Do ponto de vista do componente que est\u00e1 adotando\u00a0back pressure,\u00a0<\/em>a implementa\u00e7\u00e3o \u00e9 restrita a algum mecanismo de sinaliza\u00e7\u00e3o (talvez retornando 429 – Too many requests<\/em>) para o cliente indicando a condi\u00e7\u00e3o. Caber\u00e1 ao cliente adotar estrat\u00e9gia apropriada, conforme sinaliza\u00e7\u00e3o.<\/p>\n

      Load shedding (Governor pattern)<\/em><\/h4>\n

      Assim como um rate limiter,\u00a0<\/em>um componente de\u00a0load shedding\u00a0<\/em>opera como um middleware\u00a0<\/em>que monitora os recursos computacionais necess\u00e1rios para um componente, bem como das depend\u00eancias, e recusa ativamente novas requisi\u00e7\u00f5es at\u00e9 que n\u00edveis saud\u00e1veis sejam restaurados.<\/p>\n

      Timeout<\/em><\/h4>\n

      Pior do que componentes que param de responder s\u00e3o aqueles que passam a operar com lentid\u00e3o incomum.<\/strong>\u00a0Estabelecer timeouts<\/em>\u00a0\u00e9 importante para impedir que componentes clientes esperem “tempo demais”, seja para solicita\u00e7\u00f5es s\u00edncronas quanto ass\u00edncronas.<\/p>\n

      \n

      Embora n\u00e3o haja uma “receita de bolo” para escolher um timeout<\/em> correto, eles devem ser relativamente curtos. A recomenda\u00e7\u00e3o segura \u00e9 150% do tempo m\u00e9dio de resposta do servi\u00e7o.<\/p>\n

      Use Proxies<\/em> para componentes que n\u00e3o est\u00e3o sob controle<\/h4>\n

      Todo componente que n\u00e3o est\u00e1 sob controle do time de desenvolvimento interno e que precisa estar em conformidade com as t\u00e1ticas de resili\u00eancia, deve estar “envelopada” por um proxy<\/em>.<\/p>\n

      \"\"<\/p>\n

      O proxy <\/em>(Envoy, PgBound, HAProxy, etc) consegue resolver regras como\u00a0load shedding,<\/em>\u00a0time outs<\/em>, entre outros.<\/p>\n

      Transaction Outbox<\/em><\/h4>\n

      Comandos – requisi\u00e7\u00f5es que modificam o estado do servidor – demandam, atomicamente, atualiza\u00e7\u00f5es em bancos de dados e envio de mensagens (via algum mecanismo de mensageria).<\/p>\n

      Em termos simples, em uma transa\u00e7\u00e3o, quando um\u00a0commit\u00a0<\/em>acontece, mensagens devem ser enviadas. Entretanto, se for necess\u00e1rio um\u00a0rollback<\/em>,<\/p>\n

      A sa\u00edda simples \u00e9 adicionar uma tabela adicional, no banco de dados onde as transa\u00e7\u00f5es est\u00e3o sendo processadas, para “registrar” a demanda do envio de uma mensagem. Ao executar uma transa\u00e7\u00e3o, essa tabela deve receber, tamb\u00e9m uma inclus\u00e3o. Outro agente fica respons\u00e1vel por “ler a tabela” e efetivar o envio de mensagens.<\/p>\n

      Circuit breaker<\/em><\/h4>\n

      Circuit breaker<\/em> \u00e9 uma inst\u00e2ncia de m\u00e1quina de estados implementada entre dois componentes, um “cliente” e o outro “servidor”. O objetivo de um\u00a0Circuit breaker\u00a0<\/i>\u00e9 proteger o “servidor” de requisi\u00e7\u00f5es enquanto este estiver enfrentando dificuldades (potencial satura\u00e7\u00e3o).<\/p>\n

      \"\"<\/p>\n

      O funcionamento da m\u00e1quina de estados \u00e9 a seguinte:<\/p>\n

        \n
      1. Circuito fechado\n
          \n
        • Toda requisi\u00e7\u00e3o do “cliente” deve ser encaminhada ao “servidor”<\/li>\n
        • Se houverem mais falhas do que o “aceit\u00e1vel” dentro de um intervalo de tempo, ent\u00e3o o circuito deve “abrir”.<\/li>\n<\/ul>\n<\/li>\n
        • Circuito aberto\n
            \n
          • Nenhuma requisi\u00e7\u00e3o do “cliente” deve ser encaminhada ao “servidor”, falhando imediatamente<\/li>\n
          • Transcorrido um determinado tempo, o circuito deve ficar “meio aberto”<\/li>\n<\/ul>\n<\/li>\n
          • Circuito meio aberto\n
              \n
            1. Algumas requisi\u00e7\u00f5es devem ser encaminhadas para o “servidor”, \u00a0outras negadas<\/li>\n
            2. Se as falhas persistirem, o circuito dever\u00e1 “abrir” novamente<\/li>\n
            3. Se as falhas n\u00e3o ocorrerem mais, o circuito dever\u00e1 “fechar”.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n

              Sumarizando<\/h2>\n

              Estrat\u00e9gias tradicionais para disponibilidade, baseadas em replica\u00e7\u00e3o e clusters<\/em>, n\u00e3o s\u00e3o mais suficientes para manter sistemas confi\u00e1veis.<\/strong><\/p>\n

              T\u00e3o importante quanto garantir que h\u00e1 recursos suficientes para atender as demandas de performance, sem satura\u00e7\u00e3o, \u00e9 tamb\u00e9m importante adotar pr\u00e1ticas e cuidados arquiteturais que identifiquem, previnam e interrompam a propaga\u00e7\u00e3o\u00a0de falhas, para que elas n\u00e3o se tornem erros e, finalmente, defeitos.<\/p>\n

              \/\/ TODO<\/h2>\n

              Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo, recomendo as seguintes reflex\u00f5es:<\/p>\n

                \n
              1. Que padr\u00f5es para resili\u00eancia j\u00e1 adotou?<\/li>\n
              2. Qual a rela\u00e7\u00e3o entre a complexidade crescente dos sistemas e a demanda por resili\u00eancia?<\/li>\n<\/ol>\n","protected":false},"featured_media":3829,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[],"sessoes":[58],"apendices":[],"capitulos":[41],"class_list":["post-5046","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","sessoes-secao-2","capitulos-capitulo-2-4"],"acf":[],"yoast_head":"\nFundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0 - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0 - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Com a transforma\u00e7\u00e3o digital, sistemas est\u00e3o cada vez mais conectados. Clientes, parceiros e fornecedores t\u00eam cada vez mais acesso a sistemas que at\u00e9 bem pouco tempo eram acessados apenas “dentro de casa”. As “janelas para\u00a0downtime” est\u00e3o ficando cada vez menores. Nunca disponibilidade e confiabilidade foram t\u00e3o importantes. Redund\u00e2ncia ainda \u00e9 fundamento para resili\u00eancia Considere um […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-11T21:02:36+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"600\" \/>\n\t<meta property=\"og:image:height\" content=\"338\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"17 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/\",\"name\":\"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0 - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg\",\"datePublished\":\"2022-07-04T11:04:19+00:00\",\"dateModified\":\"2024-01-11T21:02:36+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg\",\"width\":600,\"height\":338},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0 - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/","og_locale":"pt_BR","og_type":"article","og_title":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0 - Manual do Arquiteto de Software","og_description":"Com a transforma\u00e7\u00e3o digital, sistemas est\u00e3o cada vez mais conectados. Clientes, parceiros e fornecedores t\u00eam cada vez mais acesso a sistemas que at\u00e9 bem pouco tempo eram acessados apenas “dentro de casa”. As “janelas para\u00a0downtime” est\u00e3o ficando cada vez menores. Nunca disponibilidade e confiabilidade foram t\u00e3o importantes. Redund\u00e2ncia ainda \u00e9 fundamento para resili\u00eancia Considere um […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-11T21:02:36+00:00","og_image":[{"width":600,"height":338,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"17 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/","name":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0 - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg","datePublished":"2022-07-04T11:04:19+00:00","dateModified":"2024-01-11T21:02:36+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/03\/2.4.jpg","width":600,"height":338},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquiteturas-de-sistemas-resilientes-capitulo-13-v-3-0\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Fundamentos para arquiteturas de sistemas resilientes \/ Cap\u00edtulo 13 v 3.0"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/5046","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=5046"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/3829"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=5046"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=5046"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=5046"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=5046"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=5046"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}