{"id":32777,"date":"2019-10-31T21:48:52","date_gmt":"2019-10-31T18:48:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/netramesh-legkovesnoe-service-mesh-reshenie\/"},"modified":"2019-10-31T21:48:52","modified_gmt":"2019-10-31T18:48:52","slug":"netramesh-legkovesnoe-service-mesh-reshenie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","title":{"rendered":"Netramesh \u2013 uma solu\u00e7\u00e3o de service mesh leve","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ao migrar de uma aplica\u00e7\u00e3o monol\u00edtica para uma arquitetura de microservi\u00e7os, enfrentamos novos desafios.<\/p>\n

<\/p>\n

Em uma aplica\u00e7\u00e3o monol\u00edtica, geralmente \u00e9 suficiente identificar em qual parte do sistema ocorreu um erro. Provavelmente, o problema est\u00e1 no pr\u00f3prio c\u00f3digo do mon\u00f3lito ou no banco de dados. Mas quando come\u00e7amos a investigar problemas em uma arquitetura de microservi\u00e7os, as coisas j\u00e1 n\u00e3o s\u00e3o t\u00e3o evidentes. \u00c9 necess\u00e1rio rastrear todo o caminho que a solicita\u00e7\u00e3o percorreu do in\u00edcio ao fim, isolando-o entre centenas de microservi\u00e7os. Al\u00e9m disso, muitos deles ainda possuem seus pr\u00f3prios reposit\u00f3rios, onde podem surgir tanto erros l\u00f3gicos quanto problemas de desempenho e resili\u00eancia.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Procurei por muito tempo uma ferramenta que me ajudasse a lidar com tais problemas (escrevi sobre isso no Habr: 1<\/a><\/noindex>, 2<\/a><\/noindex>), mas acabei criando minha pr\u00f3pria solu\u00e7\u00e3o open source. Neste artigo, compartilho as vantagens da abordagem service mesh e apresento uma nova ferramenta para sua implementa\u00e7\u00e3o. <\/p>\n

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

O tracing distribu\u00eddo \u00e9 uma solu\u00e7\u00e3o comum para o problema de localiza\u00e7\u00e3o de erros em sistemas distribu\u00eddos. Mas e se a abordagem de coleta de informa\u00e7\u00f5es sobre intera\u00e7\u00f5es de rede ainda n\u00e3o foi implementada no sistema, ou, pior ainda, em uma parte do sistema funciona adequadamente, mas em outra ela n\u00e3o foi adicionada aos servi\u00e7os antigos? Para identificar a verdadeira causa raiz do problema, \u00e9 necess\u00e1rio ter uma vis\u00e3o completa do que est\u00e1 acontecendo no sistema. \u00c9 especialmente importante entender quais microservi\u00e7os est\u00e3o envolvidos nos principais caminhos cr\u00edticos para o neg\u00f3cio.<\/p>\n

<\/p>\n

Aqui, a abordagem de service mesh pode nos ajudar, pois cuida de toda a maquinaria de coleta de informa\u00e7\u00f5es de rede em um n\u00edvel inferior ao funcionamento dos pr\u00f3prios servi\u00e7os. Essa abordagem nos permite interceptar todo o tr\u00e1fego e analis\u00e1-lo em tempo real. Al\u00e9m disso, os aplicativos n\u00e3o precisam saber nada sobre isso.<\/p>\n

<\/p>\n

Abordagem de service mesh<\/h1>\n

<\/p>\n

A principal ideia da abordagem service mesh \u00e9 adicionar mais uma camada de infraestrutura sobre a rede, que nos permitir\u00e1 realizar qualquer opera\u00e7\u00e3o com a intera\u00e7\u00e3o entre servi\u00e7os. A maioria das implementa\u00e7\u00f5es funciona da seguinte maneira: a cada microservi\u00e7o, \u00e9 adicionado um cont\u00eainer sidecar com um proxy transparente, pelo qual todo o tr\u00e1fego de entrada e sa\u00edda do servi\u00e7o \u00e9 direcionado. E \u00e9 exatamente aqui que podemos realizar balanceamento de carga do cliente, aplicar pol\u00edticas de seguran\u00e7a, impor limita\u00e7\u00f5es na quantidade de requisi\u00e7\u00f5es e coletar informa\u00e7\u00f5es importantes sobre a intera\u00e7\u00e3o dos servi\u00e7os em produ\u00e7\u00e3o.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Solu\u00e7\u00f5es<\/h1>\n

<\/p>\n

J\u00e1 existem v\u00e1rias implementa\u00e7\u00f5es dessa abordagem: Istio<\/a><\/noindex> e linkerd2<\/a><\/noindex>. Elas fornecem muitas funcionalidades prontas para uso. No entanto, isso tamb\u00e9m traz um grande overhead em recursos. Quanto maior o cluster onde esse sistema opera, mais recursos ser\u00e3o necess\u00e1rios para manter a nova infraestrutura. No Avito, utilizamos clusters Kubernetes que cont\u00eam milhares de inst\u00e2ncias de servi\u00e7os (e esse n\u00famero continua a crescer rapidamente). Na implementa\u00e7\u00e3o atual, o Istio consome cerca de 300 MB de mem\u00f3ria RAM para cada inst\u00e2ncia de servi\u00e7o. Devido \u00e0 grande quantidade de funcionalidades, o balanceamento transparente tamb\u00e9m impacta o tempo de resposta total dos servi\u00e7os (at\u00e9 10 ms).<\/p>\n

<\/p>\n

Como resultado, analisamos quais funcionalidades realmente precisamos agora e decidimos que a principal raz\u00e3o pela qual come\u00e7amos a implementar essas solu\u00e7\u00f5es era a capacidade de coletar informa\u00e7\u00f5es de rastreamento de todo o sistema de forma transparente. Tamb\u00e9m quer\u00edamos ter controle sobre a intera\u00e7\u00e3o entre servi\u00e7os e realizar diferentes manipula\u00e7\u00f5es com os cabe\u00e7alhos que s\u00e3o transmitidos entre os servi\u00e7os. <\/p>\n

<\/p>\n

Assim, chegamos \u00e0 nossa solu\u00e7\u00e3o: Netramesh<\/a><\/noindex>.<\/p>\n

<\/p>\n

Netramesh<\/h1>\n

<\/p>\n

Netramesh<\/a><\/noindex> \u2014 \u00e9 uma solu\u00e7\u00e3o de service mesh leve com escalabilidade infinita, independentemente do n\u00famero de servi\u00e7os no sistema.<\/p>\n

<\/p>\n

Os principais objetivos da nova solu\u00e7\u00e3o eram um pequeno overhead em recursos e alta performance. Entre as principais funcionalidades, quer\u00edamos poder enviar spans de rastreamento para o nosso sistema Jaeger de forma transparente desde o in\u00edcio.<\/p>\n

<\/p>\n

Hoje, a maioria das solu\u00e7\u00f5es em nuvem \u00e9 implementada em Golang. E, claro, isso tem suas raz\u00f5es. Escrever aplica\u00e7\u00f5es de rede em Golang, que funcionam de forma ass\u00edncrona com entrada e sa\u00edda e se escalam conforme necess\u00e1rio para os n\u00facleos, \u00e9 conveniente e bastante simples. E, o que tamb\u00e9m \u00e9 muito importante, o desempenho \u00e9 suficiente para resolver essa tarefa. Portanto, n\u00f3s tamb\u00e9m escolhemos Golang.<\/p>\n

<\/p>\n

Desempenho<\/h1>\n

<\/p>\n

Focamos nossos esfor\u00e7os em alcan\u00e7ar o desempenho m\u00e1ximo. Para uma solu\u00e7\u00e3o que \u00e9 implantada pr\u00f3xima a cada inst\u00e2ncia do servi\u00e7o, \u00e9 necess\u00e1rio um baixo consumo de mem\u00f3ria RAM e tempo de CPU. E, claro, a lat\u00eancia de resposta tamb\u00e9m deve ser a menor poss\u00edvel.<\/p>\n

<\/p>\n

Vamos ver quais resultados obtivemos. <\/p>\n

<\/p>\n

RAM<\/h2>\n

<\/p>\n

O Netramesh consome ~10Mb sem tr\u00e1fego e 50Mb no m\u00e1ximo com carga de at\u00e9 10000 RPS em uma \u00fanica inst\u00e2ncia.<\/p>\n

<\/p>\n

O proxy Istio envoy consome sempre ~300Mb em nossos clusters com milhares de inst\u00e2ncias. Isso n\u00e3o permite escal\u00e1-lo para todo o cluster.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Com o Netramesh, conseguimos uma redu\u00e7\u00e3o no consumo de mem\u00f3ria de ~10 vezes.<\/p>\n

<\/p>\n

CPU<\/h2>\n

<\/p>\n

O uso de CPU \u00e9 relativamente igual sob carga. Depende da quantidade de requisi\u00e7\u00f5es por unidade de tempo ao sidecar. Os valores em 3000 requisi\u00e7\u00f5es por segundo no pico s\u00e3o:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

H\u00e1 outro ponto importante: o Netramesh \u00e9 uma solu\u00e7\u00e3o sem plano de controle e, sem carga, n\u00e3o consome tempo de CPU. Com Istio, os sidecars sempre atualizam os endpoints dos servi\u00e7os. No final, podemos ver essa situa\u00e7\u00e3o sem carga:<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Usamos HTTP\/1 para a intera\u00e7\u00e3o entre os servi\u00e7os. O aumento do tempo de resposta do Istio ao ser proxyado atrav\u00e9s do envoy era de at\u00e9 5-10ms, o que \u00e9 bastante para servi\u00e7os que est\u00e3o prontos para responder em milissegundos. Com o Netramesh, esse tempo foi reduzido para 0,5-2ms.<\/p>\n

<\/p>\n

Escalabilidade<\/h1>\n

<\/p>\n

A pequena quantidade de recursos gastos por cada proxy permite coloc\u00e1-lo pr\u00f3ximo a cada servi\u00e7o. O Netramesh foi intencionalmente criado sem componente de plano de controle para manter a leveza de cada sidecar. Frequentemente, em solu\u00e7\u00f5es de service mesh, o plano de controle espalha informa\u00e7\u00f5es de descoberta de servi\u00e7o para cada sidecar. Juntamente com isso, tamb\u00e9m vem informa\u00e7\u00f5es sobre timeouts e configura\u00e7\u00f5es de balanceamento. Tudo isso permite fazer muitas coisas \u00fateis, mas, infelizmente, incham os sidecars em tamanho. <\/p>\n

<\/p>\n

Descoberta de servi\u00e7o<\/h1>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

O Netramesh n\u00e3o adiciona quaisquer mecanismos adicionais para a descoberta de servi\u00e7os. Todo o tr\u00e1fego \u00e9 proxyado de forma transparente atrav\u00e9s do sidecar netra. <\/p>\n

<\/p>\n

Netramesh suporta o protocolo de aplica\u00e7\u00e3o HTTP\/1. Para sua defini\u00e7\u00e3o, \u00e9 utilizada uma lista de portas configur\u00e1vel. Normalmente, h\u00e1 v\u00e1rias portas no sistema que lidam com a comunica\u00e7\u00e3o via HTTP. Por exemplo, usamos 80, 8890 e 8080 para a intera\u00e7\u00e3o entre servi\u00e7os e solicita\u00e7\u00f5es externas. Nesse caso, elas podem ser configuradas atrav\u00e9s de uma vari\u00e1vel de ambiente. NETRA_HTTP_PORTS<\/code>.<\/p>\n

<\/p>\n

Se voc\u00ea estiver usando Kubernetes como orquestrador e seu mecanismo de entidades Service para a intera\u00e7\u00e3o entre servi\u00e7os dentro do cluster, o mecanismo permanece exatamente o mesmo. Primeiro, o microservi\u00e7o obt\u00e9m o endere\u00e7o IP do servi\u00e7o usando kube-dns e estabelece uma nova conex\u00e3o com ele. Esta conex\u00e3o \u00e9 inicialmente feita com o netra-sidecar e todos os pacotes TCP chegam primeiramente ao netra. Em seguida, o netra-sidecar estabelece a conex\u00e3o com o destino original. O NAT no IP do pod no n\u00f3 permanece exatamente o mesmo que sem o netra.<\/p>\n

<\/p>\n

Rastreamento distribu\u00eddo e passando o contexto<\/h1>\n

<\/p>\n

O Netramesh oferece a funcionalidade necess\u00e1ria para enviar spans de rastreamento sobre a intera\u00e7\u00e3o HTTP. O netra-sidecar analisa o protocolo HTTP, mede a lat\u00eancia das solicita\u00e7\u00f5es e extrai as informa\u00e7\u00f5es necess\u00e1rias dos cabe\u00e7alhos HTTP. No final, obtemos todos os rastros em um sistema Jaeger unificado. Para uma configura\u00e7\u00e3o mais refinada, tamb\u00e9m \u00e9 poss\u00edvel usar vari\u00e1veis de ambiente fornecidas pela biblioteca oficial. jaeger go library<\/a><\/noindex>. <\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

\"Netramesh <\/p>\n

<\/p>\n

Mas h\u00e1 um problema. Enquanto os servi\u00e7os n\u00e3o gerarem e passarem um cabe\u00e7alho uber espec\u00edfico, n\u00e3o veremos os spans de rastreamento conectados no sistema. E isso \u00e9 necess\u00e1rio para localizar rapidamente as causas dos problemas. Aqui, o Netramesh novamente tem uma solu\u00e7\u00e3o. O proxy l\u00ea os cabe\u00e7alhos HTTP e, se n\u00e3o houver um uber trace id, ele o gera. O Netramesh tamb\u00e9m armazena informa\u00e7\u00f5es sobre solicita\u00e7\u00f5es de entrada e sa\u00edda no sidecar e as relaciona enriquecendo os cabe\u00e7alhos necess\u00e1rios das solicita\u00e7\u00f5es de sa\u00edda. Tudo o que precisa ser feito nos servi\u00e7os \u00e9 passar apenas um cabe\u00e7alho. X-Request-Id<\/code>, que pode ser configurado atrav\u00e9s de uma vari\u00e1vel de ambiente. NETRA_HTTP_REQUEST_ID_HEADER_NAME<\/code>. Para gerenciar o tamanho do contexto no Netramesh, \u00e9 poss\u00edvel definir as seguintes vari\u00e1veis de ambiente: NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS<\/code> (tempo durante o qual o contexto ser\u00e1 mantido) e NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL<\/code> (frequ\u00eancia de limpeza do contexto).<\/p>\n

<\/p>\n

Tamb\u00e9m \u00e9 poss\u00edvel combinar v\u00e1rios caminhos no seu sistema, marcando-os com um marcador de sess\u00e3o especial. O Netra permite configurar HTTP_HEADER_TAG_MAP<\/code> para transformar cabe\u00e7alhos HTTP em tags correspondentes de rastreamento. Isso pode ser particularmente \u00fatil para testes. Ap\u00f3s a conclus\u00e3o de um teste funcional, \u00e9 poss\u00edvel verificar qual parte do sistema foi afetada, filtrando pela chave de sess\u00e3o correspondente.<\/p>\n

<\/p>\n

Defini\u00e7\u00e3o da fonte da solicita\u00e7\u00e3o<\/h1>\n

<\/p>\n

Para determinar de onde a solicita\u00e7\u00e3o veio, voc\u00ea pode utilizar a funcionalidade de adi\u00e7\u00e3o autom\u00e1tica de cabe\u00e7alho com a fonte. Com a vari\u00e1vel de ambiente NETRA_HTTP_X_SOURCE_HEADER_NAME<\/code> \u00e9 poss\u00edvel definir o nome do cabe\u00e7alho que ser\u00e1 automaticamente aplicado. Com NETRA_HTTP_X_SOURCE_VALUE<\/code> \u00e9 poss\u00edvel definir o valor que ser\u00e1 atribu\u00eddo ao cabe\u00e7alho X-Source em todas as solicita\u00e7\u00f5es de sa\u00edda. <\/p>\n

<\/p>\n

Isso permite a dissemina\u00e7\u00e3o uniforme deste cabe\u00e7alho \u00fatil por toda a rede. Em seguida, voc\u00ea pode us\u00e1-lo em servi\u00e7os e adicion\u00e1-lo aos logs e m\u00e9tricas.<\/p>\n

<\/p>\n

Roteamento de tr\u00e1fego e a estrutura interna do Netramesh<\/h1>\n

<\/p>\n

O Netramesh consiste em dois componentes principais. O primeiro, netra-init, estabelece regras de rede para intercepta\u00e7\u00e3o de tr\u00e1fego. Ele utiliza iptables redirect rules<\/a><\/noindex> para interceptar todo ou parte do tr\u00e1fego em um sidecar, que \u00e9 o segundo componente principal do Netramesh. Voc\u00ea pode configurar quais portas devem ser interceptadas em sess\u00f5es TCP de entrada e sa\u00edda: INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS<\/code>.<\/p>\n

<\/p>\n

Al\u00e9m disso, a ferramenta possui uma capacidade interessante \u2014 roteamento probabil\u00edstico. Se voc\u00ea usar o Netramesh exclusivamente para coletar spans de rastreamento, \u00e9 poss\u00edvel economizar recursos em um ambiente de produ\u00e7\u00e3o, ativando o roteamento probabil\u00edstico usando as vari\u00e1veis NETRA_INBOUND_PROBABILITY<\/code> e NETRA_OUTBOUND_PROBABILITY<\/code> (de 0 a 1). O valor padr\u00e3o \u00e9 1 (todo o tr\u00e1fego \u00e9 interceptado).<\/p>\n

<\/p>\n

Ap\u00f3s uma intercepta\u00e7\u00e3o bem-sucedida, o sidecar do netra aceita uma nova conex\u00e3o e utiliza a SO_ORIGINAL_DST<\/code> op\u00e7\u00e3o de soquete para obter o destino original. Em seguida, o Netra abre uma nova conex\u00e3o para o IP original e estabelece uma comunica\u00e7\u00e3o TCP bidirecional entre as partes, ouvindo todo o tr\u00e1fego que passa. Se a porta for definida como HTTP, o Netra tenta analis\u00e1-la e rastre\u00e1-la. Se a an\u00e1lise de HTTP falhar, o Netra faz um fallback para TCP e proxy transparentemente os bytes.<\/p>\n

<\/p>\n

Constru\u00e7\u00e3o do gr\u00e1fico de depend\u00eancias<\/h1>\n

<\/p>\n

Ap\u00f3s receber uma grande quantidade de informa\u00e7\u00f5es de tracing no Jaeger, \u00e9 desej\u00e1vel obter um gr\u00e1fico completo de intera\u00e7\u00f5es no sistema. Mas se seu sistema estiver bastante sobrecarregado e bilh\u00f5es de spans de tracing se acumularem em um dia, a agrega\u00e7\u00e3o deles se torna uma tarefa complexa. Existe um m\u00e9todo oficial para isso: spark-dependencies<\/a><\/noindex>. No entanto, isso levar\u00e1 horas para construir o gr\u00e1fico completo e exigir\u00e1 extrair do Jaeger todo o conjunto de dados das \u00faltimas 24 horas. <\/p>\n

<\/p>\n

Se voc\u00ea estiver usando Elasticsearch para armazenar spans de tracing, pode aproveitar uma simples utilidade em Golang<\/a><\/noindex>, que construir\u00e1 um gr\u00e1fico semelhante em minutos, utilizando as caracter\u00edsticas e capacidades do Elasticsearch.<\/p>\n

<\/p>\n

\"Netramesh<\/p>\n

<\/p>\n

Como usar o Netramesh<\/h1>\n

<\/p>\n

O Netra pode ser facilmente adicionado a qualquer servi\u00e7o operando sob qualquer orquestrador. Voc\u00ea pode ver um exemplo aqui<\/a><\/noindex>.<\/p>\n

<\/p>\n

Atualmente, o Netra n\u00e3o possui a capacidade de inje\u00e7\u00e3o autom\u00e1tica de sidecar nos servi\u00e7os, mas h\u00e1 planos para implementa\u00e7\u00e3o. <\/p>\n

<\/p>\n

O futuro do Netramesh<\/h1>\n

<\/p>\n

O principal objetivo Netramesh<\/a><\/noindex> \u00e9 alcan\u00e7ar baixos custos de recursos e alta performance, oferecendo funcionalidades essenciais para observabilidade e controle da intera\u00e7\u00e3o entre servi\u00e7os. <\/p>\n

<\/p>\n

No futuro, o Netramesh ter\u00e1 suporte a outros protocolos de camada de aplica\u00e7\u00e3o al\u00e9m do HTTP. Em breve, a capacidade de roteamento L7 estar\u00e1 dispon\u00edvel.<\/p>\n

<\/p>\n

Utilize o Netramesh se voc\u00ea estiver enfrentando problemas semelhantes e envie-nos suas perguntas e sugest\u00f5es.<\/p>\n

Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u043e\u0442 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043a \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u043c\u044b \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u043e\u0432\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438. \u0412 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0438 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0438\u0442\u044c, \u0432 \u043a\u0430\u043a\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u0430 \u043e\u0448\u0438\u0431\u043a\u0430. \u0421\u043a\u043e\u0440\u0435\u0435 \u0432\u0441\u0435\u0433\u043e, \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0432 \u043a\u043e\u0434\u0435 \u0441\u0430\u043c\u043e\u0433\u043e \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u0430, \u043b\u0438\u0431\u043e \u0432 \u0431\u0430\u0437\u0435 \u0434\u0430\u043d\u043d\u044b\u0445. \u041d\u043e \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u043d\u0430\u0447\u0438\u043d\u0430\u0435\u043c \u0438\u0441\u043a\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0432 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435, \u0432\u0441\u0451 \u0443\u0436\u0435 \u043d\u0435 \u0442\u0430\u043a \u043e\u0447\u0435\u0432\u0438\u0434\u043d\u043e. \u041d\u0443\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0432\u0435\u0441\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24554,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32777","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Netramesh \u2013 solu\u00e7\u00e3o de service mesh leve | ProHoster","description":"Durante a transi\u00e7\u00e3o de um aplicativo monol\u00edtico para uma arquitetura de microservi\u00e7os, nos deparamos com novos problemas. Em um aplicativo monol\u00edtico, geralmente \u00e9 suficiente apenas determinar em qual parte do sistema ocorreu.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Netramesh \u2013 \u043b\u0435\u0433\u043a\u043e\u0432\u0435\u0441\u043d\u043e\u0435 service mesh \u0440\u0435\u0448\u0435\u043d\u0438\u0435 | ProHoster","og:description":"\u0412 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0435 \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0430 \u043e\u0442 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043a \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u043c\u044b \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u043c\u0441\u044f \u0441 \u043d\u043e\u0432\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438. \u0412 \u043c\u043e\u043d\u043e\u043b\u0438\u0442\u043d\u043e\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0438 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0438\u0442\u044c, \u0432 \u043a\u0430\u043a\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u0430.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/netramesh-legkovesnoe-service-mesh-reshenie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:48:52+00:00","article:modified_time":"2019-10-31T18:48:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32777","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 12:29:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:20:44","updated":"2026-01-21 12:29:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/32777","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=32777"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/32777\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/24554"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=32777"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=32777"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=32777"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}