Especialistas da Alibaba Cloud explicam a tendência de desenvolvimento da rede de serviços em 2020

Autor | Wang Xining Alibaba Especialista Técnico Sênior

Siga a conta pública "Alibaba Cloud Native" e participe da interação da mensagem no final do artigo, ou seja, você terá a oportunidade de receber benefícios de doação de livros!

Este artigo foi retirado do livro "Análise e prática da Istio Service Grid Technology", escrito por Wang Yuning, especialista técnico sênior do Alibaba Cloud. A grande tendência de desenvolvimento introduziu de forma sistemática e abrangente o conhecimento relevante da grade de serviços do Istio. Você só precisa ter prazer em participar da interação no final da conta pública, somos responsáveis ​​pelo pagamento da conta! Livro técnico homem essencial "Istio serviço de análise de tecnologia de grade e prática" colarinho livre ~

É apontado em idiomas estrangeiros que a tecnologia Service Mesh terá os três principais desenvolvimentos a seguir em 2020:

• Crescente demanda da rede de serviços;
• O Istio
  é difícil de bater e pode se tornar o padrão de fato da tecnologia de malha de serviço;
• Com o surgimento de mais casos de uso de malhas de serviço, o WebAssembly trará novas possibilidades.

O que é uma malha de serviço

O relatório de análise do Gartner 2018 sobre as tendências da tecnologia da grade de serviços mostra uma série de tecnologias da grade de serviços.A base para dividir as tecnologias da grade de serviços baseia-se em se o código de serviço do aplicativo deve estar ciente de sua grade de serviços e se está bloqueada ou o grau de bloqueio .

A tecnologia de grade baseada na estrutura de programação pode ajudar os desenvolvedores a criar um serviço bem estruturado, mas isso levará a um forte acoplamento do código do aplicativo e a estrutura e o ambiente de tempo de execução. A tecnologia de malha de serviço baseada nos agentes Sidecar não define essas barreiras para os desenvolvedores, facilita o gerenciamento e a manutenção e pode fornecer um método mais flexível para configurar políticas de tempo de execução.

Em um ambiente de microsserviços, um único aplicativo pode ser decomposto em vários componentes independentes e implantado como serviços distribuídos.Esses serviços são geralmente sem estado, transitórios, escalonáveis ​​dinamicamente e executados em sistemas de orquestração de contêiner (como Kubernetes).

A grade de serviço geralmente consiste no plano de controle e no plano de dados. Especificamente, o plano de controle é um conjunto de serviços em execução em um espaço para nome dedicado. Esses serviços executam algumas funções de controle e gerenciamento, incluindo a agregação de dados de telemetria, o fornecimento de APIs voltadas para o usuário e o fornecimento de dados de controle para agentes do plano de dados. O plano de dados consiste em uma série de agentes transparentes em execução ao lado de cada instância de serviço. Esses agentes lidam automaticamente com todo o tráfego de e para o serviço.Por serem transparentes, eles agem como uma pilha de rede fora de processo, enviando dados de telemetria para o plano de controle e recebendo sinais de controle do plano de controle.

As instâncias de serviço podem ser iniciadas, paradas, destruídas, reconstruídas ou substituídas conforme necessário. Portanto, esses serviços exigem um middleware de comunicação para oferecer suporte aos recursos de descoberta dinâmica e de conexão automática, para que esses serviços possam se comunicar de maneira segura, dinâmica e confiável.Esta é a função suportada pela grade de serviço.

A grade de serviço é uma camada de infraestrutura dedicada que torna a comunicação serviço a serviço mais segura, rápida e confiável. Se você estiver criando um aplicativo nativo da nuvem, precisará de uma malha de serviço. No ano passado, a malha de serviço se tornou um componente essencial dos programas nativos da nuvem e entrega solicitações de forma confiável por meio de topologias de serviço complexas que contêm aplicativos modernos nativos da nuvem. De fato, as malhas de serviço geralmente são implementadas como uma combinação de proxies de rede leves que são implantados com o código do aplicativo sem saber o que é o aplicativo.

O conceito de malha de serviço como uma camada separada está relacionado ao aumento de aplicativos nativos da nuvem. No modelo nativo da nuvem, um único aplicativo pode conter centenas de serviços, cada serviço pode ter milhares de instâncias e cada instância pode estar em um estado de constante mudança. É por isso que coordenadores como o Kubernetes estão se tornando mais populares e necessários. A comunicação entre esses serviços não apenas se torna cada vez mais complexa, mas também a parte mais comum do ambiente de tempo de execução; portanto, o gerenciamento da comunicação entre esses serviços é fundamental para garantir desempenho e confiabilidade de ponta a ponta.

A malha de serviço é um modelo de rede, localizado na camada de abstração acima do TCP / IP. Ele assume que a rede subjacente de três ou quatro camadas existe e pode transferir bytes de um ponto para outro. Ele também pressupõe que a rede não é tão confiável quanto outros aspectos do ambiente; portanto, a rede de serviço também deve ser capaz de lidar com falhas de rede. De certa forma, a malha de serviço é semelhante ao TCP / IP. Assim como a pilha do protocolo TCP abstrai o mecanismo de transferência confiável de bytes entre os pontos de extremidade da rede, a grade de serviço abstrai o mecanismo de transferência confiável de solicitações entre serviços. Como o TCP, a malha de serviço não se importa com a carga útil real ou sua codificação, mas é responsável apenas por concluir a transmissão do serviço A para o serviço B e alcançar esse objetivo ao lidar com quaisquer falhas. No entanto, diferentemente do TCP, a malha de serviço não apenas tem a capacidade de "fazê-lo funcionar", mas também fornece um ponto de controle unificado para a introdução de visibilidade e controle no tempo de execução do aplicativo. O objetivo claro da grade de serviço é mover as comunicações de serviço da área de infraestrutura invisível e transformá-las em uma parte do ecossistema onde elas podem ser monitoradas, gerenciadas e controladas.

Em aplicativos nativos da nuvem, garantir a confiabilidade completa das solicitações não é fácil. A rede de serviço gerencia essa complexidade por meio de uma variedade de tecnologias poderosas e suporta mecanismos como fusível, balanceamento de carga com reconhecimento de atraso, descoberta de serviço eventualmente consistente, nova tentativa e tempo limite para garantir a confiabilidade o máximo possível. Todas essas funções devem trabalhar juntas, e a interação com o ambiente complexo em que operam também é muito importante.

Por exemplo, quando uma solicitação é enviada para um serviço por meio de uma grade de serviços, o processo de interação pode ser simplificado aproximadamente para as seguintes etapas:

• O componente de malha de serviço determina o serviço que o solicitante deseja aplicando regras de roteamento dinâmico. As solicitações devem ser roteadas para os serviços de produção ou pré-lançamento? Ele é roteado para um data center local ou um serviço na nuvem? Requer escala de cinza para a versão mais recente do serviço que está sendo testada ou ainda é roteado para uma versão mais antiga que foi verificada na produção? Todas essas regras de roteamento são configuráveis ​​dinamicamente e podem ser aplicadas globalmente ou a qualquer segmento de tráfego;
• Depois de encontrar o destino correto, o componente de malha de serviço recupera o conjunto de instâncias correspondente do ponto de extremidade de descoberta de serviço relevante, que pode ter várias instâncias. Se essas informações forem diferentes das informações observadas pelo componente da grade de serviço na prática, ele decidirá em quais fontes de informação confiar;
• O componente de malha de serviço seleciona a instância com maior probabilidade de retornar uma resposta rápida com base em vários fatores, incluindo os dados de atraso observados da última solicitação;
• O componente de malha de serviço tenta enviar a solicitação para a instância selecionada e registra o atraso e o tipo de resposta;
• Se a instância tiver sido desativada por vários motivos, ou a solicitação não responder de todo, ou a solicitação não puder ser processada por qualquer outra razão, o componente da malha de serviço tentará novamente a solicitação em outra instância, conforme necessário, desde que saiba que a solicitação está Idempotente
• Se a instância sempre retornar um erro, o componente de malha de serviço o removerá do pool de balanceamento de carga, para que possa tentar periodicamente novamente mais tarde. Essa situação é muito comum em aplicativos distribuídos da Internet e é muito provável que instâncias em redes públicas causem falhas instantâneas devido a alguns motivos;
• Se o tempo limite da solicitação tiver passado, o componente de malha de serviço falhará proativamente na solicitação em vez de adicionar carga através de novas tentativas para evitar uma avalanche. Isso é muito importante para a aplicação distribuída da Internet; caso contrário, uma pequena falha provavelmente causará um desastre de avalanche;
• Ao mesmo tempo, o componente de malha de serviço captura todos os aspectos do comportamento acima na forma de métricas e rastreamento distribuído e envia esses dados para um sistema de métricas centralizado ou sistema de rastreamento de link.

Vale ressaltar que essas funções devem fornecer flexibilidade ponto a ponto e flexibilidade em todo o aplicativo para aplicativos distribuídos. Os sistemas distribuídos em larga escala (independentemente de como são construídos) têm uma característica clara: qualquer pequena falha localizada pode ser atualizada para uma falha catastrófica em todo o sistema. A malha de serviço deve ser projetada para impedir que essas falhas aumentem, reduzindo a carga e falhando rapidamente quando o sistema subjacente se aproxima de seus limites.

Por que a malha de serviço é necessária

A malha de serviço em si não é uma nova função, mas mais como uma alteração no local da função. Os aplicativos da Web sempre devem gerenciar a complexidade da comunicação de serviço. Nos últimos quinze anos, a origem do modelo de malha de serviço pode ser rastreada até a evolução desses aplicativos.

No início deste século, a arquitetura típica de aplicativos da Web de tamanho médio é geralmente uma arquitetura de aplicativos de três camadas, dividida em uma camada lógica de aplicativo, uma camada lógica de serviço da Web e uma camada lógica de armazenamento, que são camadas separadas. Embora a comunicação entre as camadas seja complicada, o escopo é limitado. No momento, a arquitetura do aplicativo não possui uma grade, mas existe uma lógica de comunicação entre a lógica de processamento de código de cada camada.

Quando a rede se desenvolveu em uma escala muito alta, essa abordagem arquitetônica começou a se esticar. Em particular, algumas grandes empresas de Internet estão enfrentando enormes demandas de tráfego e descobriram o antecessor de um método nativo da nuvem eficaz: a camada de aplicativos é dividida em muitos serviços, agora conhecidos como "microsserviços", e as camadas formam uma topologia Método de comunicação. Nesses sistemas, geralmente na forma de uma biblioteca "fat client", que é a biblioteca OSS semelhante à Netflix descrita anteriormente, a capacidade de fusível do Hystrix é um bom exemplo. Embora essas bases de código estejam relacionadas a um ambiente específico e exijam o uso de linguagens e estruturas específicas, elas são usadas para gerenciar a forma e os recursos de comunicação entre serviços, o que foi uma boa escolha nas circunstâncias da época e também em muitas empresas Seja usado.

Depois de entrar na era nativa da nuvem, o modelo nativo da nuvem possui dois fatores importantes:

• Os contêineres (como o Docker) fornecem isolamento de recursos e gerenciamento de dependência;
• A camada de orquestração (como o Kubernetes) abstrai o hardware subjacente como um pool de recursos homogêneo.

Embora esses componentes da base de código permitam que o aplicativo tenha uma certa capacidade de expansão de carga e lide com algumas das falhas que sempre existem no ambiente em nuvem, com o aumento de centenas de serviços ou milhares de instâncias, existem Na camada do processo de negócios das instâncias de agendamento, o caminho seguido por uma única solicitação através da topologia de serviço pode ser muito complexo. Ao mesmo tempo, com a popularização da tecnologia de contêineres, e o contêiner facilita a gravação e a execução de cada serviço em outro idioma, o método da biblioteca fica esticado nesse momento.

Essa complexidade e demandas críticas fazem com que os aplicativos precisem cada vez mais de uma camada dedicada à comunicação entre serviços, que é separada do código do aplicativo e pode capturar a alta resiliência dinâmica do ambiente subjacente. Essa camada é a malha de serviço que precisamos.

Os agentes de serviço podem nos ajudar a adicionar funções importantes à arquitetura de serviço do ambiente em nuvem. Cada aplicativo pode ter seus próprios requisitos ou configuração para entender como o agente se comporta de acordo com seu destino de carga de trabalho. Com mais e mais aplicativos e serviços, pode ser muito difícil configurar e gerenciar um grande número de agentes. Além disso, o uso desses agentes em cada instância do aplicativo pode oferecer oportunidades para criar funções avançadas avançadas, caso contrário, teremos que executar essas funções no próprio aplicativo.

O agente de serviço forma um plano de dados em malha, através do qual o tráfego entre todos os serviços é processado e observado. O plano de dados é responsável por estabelecer, proteger e controlar o fluxo através da grade. O componente de gerenciamento responsável por como o plano de dados é executado é chamado de plano de controle. O plano de controle é o cérebro da grade e fornece APIs públicas para que os usuários manipulem o comportamento da rede.

Grade de serviço Istio

O Istio é uma plataforma aberta para conexão / gerenciamento e microsserviços seguros, que fornece uma maneira simples de criar uma grade de microsserviços e fornece recursos de balanceamento de carga, autenticação entre serviços e monitoramento. As funções acima podem ser realizadas sem modificar muitos serviços. O Istio é um projeto de código aberto que fornece uma maneira consistente de conectar, fortalecer, gerenciar e monitorar microsserviços, originalmente uma implementação de código aberto de uma rede de serviços criada pelo Google, IBM e Lyft. O Istio pode ajudá-lo a adicionar flexibilidade e observabilidade à sua arquitetura de serviço de maneira transparente. Com o Istio, os aplicativos não precisam saber que fazem parte da malha de serviço. Sempre que um aplicativo interage com o mundo exterior, o Istio manipula o tráfego de rede em nome do aplicativo. Isso significa que, se você estiver fazendo microsserviços, o Istio poderá trazer muitos benefícios.

O Istio fornece principalmente as seguintes funções:

• Gerenciamento de tráfego, controlando o tráfego e as chamadas de API entre serviços, tornando as chamadas mais confiáveis ​​e tornando a rede mais robusta sob condições adversas;
• Observabilidade, acesso a dependências entre serviços e fluxo de chamadas de serviço, fornecendo a capacidade de identificar rapidamente problemas;
• Execução de políticas, controle a estratégia de acesso ao serviço, sem alterar o próprio serviço.

A identidade e a segurança do serviço fornecem identidades verificáveis ​​para os serviços na grade e oferecem a capacidade de proteger o tráfego do serviço, para que possam circular em redes com diferentes graus de confiança.

A primeira versão disponível para produção 1.0 do Istio foi lançada oficialmente em 31 de julho de 2018 e a versão 1.1 foi lançada em março de 2019. Depois disso, a comunidade lançou 10 versões pequenas sucessivamente dentro de três meses em uma iteração rápida. No final deste livro, a comunidade lançou a versão 1.4.

O plano de dados do Istio usa proxies Envoy por padrão e funciona imediatamente para ajudá-lo a configurar seu aplicativo para implantar instâncias de proxy de serviço próximas a ele. O plano de controle do Istio consiste em componentes que fornecem aos usuários finais e à equipe de operações APIs de operações e manutenção, APIs de configuração de proxy, configurações de segurança, declarações de políticas e muito mais. Introduziremos esses componentes do plano de controle nas partes subsequentes deste livro.

O Istio foi originalmente desenvolvido para ser executado no Kubernetes, mas o código foi implementado de uma perspectiva neutra da plataforma de implantação. Isso significa que você pode tirar proveito das malhas de serviço baseadas no Istio em plataformas de implantação como Kubernetes, OpenShift, Mesos e Cloud Foundry, e até mesmo implantar ambientes do Istio em máquinas virtuais e bare metal físico. Nos próximos capítulos, mostraremos o quão poderoso o Istio é para implantações híbridas de portfólios de nuvem, incluindo datacenters privados. Neste livro, daremos prioridade à implantação no Kubernetes e apresentaremos máquinas virtuais e outros links em capítulos mais avançados.

Istio significa "zarpar" em grego, e Kubernetes pode ser traduzido como "timoneiro" ou "piloto" em grego. Portanto, desde o início, o Istio espera trabalhar bem com o Kubernetes para executar com eficiência uma arquitetura de microsserviços distribuídos e fornecer um método unificado para segurança, conexão e monitoramento de microsserviços.

Com o proxy de serviço próximo a cada instância do aplicativo, o aplicativo não precisa mais de uma biblioteca elástica específica do idioma para implementar funções como fusível, tempo limite, nova tentativa, descoberta de serviço e balanceamento de carga. Além disso, o agente de serviço também lida com coleta de métricas, rastreamento distribuído e coleta de logs.

Como o tráfego na malha de serviço flui através do proxy de serviço do Istio, o Istio possui pontos de controle em cada aplicativo para influenciar e orientar o comportamento da rede. Isso permite que as operadoras controlem o tráfego de roteamento e obtenham uma implantação refinada através da implantação de canary, lançamento escuro, rolagem hierárquica e teste A / B. Vamos explorar esses recursos nos próximos capítulos.

Função principal

O Istio fornece muitas funções importantes na rede de serviço, incluindo cinco partes: gerenciamento de tráfego, segurança, observabilidade, suporte à plataforma, integração e personalização.

1. Gerenciamento de Tráfego

Por meio de uma configuração simples de regras e roteamento de tráfego, o Istio pode controlar o tráfego e as chamadas de API entre serviços. O Istio simplifica a configuração de atributos de nível de serviço, como fusíveis, tempos limite e novas tentativas, e pode facilmente configurar tarefas importantes, como teste A / B, implantação de canários e implantação em fases com base na divisão de tráfego baseada em porcentagem.

O Istio possui uma função de recuperação de falhas pronta para uso, você pode encontrar o problema antes que ele ocorra e otimizar a chamada entre serviços para ser mais confiável.

2. Segurança

O Istio possui poderosos recursos de segurança que permitem que os desenvolvedores se concentrem na segurança no nível do aplicativo. O Istio fornece o canal de comunicação seguro subjacente e gerencia a autenticação, autorização e criptografia das comunicações de serviço em larga escala. Com o Istio, a comunicação de serviço é segura por padrão, permitindo que as políticas sejam implementadas de maneira consistente em vários protocolos e tempos de execução, e o principal é que tudo isso exija pouca ou nenhuma alteração no aplicativo.

Embora o Istio não tenha nada a ver com a plataforma, quando é usado com a estratégia de rede Kubernetes, suas vantagens são maiores, incluindo a capacidade de proteger a comunicação pod-a-pod ou serviço a serviço nas camadas de rede e de aplicativos. Os capítulos subsequentes descreverão como combinar estratégias de rede e Istio em Kubernetes para proteger serviços em conjunto.

3. Observabilidade

O Istio possui recursos avançados de rastreamento, monitoramento e registro que podem fornecer uma compreensão aprofundada das implantações da grade de serviço. Através da função de monitoramento do Istio, você pode realmente entender como o desempenho do serviço afeta as funções upstream e downstream, e seu painel personalizado pode fornecer visibilidade do desempenho de todos os serviços e permitir que você entenda como esse desempenho afeta outros processos.

O componente Mixer do Istio é responsável pelo controle de políticas e coleta de telemetria, fornece abstração e intermediário de back-end, isola o restante do Istio dos detalhes de implementação de cada infraestrutura de back-end e fornece à equipe de operações e manutenção infraestrutura de grade e de back-end Controle refinado de todas as interações entre.

Todos esses recursos permitem definir, monitorar e implementar de forma mais eficaz o SLO de destino do nível de serviço no serviço. Obviamente, o mais importante é detectar e reparar problemas de maneira rápida e eficaz.

4. Suporte de plataforma

O Istio é independente da plataforma e seu objetivo é executar em uma variedade de ambientes, incluindo nuvem cruzada, local, Kubernetes, Mesos e assim por diante. Você pode implantar o Istio no Kubernetes ou Nomad com o Consul. O Istio atualmente suporta:

• Serviços implantados no Kubernetes;
• Serviços registrados no Consul;
• Serviços em execução em várias máquinas virtuais.

5. Integração e customização

Os componentes de implementação de políticas do Istio podem ser estendidos e personalizados para integrar-se às soluções existentes, como ACL, registro, monitoramento, cotas e auditoria.

Além disso, a partir da versão 1.0, o Istio suporta a distribuição de configurações com base no MCP (Mesh Conf? Iguration Protocol, protocolo de configuração de malha). Ao usar o MCP, você pode integrar facilmente sistemas externos, por exemplo, você pode implementar o servidor MCP e integrá-lo ao Istio. O servidor MCP pode fornecer as duas funções principais a seguir:

• Conecte e monitore o sistema de registro de serviço externo para obter as informações mais recentes sobre serviços (como Eureka, ZooKeeper e outros sistemas);
• Converta informações de serviço externo no Istio
  ServiceEntry e publique-as através dos recursos do MCP.

Por que usar o Istio

No processo de transformação de um aplicativo monolítico em uma arquitetura de microsserviços distribuídos, os desenvolvedores e a equipe de operações enfrentam muitos desafios, e o Istio pode resolver esses problemas. À medida que a escala e a complexidade aumentam, as grades de serviço estão se tornando mais difíceis de entender e gerenciar Vários requisitos incluem descoberta de serviços, balanceamento de carga, recuperação de falhas, coleta e monitoramento de índices e operações e manutenção mais complexas, como testes A / B Liberação de canário, limite de corrente, controle de acesso e autenticação de ponta a ponta, etc. O Istio fornece uma solução completa para atender às diversas necessidades dos aplicativos de microsserviço, fornecendo insights comportamentais e controle de operação para toda a grade de serviços.

O Istio fornece uma maneira simples de estabelecer uma rede para serviços implantados.A rede possui funções como balanceamento de carga, autenticação entre serviços e monitoramento.Ela requer apenas algumas ou poucas alterações no código de serviço. Se você deseja que o serviço ofereça suporte ao Istio, é necessário implantar um proxy Sidecar especial em seu ambiente, usar o plano de controle do Istio para configurar e gerenciar o proxy e interceptar todas as comunicações de rede entre microsserviços.

Além disso, o Enterprise Service Bus (ESB) da arquitetura orientada a serviços (SOA) possui algumas semelhanças com a grade de serviço.Na arquitetura SOA, o ESB é transparente aos serviços de aplicativos, o que significa que o aplicativo não possui Percepção. A grade de serviço pode ter um comportamento semelhante, a grade de serviço deve ser transparente para o aplicativo, assim como o ESB, para simplificar a chamada entre serviços. Obviamente, o ESB também inclui coisas como retransmissão de protocolos interativos, conversão de mensagens ou roteamento baseado em conteúdo, e a malha de serviço não é responsável por todas as funções que o ESB executa. A grade de serviço fornece resiliência para solicitações de serviço por meio de novas tentativas, tempo limite e fusível, além de fornecer serviços como descoberta de serviços e balanceamento de carga. Conversões comerciais complexas, orquestração de processos de negócios, processos de negócios anormais e recursos de orquestração de serviços não pertencem ao escopo das soluções de grade de serviço. Comparado com o sistema centralizado do ESB, o plano de dados na grade de serviço é altamente distribuído e seus agentes e aplicativos coexistem, o que elimina o ponto único de gargalo de falha que geralmente ocorre na arquitetura do ESB.

Obviamente, também é necessário saber quais problemas a grade de serviços não resolve. Tecnologias de grade de serviços como o Istio geralmente fornecem funções poderosas de infraestrutura que podem tocar muitas áreas da arquitetura distribuída, mas certamente não conseguem resolver todos os problemas que você pode encontrar. Perguntas. A arquitetura em nuvem ideal pode separar preocupações diferentes de cada camada de implementação.

No nível mais baixo da infraestrutura, é dada mais atenção à infraestrutura e a como fornecer recursos de infraestrutura para implantação automatizada. Isso ajuda a implantar o código em várias plataformas, sejam contêineres, Kubernetes ou máquinas virtuais. O Istio não limita qual ferramenta de implantação automatizada você deve usar.

Em um nível mais alto de aplicativos de negócios, a lógica de negócios de aplicativos é um ativo diferenciado para as empresas manterem sua principal competitividade. Esses ativos de código envolvem uma única função comercial e os serviços que precisam ser chamados, em que ordem, como executar a interação desses serviços, como agregá-los e as operações a serem executadas quando ocorre uma falha. O Istio não implementa ou substitui nenhuma lógica de negócios, não realiza a orquestração de serviço, nem fornece conversão de conteúdo ou aprimoramento de cargas de negócios, nem divide ou agrega as cargas. É melhor deixar essas funções para as bibliotecas e estruturas do aplicativo.

O diagrama a seguir trata da separação de preocupações em aplicativos nativos da nuvem, em que o Istio suporta a camada de aplicativos e fica acima da camada de implantação de nível inferior.
O Istio desempenha a função de conexão entre a plataforma de implantação e o código do aplicativo. Sua função é facilitar a remoção de lógica de rede complexa do aplicativo, que pode executar o roteamento baseado em conteúdo com base em metadados externos (como cabeçalhos HTTP, etc.) que fazem parte da solicitação. O controle e o roteamento de fluxo refinado também podem ser executados com base na correspondência de serviços e nos metadados solicitados. Você também pode proteger a verificação de token de segurança de transmissão e descarregamento ou implementar cotas e políticas de uso definidas pelos operadores de serviço.

Compreender os recursos do Istio, suas semelhanças com outros sistemas e sua posição na arquitetura pode nos ajudar a cometer os mesmos erros que as tecnologias promissoras que encontramos no passado.

Nível de maturidade e suporte

A comunidade Istio propôs diferentes definições de estágios funcionais para a maturidade relativa e o nível de suporte de cada função componente: Alpha, Beta e Stable são usados ​​para descrever seus respectivos estados, conforme mostrado na Tabela 1-1.

A Tabela 1-2 é uma lista das funções existentes da versão Istio 1.4 que extraímos que atingiram os estágios funcionais Beta e Estável. Esta informação será atualizada após cada versão. Você pode consultar o site oficial para obter o status da atualização.

Obviamente, o Istio ainda possui algumas funções que ainda estão no estado Alfa, como o plug-in Istio CNI, que pode substituir o contêiner istio-init para concluir a mesma função de rede e não requer que os usuários do Istio solicitem autorização adicional ao Rub do Kubernetes; e o uso de filtros personalizados no Envoy Capacidade etc. Acredita-se que na melhoria contínua subsequente, essas funções se tornem gradualmente cada vez mais estáveis ​​e disponíveis para produção.

Sumário

Atualmente, o Istio é a implementação mais popular no campo da grade de serviços do setor, e seus recursos permitem simplificar a operação e operação de aplicativos de arquitetura de serviço nativos da nuvem em um ambiente híbrido. O Istio permite que os desenvolvedores se concentrem no uso de sua linguagem de programação favorita para criar funções de serviço, o que melhora efetivamente a produtividade do desenvolvedor e, ao mesmo tempo, desenvolvem-se livres de misturar código que resolve problemas de sistema distribuído em código comercial.

O Istio é um projeto de desenvolvimento completamente aberto, com uma comunidade vibrante, aberta e diversificada, cujo objetivo é capacitar desenvolvedores e pessoal de operações para que eles possam agilmente liberar e manter microsserviços em todos os ambientes. Tenha visibilidade completa da rede subjacente e obtenha recursos consistentes de controle e segurança. Nas partes subseqüentes deste livro, mostraremos como usar os recursos do Istio para executar microsserviços no mundo nativo da nuvem.

Este artigo foi extraído de "Istio Service Grid Analysis and Actual Combat" e publicado com permissão do editor. Este livro foi escrito pelo especialista técnico sênior da Alibaba Cloud, Wang Xining. Ele apresenta os princípios básicos do Istio e o desenvolvimento real em detalhes.Ele contém um grande número de casos selecionados e códigos de referência que podem ser baixados para iniciar rapidamente o desenvolvimento do Istio. O Gartner acredita que a grade de serviços se tornará a tecnologia padrão para todos os principais sistemas de gerenciamento de contêineres em 2020. Este livro é adequado para todos os leitores interessados ​​em microsserviços e nativos da nuvem.Recomenda-se a leitura deste livro em profundidade.

Leitura recomendada:
[1] Alibaba Cloud Service Grid ASM, série beta de ataques públicos: Compreenda rapidamente qual é o
link do artigo ASM : https://yq.aliyun.com/articles/748761
[2] Alibaba Cloud Service Grid ASM Capacidade de expansão (1): adicione o cabeçalho da solicitação HTTP através do EnvoyFilter no ASM
Link do artigo: https://yq.aliyun.com/articles/748807

"O Alibaba Cloud Native se concentra em microsserviços, sem servidor, contêineres, malha de serviço e outros campos técnicos, se concentra nas tendências de tecnologias populares nativas da nuvem, nas práticas de pouso em larga escala nativas na nuvem e é o número público que entende melhor os desenvolvedores nativos da nuvem".

Link original
Este artigo é o conteúdo original da comunidade Yunqi e não pode ser reproduzido sem permissão.