{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Escolha do estilo arquitet\u00f4nico (parte 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ol\u00e1, Habr. Neste momento, a OTUS est\u00e1 com inscri\u00e7\u00f5es abertas para uma nova turma do curso Arquitetura de Software<\/a><\/noindex>. Antecipando o in\u00edcio do curso, quero compartilhar com voc\u00eas meu artigo autoral.<\/i><\/b><\/p>\n

<\/p>\n

Introdu\u00e7\u00e3o<\/h2>\n

\nA escolha do estilo arquitet\u00f4nico \u00e9 uma das decis\u00f5es t\u00e9cnicas fundamentais na constru\u00e7\u00e3o de um sistema de informa\u00e7\u00e3o. Nesta s\u00e9rie de artigos, proponho analisar os estilos arquitet\u00f4nicos mais populares para a constru\u00e7\u00e3o de aplica\u00e7\u00f5es e responder \u00e0 pergunta de quando determinado estilo arquitet\u00f4nico \u00e9 mais prefer\u00edvel. Durante a exposi\u00e7\u00e3o, tentarei tra\u00e7ar uma linha l\u00f3gica que explica a evolu\u00e7\u00e3o dos estilos arquitet\u00f4nicos, desde mon\u00f3litos at\u00e9 microsservi\u00e7os.
\n<\/a><\/noindex><\/p>\n

Um pouco de hist\u00f3ria<\/h2>\n

\nSe voc\u00ea tentar perguntar aos desenvolvedores: \"Por que os microsservi\u00e7os s\u00e3o necess\u00e1rios?\", receber\u00e1 respostas variadas. Voc\u00ea ouvir\u00e1 que os microsservi\u00e7os melhoram a escalabilidade, facilitam a compreens\u00e3o do c\u00f3digo e aprimoram a resili\u00eancia, e \u00e0s vezes pode at\u00e9 ouvir que eles permitem \"limpar o c\u00f3digo\". Vamos olhar para a hist\u00f3ria para entender qual era o objetivo do surgimento dos microsservi\u00e7os.<\/p>\n

Em resumo, os microsservi\u00e7os em nossa compreens\u00e3o atual surgiram da seguinte forma: em 2011, James Lewis, ao analisar o trabalho de v\u00e1rias empresas, notou o surgimento de um novo padr\u00e3o \"micro-app\" que otimizava o SOA em termos de acelerar o desenvolvimento de servi\u00e7os. Algum tempo depois, em 2012, o padr\u00e3o foi renomeado para microsservi\u00e7o em uma c\u00fapula arquitet\u00f4nica. Assim, o objetivo inicial da implementa\u00e7\u00e3o de microsservi\u00e7os era melhorar o famoso time to market<\/b>.<\/p>\n

Na \"onda do hype\", os microsservi\u00e7os estavam em alta em 2015. Segundo algumas pesquisas, nenhuma confer\u00eancia deixava de ter uma apresenta\u00e7\u00e3o sobre o tema microsservi\u00e7os. Al\u00e9m disso, algumas confer\u00eancias eram dedicadas exclusivamente a microsservi\u00e7os. Atualmente, muitos projetos s\u00e3o iniciados com esse estilo arquitet\u00f4nico, e se um projeto cont\u00e9m toneladas de c\u00f3digo legado, certamente est\u00e1 ocorrendo uma migra\u00e7\u00e3o ativa para microsservi\u00e7os.<\/p>\n

Apesar de tudo isso, ainda \u00e9 uma quantidade relativamente pequena de desenvolvedores que pode definir o conceito de \"microsservi\u00e7o\". Mas falaremos sobre isso mais adiante...<\/p>\n

Monolito<\/h2>\n

\nO estilo arquitet\u00f4nico que se op\u00f5e ao microsservi\u00e7o \u00e9 o monolito (ou \"tudo em um\"). N\u00e3o faz muito sentido falar sobre o que \u00e9 um monolito, ent\u00e3o vou listar imediatamente as desvantagens desse estilo arquitet\u00f4nico que iniciaram o desenvolvimento de novos estilos arquitet\u00f4nicos: tamanho, acoplamento, implanta\u00e7\u00e3o, escalabilidade, confiabilidade e rigidez. Abaixo, proponho que nos familiarizemos com cada uma das desvantagens separadamente.<\/p>\n

Tamanho<\/h3>\n

\nO mon\u00f3lito \u00e9 muito grande. E, geralmente, ele se comunica com um banco de dados igualmente grande. O aplicativo se torna complexo demais para ser compreendido por um \u00fanico desenvolvedor. Apenas aqueles que passaram muito tempo neste c\u00f3digo conseguem trabalhar bem com mon\u00f3litos, enquanto novatos gastam muito tempo tentando entender o mon\u00f3lito, sem garantias de que conseguir\u00e3o. Normalmente, ao trabalhar com um mon\u00f3lito, sempre h\u00e1 um 's\u00eanior' que conhece o mon\u00f3lito razoavelmente bem e orienta outros desenvolvedores novatos ao longo de um ano ou um ano e meio. \u00c9 claro que esse s\u00eanior se torna um ponto \u00fanico de falha, e sua sa\u00edda pode levar \u00e0 ru\u00edna do mon\u00f3lito. <\/p>\n

Coes\u00e3o<\/h3>\n

\nUm mon\u00f3lito \u00e9 como um 'grande novelo de barbante' (big ball of mud), cujas altera\u00e7\u00f5es podem levar a consequ\u00eancias imprevis\u00edveis. Ao fazer mudan\u00e7as em um local, pode-se danificar o mon\u00f3lito em outro (\u00e9 o famoso 'co\u00e7ou a orelha, e a @&*# se soltou'). Isso acontece porque os componentes dentro do mon\u00f3lito t\u00eam rela\u00e7\u00f5es muito complexas e, principalmente, n\u00e3o \u00f3bvias.<\/p>\n

Implanta\u00e7\u00e3o<\/h3>\n

\nA implanta\u00e7\u00e3o de um mon\u00f3lito, devido \u00e0s complexas inter-rela\u00e7\u00f5es entre seus componentes, \u00e9 um processo longo, com seus pr\u00f3prios rituais. Esses rituais geralmente n\u00e3o est\u00e3o completamente padronizados e s\u00e3o transmitidos 'de boca em boca'. <\/p>\n

Escalabilidade<\/h3>\n

\nOs m\u00f3dulos de um mon\u00f3lito podem ter necessidades de recursos conflitantes, o que exige uma busca por compromisso do ponto de vista de hardware. Imagine que seu mon\u00f3lito seja composto pelos servi\u00e7os A e B. O servi\u00e7o A exige muito espa\u00e7o em disco, enquanto o servi\u00e7o B demanda muita mem\u00f3ria RAM. Nesse caso, ou a m\u00e1quina onde o mon\u00f3lito \u00e9 instalado deve atender os requisitos de ambos os servi\u00e7os, ou um dos servi\u00e7os precisar\u00e1 ser manualmente desligado.<\/p>\n

Outro exemplo (mais cl\u00e1ssico): o servi\u00e7o A \u00e9 muito mais popular que o servi\u00e7o B, portanto, voc\u00ea deseja que haja 100 inst\u00e2ncias do servi\u00e7o A e 10 do servi\u00e7o B. Novamente, temos duas op\u00e7\u00f5es: ou implantamos 100 mon\u00f3litos completos, ou teremos que desligar manualmente os servi\u00e7os B em algumas das inst\u00e2ncias. <\/p>\n

Confiabilidade<\/h3>\n

\nComo todos os servi\u00e7os est\u00e3o juntos, se o monolito falha, todos os servi\u00e7os falham ao mesmo tempo. Na verdade, isso pode n\u00e3o ser t\u00e3o ruim; pelo menos n\u00e3o haver\u00e1 falhas parciais em um sistema distribu\u00eddo, mas, por outro lado, devido a um erro em uma funcionalidade usada por 0,001% dos usu\u00e1rios, voc\u00ea pode perder todos os usu\u00e1rios de seu sistema. <\/p>\n

Rigidez<\/h3>\n

\nDevido ao tamanho do mon\u00f3lito, \u00e9 dif\u00edcil migrar para novas tecnologias. Como resultado, uma tarefa separada \u00e9 manter aquele famoso s\u00eanior. A pilha tecnol\u00f3gica escolhida no in\u00edcio do projeto pode se tornar um bloqueio, impedindo o desenvolvimento do produto. <\/p>\n

Conclus\u00e3o<\/h2>\n

\nNa pr\u00f3xima vez, vamos discutir como as pessoas tentaram resolver os problemas mencionados passando para componentes e SOA.<\/p>\n

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

\n

Leia mais:<\/h4>\n

<\/p>\n