{"id":79498,"date":"2020-04-27T19:42:07","date_gmt":"2020-04-27T17:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat"},"modified":"2020-04-27T19:42:07","modified_gmt":"2020-04-27T17:42:07","slug":"mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/mikroservisy-chto-eto-zachem-eto-i-kogda-nuzhno-ih-vnedryat","title":{"rendered":"Microsservi\u00e7os: o que s\u00e3o, por que usar e quando implement\u00e1-los","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Eu queria escrever um artigo sobre arquitetura de microsservi\u00e7os h\u00e1 muito tempo, mas sempre fui interrompido por duas raz\u00f5es \u2014 quanto mais eu me aprofundava no tema, mais parecia que o que eu sabia era \u00f3bvio e o que n\u00e3o sabia exigia muito mais estudo. Por outro lado, acredito que j\u00e1 h\u00e1 bastante assunto para refletir e discutir com um p\u00fablico mais amplo. Portanto, opini\u00f5es alternativas s\u00e3o bem-vindas.
\n<\/a><\/noindex><\/p>\n

A Lei de Conway e a rela\u00e7\u00e3o entre neg\u00f3cios, organiza\u00e7\u00e3o e sistema de informa\u00e7\u00e3o<\/h2>\n

\nMais uma vez, permitirei-me citar:<\/p>\n

\u00abQualquer organiza\u00e7\u00e3o que projete um sistema (no sentido amplo) obter\u00e1 um design cuja estrutura reflete a estrutura das equipes nessa organiza\u00e7\u00e3o\u00bb
\n\u2014 Melvyn Conway, 1967\n<\/p><\/blockquote>\n

Na minha opini\u00e3o, essa lei est\u00e1 mais relacionada \u00e0 adequa\u00e7\u00e3o da organiza\u00e7\u00e3o dos neg\u00f3cios do que diretamente ao sistema de informa\u00e7\u00e3o. Vou explicar com um exemplo. Suponha que temos uma oportunidade de neg\u00f3cio est\u00e1vel com um ciclo de vida suficientemente longo para justificar a organiza\u00e7\u00e3o do empreendimento (n\u00e3o \u00e9 um erro de digita\u00e7\u00e3o, mas gosto muito desse termo que eu peguei emprestado). \u00c9 claro que o sistema que apoia esse neg\u00f3cio ser\u00e1 organizacional e processualmente adequado a esse neg\u00f3cio.<\/p>\n

Orienta\u00e7\u00e3o para o neg\u00f3cio dos sistemas de informa\u00e7\u00e3o<\/h2>\n

\n\"Microsservi\u00e7os:
\n
\nVou explicar com um exemplo. Suponha que existe uma oportunidade de neg\u00f3cio para organizar a venda de pizzas. Na vers\u00e3o V1 (vamos cham\u00e1-la de vers\u00e3o pr\u00e9-informacional), a empresa era uma pizzaria, um caixa e um servi\u00e7o de entrega. Essa vers\u00e3o teve uma longa dura\u00e7\u00e3o em um ambiente de baixo dinamismo. Ent\u00e3o, surgiu a vers\u00e3o 2 \u2014 mais avan\u00e7ada e capaz de utilizar um sistema de informa\u00e7\u00e3o como base para um neg\u00f3cio com uma arquitetura monol\u00edtica. E aqui, na minha opini\u00e3o, surge uma injusti\u00e7a terr\u00edvel em rela\u00e7\u00e3o aos monol\u00edticos \u2014 supostamente a arquitetura monol\u00edtica n\u00e3o corresponde ao modelo de dom\u00ednio do neg\u00f3cio<\/b>. Se assim fosse, o sistema n\u00e3o conseguiria funcionar de forma alguma - em contrariedade \u00e0 mesma lei de Conway e ao bom senso. N\u00e3o, a arquitetura monol\u00edtica est\u00e1 completamente alinhada ao modelo de neg\u00f3cios nesta fase de desenvolvimento empresarial \u2014 quero dizer, na fase em que o sistema j\u00e1 foi criado e colocado em opera\u00e7\u00e3o. \u00c9 um fato not\u00e1vel que, independentemente da abordagem arquitet\u00f4nica, a arquitetura orientada a servi\u00e7os da vers\u00e3o 3 e a arquitetura de microsservi\u00e7os da vers\u00e3o N funcionam igualmente bem. Qual \u00e9 o truque?<\/p>\n

Tudo flui, tudo muda ou os microsservi\u00e7os s\u00e3o uma forma de combater a complexidade?<\/h2>\n

\n Antes de continuar, vamos considerar algumas ideias err\u00f4neas sobre a arquitetura de microsservi\u00e7os.<\/p>\n

Os defensores do uso da abordagem de microsservi\u00e7os frequentemente afirmam que dividir um mon\u00f3lito em microsservi\u00e7os simplifica a abordagem de desenvolvimento ao reduzir a base de c\u00f3digo de servi\u00e7os individuais. Na minha opini\u00e3o, essa afirma\u00e7\u00e3o \u00e9 totalmente absurda. S\u00e9rio, a intera\u00e7\u00e3o \u00f3bvia dentro de um mon\u00f3lito e um c\u00f3digo homog\u00eaneo parece complexa? Se fosse realmente assim, todos os projetos seriam originalmente constru\u00eddos como microsservi\u00e7os, enquanto a pr\u00e1tica mostra que a migra\u00e7\u00e3o de mon\u00f3litos para microsservi\u00e7os \u00e9 muito mais comum. A complexidade n\u00e3o desaparece, apenas se transfere de m\u00f3dulos individuais para interfaces (sejam barramentos de dados, RPC, API e outros protocolos) e sistemas orquestradores. E isso \u00e9 complicado! <\/p>\n

A vantagem de usar uma pilha heterog\u00eanea tamb\u00e9m \u00e9 duvidosa. N\u00e3o vou discutir que isso \u00e9 poss\u00edvel, mas na realidade \u00e9 raro (Aproveitando, isso deve acontecer \u2014 mas mais como consequ\u00eancia do que como vantagem).<\/p>\n

Ciclo de vida do produto e ciclo de vida do servi\u00e7o<\/h2>\n

\nD\u00ea uma olhada novamente no diagrama acima. N\u00e3o marquei por acaso o ciclo de vida reduzido de uma vers\u00e3o de neg\u00f3cios \u2014 nas condi\u00e7\u00f5es modernas, acelerar a transi\u00e7\u00e3o entre vers\u00f5es \u00e9 o que determina o sucesso do neg\u00f3cio. O sucesso do produto \u00e9 definido pela velocidade em que as hip\u00f3teses de neg\u00f3cios s\u00e3o testadas nele.<\/b>. E \u00e9 aqui que, na minha opini\u00e3o, est\u00e1 a chave da principal vantagem da arquitetura de microsservi\u00e7os. Mas vamos por partes. <\/p>\n

Vamos avan\u00e7ar para o pr\u00f3ximo n\u00edvel da evolu\u00e7\u00e3o dos sistemas de informa\u00e7\u00e3o \u2014 para a arquitetura orientada a servi\u00e7os SOA. Assim, em algum momento espec\u00edfico, destacamos em nosso produto servi\u00e7os duradouros<\/b> \u2014 duradouros no sentido de que, ao migrar entre vers\u00f5es do produto, h\u00e1 chances de que o ciclo de vida do servi\u00e7o seja mais longo do que o ciclo de vida da pr\u00f3xima vers\u00e3o do produto. Seria l\u00f3gico n\u00e3o alter\u00e1-los de forma alguma \u2014 o que nos importa \u00e9 a velocidade de transi\u00e7\u00e3o para a pr\u00f3xima vers\u00e3o<\/b>. Mas, infelizmente, somos for\u00e7ados a fazer mudan\u00e7as constantes nos servi\u00e7os \u2014 e aqui tudo serve, desde pr\u00e1ticas DevOps, containeriza\u00e7\u00e3o, e outras coisas que vierem \u00e0 mente. Mas isso ainda n\u00e3o s\u00e3o microservi\u00e7os! <\/p>\n

Microservi\u00e7os como uma ferramenta para combater a complexidade\u2026 gest\u00e3o da configura\u00e7\u00e3o<\/h2>\n

\n E \u00e9 aqui que podemos finalmente abordar o papel definidor dos microservi\u00e7os \u2014 \u00e9 uma abordagem que simplifica a gest\u00e3o da configura\u00e7\u00e3o do produto. Em termos mais detalhados, a fun\u00e7\u00e3o de cada microservi\u00e7o descreve exatamente uma fun\u00e7\u00e3o de neg\u00f3cios dentro do produto de acordo com o modelo de dom\u00ednio \u2014 e essas j\u00e1 s\u00e3o coisas que n\u00e3o vivem numa vers\u00e3o de curta dura\u00e7\u00e3o, mas sim numa oportunidade de neg\u00f3cios de longa dura\u00e7\u00e3o. E a transi\u00e7\u00e3o para a pr\u00f3xima vers\u00e3o do produto ocorre de forma literal e impercept\u00edvel \u2014 voc\u00ea altera\/adiciona um microservi\u00e7o, ou talvez apenas o esquema de sua intera\u00e7\u00e3o, e de repente se v\u00ea no futuro, deixando para tr\u00e1s concorrentes que continuam a pular entre as vers\u00f5es de seus mon\u00f3litos. Agora, imagine que voc\u00ea tem um volume suficientemente grande de microservi\u00e7os com interfaces e oportunidades de neg\u00f3cios previamente definidas. Voc\u00ea chega e constr\u00f3i a estrutura de seu produto a partir de microservi\u00e7os prontos \u2014 simplesmente desenhando um diagrama, por exemplo. Parab\u00e9ns \u2014 voc\u00ea tem uma plataforma \u2014 e agora pode clicar para construir o seu neg\u00f3cio. Sonhos, sonhos. <\/p>\n

Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h2>\n

<\/p>\n