{"id":38981,"date":"2019-10-31T22:27:10","date_gmt":"2019-10-31T19:27:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury\/"},"modified":"2019-10-31T22:27:10","modified_gmt":"2019-10-31T19:27:10","slug":"servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"Servi\u00e7os \u00f3rf\u00e3os: o lado oculto da arquitetura (micro)servi\u00e7os","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

O diretor de opera\u00e7\u00f5es do portal Banki.ru, Andrey Nikolsky, falou na confer\u00eancia do ano passado DevOpsDays Moscovo<\/a><\/noindex> sobre servi\u00e7os \u00f3rf\u00e3os: como identificar um \u00f3rf\u00e3o na infraestrutura, quais s\u00e3o os problemas dos servi\u00e7os \u00f3rf\u00e3os, o que fazer com eles, e como proceder se nada funcionar.<\/p>\n

Abaixo, voc\u00ea encontrar\u00e1 a vers\u00e3o em texto da apresenta\u00e7\u00e3o. <\/p>\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nOl\u00e1, colegas! Meu nome \u00e9 Andrey, sou respons\u00e1vel pela opera\u00e7\u00e3o na empresa Banki.ru.<\/p>\n

Temos grandes servi\u00e7os, s\u00e3o servi\u00e7os monol\u00edticos, h\u00e1 servi\u00e7os no entendimento mais cl\u00e1ssico e tamb\u00e9m servi\u00e7os muito pequenos. Em minha terminologia de trabalho, costumo dizer que, se um servi\u00e7o \u00e9 simples e pequeno, \u00e9 um microservi\u00e7o; se n\u00e3o \u00e9 muito simples e nem pequeno, \u00e9 apenas um servi\u00e7o. <\/p>\n

Vantagens dos servi\u00e7os<\/b><\/h3>\n

\nVou passar rapidamente pelas vantagens dos servi\u00e7os. <\/p>\n

\"Servi\u00e7os
\n
\nPrimeiro \u2014 escalabilidade. Voc\u00ea pode rapidamente fazer algo em um servi\u00e7o e levar para produ\u00e7\u00e3o. Se voc\u00ea recebe tr\u00e1fego, clona o servi\u00e7o. Se mais tr\u00e1fego chega, clona novamente e vive com isso. Isso \u00e9 um bom b\u00f4nus e, na verdade, quando come\u00e7amos, era considerado o mais importante, a raz\u00e3o pela qual estamos fazendo tudo isso.<\/p>\n

\"Servi\u00e7os
\n
\nEm segundo lugar, desenvolvimento isolado, onde voc\u00ea tem v\u00e1rias equipes de desenvolvimento, diferentes desenvolvedores em cada equipe, e cada equipe trabalha em seu pr\u00f3prio servi\u00e7o.<\/p>\n

Com as equipes, surgem nuances. Os desenvolvedores s\u00e3o diferentes. E existem, por exemplo, pessoas-neve<\/a><\/noindex>. Eu vi isso pela primeira vez com Maxim Dorofeev. \u00c0s vezes, pessoas-neve est\u00e3o em algumas equipes, mas em outras n\u00e3o. Isso torna os diferentes servi\u00e7os utilizados na empresa um pouco desiguais. <\/p>\n

\"Servi\u00e7os
\n
\nOlhe para a imagem: este \u00e9 um bom desenvolvedor, ele tem grandes m\u00e3os e pode fazer muita coisa. O principal problema \u00e9 de onde v\u00eam essas m\u00e3os. <\/p>\n

\"Servi\u00e7os
\n
\nOs servi\u00e7os permitem o uso de diferentes linguagens de programa\u00e7\u00e3o, mais adequadas para v\u00e1rias tarefas. Algum servi\u00e7o em Go, algum em Erlang, algum em Ruby, algo em PHP, algo em Python. Em geral, \u00e9 poss\u00edvel se expandir bastante. Aqui tamb\u00e9m h\u00e1 nuances.<\/p>\n

\"Servi\u00e7os
\n
\nA arquitetura orientada a servi\u00e7os \u00e9, acima de tudo, sobre devops. Ou seja, se voc\u00ea n\u00e3o tem automa\u00e7\u00e3o, n\u00e3o tem processo de deployment, se voc\u00ea configura manualmente, suas configura\u00e7\u00f5es podem mudar de inst\u00e2ncia de servi\u00e7o para inst\u00e2ncia, e voc\u00ea precisa entrar l\u00e1 para fazer algo, ent\u00e3o voc\u00ea est\u00e1 no inferno. <\/p>\n

Por exemplo, se voc\u00ea tem 20 servi\u00e7os e precisa fazer o deploy manualmente, voc\u00ea tem 20 consoles e ao mesmo tempo pressiona \u2018enter\u2019, como um ninja. Isso n\u00e3o \u00e9 muito bom. <\/p>\n

Se voc\u00ea tem um servi\u00e7o ap\u00f3s os testes (se houver testes, claro), e precisa ainda de um ajuste fino para que funcione em produ\u00e7\u00e3o, eu tamb\u00e9m tenho m\u00e1s not\u00edcias para voc\u00ea. <\/p>\n

Se voc\u00ea depende de servi\u00e7os espec\u00edficos da Amazon e est\u00e1 trabalhando na R\u00fassia, h\u00e1 dois meses voc\u00ea tamb\u00e9m estava dizendo \u2018Tudo est\u00e1 pegando fogo, estou bem, tudo \u00f3timo\u2019.<\/p>\n

\"Servi\u00e7os
\n
\nUsamos o Ansible para automatizar o deployment, Puppet para converg\u00eancia, Bamboo para automatiza\u00e7\u00e3o do deploy e Confluence para descrever tudo isso de alguma forma.<\/p>\n

N\u00e3o vou me aprofundar nisso, pois a apresenta\u00e7\u00e3o \u00e9 mais sobre pr\u00e1ticas de intera\u00e7\u00e3o do que sobre implementa\u00e7\u00e3o t\u00e9cnica. <\/p>\n

\"Servi\u00e7os
\n
\nJ\u00e1 tivemos, por exemplo, problemas onde o Puppet no servidor funciona com Ruby 2, enquanto alguma aplica\u00e7\u00e3o foi escrita para Ruby 1.8, e eles n\u00e3o funcionam juntos. Acontece um erro qualquer. E quando voc\u00ea precisa manter v\u00e1rias vers\u00f5es do Ruby em uma mesma m\u00e1quina, geralmente come\u00e7am os problemas. <\/p>\n

Por exemplo, para cada desenvolvedor, fornecemos um ambiente que tem praticamente tudo que temos, todos os servi\u00e7os que podem ser desenvolvidos, para que ele tenha um ambiente isolado onde pode quebrar e construir como quiser. <\/p>\n

\u00c0s vezes, \u00e9 necess\u00e1rio um pacote especialmente compilado com suporte para algo espec\u00edfico. Isso \u00e9 bastante rigoroso. Ouvi uma apresenta\u00e7\u00e3o onde a imagem do Docker pesa 45 GB. No Linux, claro, \u00e9 um pouco mais simples, tudo \u00e9 menor, mas ainda assim, n\u00e3o h\u00e1 espa\u00e7o suficiente. <\/p>\n

Al\u00e9m disso, h\u00e1 depend\u00eancias conflitantes, quando uma parte do projeto depende de uma vers\u00e3o de biblioteca, e outra parte do projeto depende de outra vers\u00e3o, e as bibliotecas n\u00e3o podem ser instaladas juntas de forma alguma. <\/p>\n

\"Servi\u00e7os
\n
\nTemos sites e servi\u00e7os em PHP 5.6, estamos envergonhados por isso, mas o que fazer? \u00c9 uma de nossas plataformas. Existem sites e servi\u00e7os em PHP 7, estes s\u00e3o mais numerosos, n\u00e3o nos envergonhamos deles. E cada desenvolvedor tem seu pr\u00f3prio banco de dados, onde ele se diverte programando. <\/p>\n

Se voc\u00ea est\u00e1 programando na empresa em uma \u00fanica linguagem, ter tr\u00eas m\u00e1quinas virtuais por desenvolvedor parece normal. Se voc\u00ea tem diferentes linguagens de programa\u00e7\u00e3o, a situa\u00e7\u00e3o piora.<\/p>\n

\"Servi\u00e7os
\n
\nVoc\u00ea tem sites e servi\u00e7os aqui, e aqui, depois mais uma plataforma para Go, uma plataforma para Ruby, e algum Redis ao lado. No final, tudo isso se transforma em um grande campo de suporte, onde algo pode quebrar a qualquer momento.<\/p>\n

\"Servi\u00e7os
\n
\nPor isso, substitu\u00edmos os recursos da linguagem de programa\u00e7\u00e3o pelo uso de diferentes frameworks, uma vez que os frameworks em PHP s\u00e3o bastante variados, possuem diferentes capacidades, comunidades distintas e suportes diversos. Assim, \u00e9 poss\u00edvel criar servi\u00e7os j\u00e1 com algo pronto para eles. <\/p>\n

Cada servi\u00e7o tem sua pr\u00f3pria equipe<\/b><\/h3>\n

\n\"Servi\u00e7os
\n
\nNossa principal vantagem, que se cristalizou ao longo dos anos, \u00e9 que cada servi\u00e7o possui sua pr\u00f3pria equipe. Isso \u00e9 conveniente para grandes projetos, pois economiza tempo com documenta\u00e7\u00e3o e os gerentes conhecem bem seus projetos. <\/p>\n

As tarefas de suporte podem ser facilmente delegadas. Por exemplo, se um servi\u00e7o de seguros falhar, a equipe que cuida do seguro imediatamente se junta para consert\u00e1-lo. <\/p>\n

Novos recursos s\u00e3o desenvolvidos rapidamente, porque quando voc\u00ea tem um servi\u00e7o at\u00f4mico, \u00e9 poss\u00edvel implementar algo novo de forma \u00e1gil. <\/p>\n

E quando voc\u00ea quebra seu servi\u00e7o, o que inevitavelmente acontece, voc\u00ea n\u00e3o afeta outros servi\u00e7os, e os desenvolvedores de outras equipes n\u00e3o v\u00eam at\u00e9 voc\u00ea com paus e dizem: 'Ei, n\u00e3o fa\u00e7a isso'. <\/p>\n

\"Servi\u00e7os
\n
\nComo sempre, existem nuances. Temos equipes est\u00e1veis, e os gerentes est\u00e3o firmemente ligados \u00e0s equipes. Existem documentos claros, e os gerentes supervisionam tudo de perto. Cada gerente tem v\u00e1rias equipes sob sua responsabilidade, e h\u00e1 um ponto de compet\u00eancia espec\u00edfico. <\/p>\n

Se as equipes s\u00e3o flutuantes (o que tamb\u00e9m acontece \u00e0s vezes), existe um bom m\u00e9todo chamado 'mapa estelar'.<\/p>\n

\"Servi\u00e7os
\n
\nVoc\u00ea tem uma lista de servi\u00e7os e pessoas. A estrela indica que a pessoa \u00e9 uma especialista naquele servi\u00e7o, enquanto o livro indica que a pessoa est\u00e1 estudando o servi\u00e7o. A tarefa da pessoa \u00e9 trocar o livro pela estrela. E se n\u00e3o houver nada escrito ao lado do servi\u00e7o, come\u00e7am os problemas, sobre os quais falarei em seguida. <\/p>\n

Como surgem servi\u00e7os \u00f3rf\u00e3os?<\/b><\/h3>\n

\n\"Servi\u00e7os
\n
\nO primeiro problema, a primeira maneira de ter um servi\u00e7o \u00f3rf\u00e3o em sua infraestrutura \u00e9 a demiss\u00e3o de pessoas. Algu\u00e9m j\u00e1 passou por isso, quando prazos chegam no neg\u00f3cio antes que as tarefas sejam avaliadas? \u00c0s vezes, os prazos s\u00e3o apertados e simplesmente n\u00e3o h\u00e1 tempo para a documenta\u00e7\u00e3o. \"Precisamos entregar o servi\u00e7o em produ\u00e7\u00e3o, depois escribemos mais.\" <\/p>\n

Se a equipe \u00e9 pequena, pode haver apenas um desenvolvedor escrevendo tudo, enquanto os outros apoiam. \"Eu escrevi a arquitetura principal, voc\u00ea pode criar as interfaces.\" Depois, em algum momento, o gerente pode sair. E nesse per\u00edodo, enquanto o gerente saiu e nenhum novo foi designado, os desenvolvedores decidem por conta pr\u00f3pria para onde o servi\u00e7o est\u00e1 indo, o que est\u00e1 acontecendo. E como sabemos (vamos voltar alguns slides), em algumas equipes h\u00e1 pessoas especiais, \u00e0s vezes um desses leads. Ent\u00e3o ele se demite, e obtemos um servi\u00e7o \u00f3rf\u00e3o. <\/p>\n

\"Servi\u00e7os
\n
\nEnquanto isso, as tarefas de suporte e de neg\u00f3cios n\u00e3o desaparecem, elas se acumulam no backlog. Se durante o desenvolvimento do servi\u00e7o houveram algum erro arquitet\u00f4nico, eles tamb\u00e9m se acumulam no backlog. O servi\u00e7o vai lentamente degradando. <\/p>\n

Como identificar um \u00f3rf\u00e3o?<\/b> <\/h3>\n

\nEssa lista descreve bem a situa\u00e7\u00e3o. Quem se identificou com algo em sua infraestrutura?<\/p>\n

\"Servi\u00e7os
\n
\nSobre as solu\u00e7\u00f5es documentadas: temos um servi\u00e7o e, no geral, ele funciona, possui um manual de duas p\u00e1ginas sobre como us\u00e1-lo, mas como ele funciona internamente, ningu\u00e9m sabe. <\/p>\n

Ou, por exemplo, temos um encurtador de links. No nosso caso, agora temos tr\u00eas encurtadores de links para diferentes fins em diferentes servi\u00e7os. Essas s\u00e3o consequ\u00eancias. <\/p>\n

\"Servi\u00e7os
\n
\nAgora vou ser o capit\u00e3o \u00f3bvio. O que deve ser feito? Primeiro, o servi\u00e7o deve ser passado para outro gerente, outra equipe. Se seu l\u00edder ainda n\u00e3o se demitiu, voc\u00ea deve incluir algu\u00e9m que entenda um pouco do servi\u00e7o na nova equipe quando perceber que ele est\u00e1 se tornando um \u00f3rf\u00e3o. <\/p>\n

A principal coisa: voc\u00ea deve ter procedimentos de transfer\u00eancia escritos claramente. No nosso caso, geralmente sou eu que supervisiono isso, porque preciso que tudo funcione. Para os gerentes, \u00e9 importante que seja entregue rapidamente, e o que acontecer depois j\u00e1 n\u00e3o \u00e9 t\u00e3o relevante para eles. <\/p>\n

\"Servi\u00e7os
\n
\nA pr\u00f3xima maneira de criar um servi\u00e7o sem dono \u00e9: 'Vamos terceirizar, assim ser\u00e1 mais r\u00e1pido, e depois passaremos para a equipe'. \u00c9 claro que todos t\u00eam algum planejamento na equipe, uma fila de espera. Muitas vezes, o cliente empresarial pensa que os terceirizados far\u00e3o exatamente como o departamento t\u00e9cnico da empresa. No entanto, seus motivadores s\u00e3o diferentes. Na terceiriza\u00e7\u00e3o, podemos encontrar solu\u00e7\u00f5es tecnol\u00f3gicas estranhas e algoritmos incomuns.<\/p>\n

\"Servi\u00e7os
\n
\nPor exemplo, tivemos um servi\u00e7o onde o Sphinx estava em lugares inesperados. Vou contar mais sobre o que tivemos que fazer mais adiante. <\/p>\n

Os terceirizados costumam ter frameworks pr\u00f3prios. \u00c9 simplesmente PHP puro com c\u00f3pia e colagem de projetos anteriores, onde voc\u00ea pode encontrar de tudo. H\u00e1 grandes gambiarras nos scripts de deploy, quando voc\u00ea precisa modificar algumas linhas em um arquivo usando scripts Bash complexos, e esses scripts de deploy s\u00e3o chamados por algum terceiro. No final, voc\u00ea altera o sistema de deploy, escolhe outra coisa e, de repente, seu servi\u00e7o para de funcionar. Porque precis\u00e1vamos colocar mais 8 links entre diferentes pastas. Ou ocorre que mil registros funcionam, mas cem mil j\u00e1 n\u00e3o funcionam. <\/p>\n

Continuarei no comando. A aceita\u00e7\u00e3o de um servi\u00e7o terceirizado \u00e9 um procedimento obrigat\u00f3rio. Algu\u00e9m j\u00e1 passou pela situa\u00e7\u00e3o em que um servi\u00e7o terceirizado chega, mas n\u00e3o \u00e9 aceito? Isso n\u00e3o \u00e9 t\u00e3o comum quanto um servi\u00e7o sem dono, mas ainda assim. <\/p>\n

\"Servi\u00e7os
\n
\nO servi\u00e7o precisa ser verificado, \u00e9 necess\u00e1rio revisar o servi\u00e7o e mudar as senhas. Tivemos um caso em que nos foi apresentado um servi\u00e7o onde a administra\u00e7\u00e3o dizia \"if login == 'admin' && password == 'admin'...\", escrito diretamente no c\u00f3digo. N\u00f3s ficamos aqui pensando, e isso est\u00e1 sendo feito por pessoas em 2018?<\/p>\n

Testar o volume de armazenamento tamb\u00e9m \u00e9 essencial. \u00c9 necess\u00e1rio observar o que acontecer\u00e1 com cem mil registros antes de voc\u00ea colocar esse servi\u00e7o em produ\u00e7\u00e3o. <\/p>\n

\"Servi\u00e7os
\n
\nN\u00e3o deve ser vergonhoso enviar um servi\u00e7o para rework. Quando voc\u00ea diz: 'N\u00e3o aceitaremos esse servi\u00e7o, temos 20 tarefas, fa\u00e7am-nas, ent\u00e3o aceitaremos', isso \u00e9 normal. A consci\u00eancia n\u00e3o deve pesar porque voc\u00ea colocar\u00e1 o gerente em uma situa\u00e7\u00e3o dif\u00edcil ou porque a empresa gastar\u00e1 dinheiro. Depois, a empresa gastar\u00e1 ainda mais.<\/p>\n

Tivemos um caso em que decidimos realizar um projeto piloto terceirizado.<\/p>\n

\"Servi\u00e7os
\n
\nEle foi entregue a tempo, e esse foi o \u00fanico crit\u00e9rio de qualidade. Portanto, fizeram mais um projeto piloto, j\u00e1 nem totalmente piloto. Esses servi\u00e7os foram aceitos, de maneira administrativa disseram, aqui est\u00e1 o seu c\u00f3digo, aqui est\u00e1 a equipe, aqui est\u00e1 o seu gerente. Os servi\u00e7os realmente come\u00e7aram a gerar lucro. No entanto, na pr\u00e1tica, eles ainda permanecem \u00f3rf\u00e3os, ningu\u00e9m entende como funcionam, e os gerentes se afastam de suas tarefas. <\/p>\n

\"Servi\u00e7os
\n
\nH\u00e1 tamb\u00e9m um conceito excelente \u2014 desenvolvimento clandestino. Quando algum departamento, normalmente o de marketing, quer testar uma hip\u00f3tese e encomenda o servi\u00e7o inteiro por outsourcing. Come\u00e7a a receber tr\u00e1fego, eles fecham documentos, assinam contratos com o prestador, entra em opera\u00e7\u00e3o e dizem: \u2018Pessoal, temos um servi\u00e7o aqui, j\u00e1 est\u00e1 recebendo tr\u00e1fego, ele nos traz dinheiro, vamos aceit\u00e1-lo\u2019. N\u00f3s ficamos: \u2018Opa, como assim?\u2019.<\/p>\n

\"Servi\u00e7os
\n
\nE mais uma maneira de obter um servi\u00e7o \u00f3rf\u00e3o: quando alguma equipe de repente fica sobrecarregada, a ger\u00eancia diz: \u2018Vamos passar o servi\u00e7o dessa equipe para outra equipe, que est\u00e1 com menos carga de trabalho\u2019. E depois passamos para uma terceira equipe e mudamos o gerente. E no final, temos novamente um \u00f3rf\u00e3o.<\/p>\n

Qual \u00e9 o problema com os \u00f3rf\u00e3os?<\/b><\/h3>\n

\n\"Servi\u00e7os
\n
\nQuem n\u00e3o sabe, este \u00e9 o navio de guerra Wasa, lan\u00e7ado na Su\u00e9cia, famoso por ter afundado cinco minutos ap\u00f3s ser botado na \u00e1gua. E o rei da Su\u00e9cia, ali\u00e1s, n\u00e3o puniu ningu\u00e9m por isso. Foi constru\u00eddo por duas gera\u00e7\u00f5es de engenheiros que n\u00e3o sabiam construir tais navios. Um efeito previs\u00edvel.<\/p>\n

O navio poderia ter afundado, ali\u00e1s, de forma muito pior, por exemplo, quando o rei j\u00e1 estivesse a bordo indo para algum lugar em uma tempestade. Mas assim, afundou logo, de acordo com o \u00e1gil isso \u00e9 bom \u2014 falhar cedo. <\/p>\n

Se falhamos cedo, geralmente n\u00e3o h\u00e1 problemas. Por exemplo, durante a aceita\u00e7\u00e3o, foi enviado para melhorias. Mas se falhamos j\u00e1 na produ\u00e7\u00e3o, quando o dinheiro foi investido, podem haver problemas. Consequ\u00eancias, como s\u00e3o chamadas nos neg\u00f3cios.<\/p>\n

Quais s\u00e3o os perigos dos servi\u00e7os \u00f3rf\u00e3os:<\/p>\n