Apache APISIX unifica o gerenciamento de tráfego completo com Service Mesh

Com o rápido crescimento do Cloud Native, o Service Mesh também está começando a ganhar destaque. Atualmente, existem muitas soluções conhecidas de Service Mesh, e cada produto tem suas próprias vantagens. Portanto, as decisões sobre soluções de Service Mesh variam de pessoa para pessoa, dependendo do setor ou contexto de negócios.

Situação Atual e Pontos de Dificuldade do Service Mesh

O surgimento do Service Mesh está fortemente ligado à evolução atual da arquitetura de negócios. Com a tendência crescente do Cloud Native, a maioria das empresas começou a se transformar em microservices, onde percebemos que os aplicativos começaram a se tornar cada vez menores, e cada aplicativo teria algumas funcionalidades comuns. Então, começamos a pensar: "Existe uma tecnologia que pode resolver esse cenário comum?" Assim, o Sidecar surgiu.

Com o Sidecar, algumas funções como registro e descoberta de serviços, gerenciamento de tráfego, observabilidade e segurança podem ser delegadas a ele, permitindo que os serviços de negócios se concentrem no desenvolvimento da lógica de negócios.

No entanto, o surgimento do Sidecar fez com que as pessoas percebessem alguns pontos de dificuldade na prática, como:

Há tantas soluções que é difícil migrar após a escolha. Atualmente, existem inúmeras soluções de Service Mesh, e as características e capacidades variam de solução para solução. Uma vez que uma dessas soluções é escolhida, ela será usada sem substituições futuras. No entanto, se descobrirmos que a solução não atende aos novos requisitos quando o negócio se expande, os custos de migração serão enormes.
Alto custo de integração com a infraestrutura. O Service Mesh implementado na prática muitas vezes requer integração com infraestruturas, como arquiteturas de microsserviços anteriores, MQ ou componentes de infraestrutura de banco de dados. Algumas questões legadas ou dívidas técnicas históricas também podem criar resistência ao processo de integração.
Perda de desempenho e consumo adicional de recursos. Atualmente, não importa qual solução de Service Mesh você escolha, haverá alguma perda de desempenho. Além disso, devido ao Sidecar, recursos extras precisam ser alocados para ele ao configurar o negócio.
Dificuldade severa de escalabilidade. Algumas soluções de Service Mesh não são escaláveis em termos de protocolos ou funcionalidades com os métodos de configuração existentes, e não são personalizáveis por meio de plug-and-play.

Portanto, diante da situação de negócios e dos pontos de dificuldade, começamos a pensar se poderia existir uma solução ideal de Service Mesh que pudesse resolver esses problemas.

Como é o Service Mesh Ideal?

Em cenários de negócios, nossas exigências para o Service Mesh são, como mostrado acima, ou seja, há múltiplas dimensões de requisitos na direção de recursos, desempenho, gerenciamento de tráfego e escalabilidade. Claro, além disso, também haverá alguns requisitos mais detalhados em outras dimensões. Por exemplo:

Primeiro, no nível de experiência de uso, é necessário alcançar um custo mais baixo de entrada, já que pode haver mais operações de operação e manutenção para aplicar o Service Mesh do que para desenvolvedores. Portanto, o custo de entrada é um dos fatores que as pessoas consideram ao escolher uma solução.
Em segundo lugar, no nível técnico, a configuração do plano de controle deve ser fácil de iniciar. Ao mesmo tempo, as permissões relevantes devem ser estritamente e seguramente controladas, e a configuração deve ser mais próxima do nível público.
No lado dos dados, é melhor suportar nativamente múltiplos protocolos ou até mesmo protocolos personalizados, porque você precisa considerar os problemas causados pela migração de alguns sistemas legados. Devido à presença do Sidecar, também é necessário considerar que sua pegada de recursos seja gerenciável, para que os custos possam ser efetivamente controlados. A escalabilidade também é necessária para personalização.
Finalmente, dentro de todo o ecossistema do produto, tanto a comunidade quanto o reparo do produto precisam corresponder à velocidade de "resposta oportuna".

Como temos requisitos e metas tão claros, o próximo passo é implementar e construir uma solução próxima do ideal.

Solução de Service Mesh Baseada no APISIX

Apache APISIX é um gateway de API cloud-native dinâmico, em tempo real e de alto desempenho que oferece recursos ricos de gerenciamento de tráfego, como balanceamento de carga, upstream dinâmico, canary release, circuit breaking, autenticação, observabilidade e muito mais.

Centenas de empresas ao redor do mundo já aplicam o Apache APISIX para lidar com tráfego crítico de negócios, cobrindo finanças, internet, manufatura, varejo, operadoras, etc., como NASA, European Factory Platform, China Airlines, China Mobile, Tencent, Huawei, Weibo, Netease, Ke Holdings Inc., 360, Taikang, Nayuki Holdings Limited, etc. Portanto, a solução de Service Mesh baseada no APISIX terá uma forte demanda não apenas em termos de nível de uso, mas também ao enfrentar diferentes setores da indústria.

A arquitetura da atual solução de Service Mesh é baseada no Istio como plano de controle e no APISIX como plano de dados.

Primeiro, escolhemos o Istio como plano de controle, porque o Istio é a solução de Service Mesh mais popular atualmente, e tem uma comunidade ativa, o que faz com que quase todos os principais fornecedores de nuvem suportem o Istio, e também representa, em certa medida, a demanda e direção do mercado atual. Portanto, em termos de escolha do plano de controle, não houve um módulo autodesenvolvido. Em vez disso, optamos por abraçar o Istio, que é mais adequado e tem uma maior taxa de aceitação.

O plano de dados é onde o Apache APISIX pode se destacar. Como um gateway de API cloud-native, quais ações o APISIX tomou como plano de dados do Istio nesta solução de Service Mesh?

Quem conhece o APISIX sabe que o APISIX usa o etcd para armazenamento de dados. Mas se usarmos o APISIX como Sidecar, de onde vem sua configuração? Essa é a questão que precisa ser considerada. Se colocarmos o componente etcd no Sidecar também, descobriremos que o consumo de recursos é muito grande e não é flexível o suficiente.

Portanto, nesse processo, primeiro adicionamos um centro de configuração chamado xDS ao APISIX para eliminar a necessidade do etcd, e então introduzimos o Amesh, como mostrado acima, um programa Go compilado em uma biblioteca de link dinâmico que é carregada quando o APISIX é iniciado. Ele usa o protocolo xDS para interagir com o Istio. Em seguida, ele escreve a configuração obtida no centro de configuração xDS do APISIX, que gera regras de roteamento específicas e, eventualmente, usa o APISIX para rotear as solicitações correspondentes.

Após a configuração da arquitetura acima, os seguintes resultados podem ser alcançados:

Amesh e APISIX mantêm o mesmo ciclo de vida e podem ser ligados e desligados juntos.
Graças ao suporte nativo do APISIX ao xDS Discovery, os dados são convertidos entre si por meio do protocolo xDS, resultando em um nível de consumo de recursos controlado.
O CRD pode ser usado para estender rapidamente e facilmente toda a solução, especialmente para funcionalidades ainda não suportadas pelo Istio. Por exemplo, a configuração mais rica de plugins do APISIX é configurada por CRD; ao usar o controlador junto com o Istio, a escalabilidade da solução de Service Mesh do Istio e APISIX é maximizada.

Desempenho Específico da Solução

Melhoria Significativa de Desempenho

Os dados são sempre a maneira mais intuitiva e eficaz de apresentar um produto tecnológico. Usamos o APISIX e o Envoy como plano de dados na solução de Service Mesh, usamos o volume de até 5.000 rotas para realizar testes de estresse em vários cenários e, finalmente, apresentamos a seguinte comparação de dados.

O cenário de teste é "Corresponder a 3000ª rota de 5000 rotas". Devido ao grande número de cenários de teste, apenas as rotas correspondentes à parte intermediária são descritas abaixo, e também há cenários correspondentes às rotas iniciais e finais. (Há muitos dados para mostrar, então os dados a seguir são o resultado do teste com o volume de 3000 rotas).

Como você pode ver pelos dados acima, o APISIX mostra uma melhoria de desempenho de 5x no nível de QPS para a mesma pressão e a mesma configuração de máquina. Além disso, no nível de latência de solicitação, o APISIX é menor que o Envoy por ordem de magnitude, com a latência do APISIX na faixa de microssegundos e a do Envoy na faixa de milissegundos. Claro, você também pode ver que, nesta medição, o consumo de CPU do APISIX é de apenas 50% quando o CPU do Envoy já está funcionando em capacidade total.

Redução do Uso de Recursos

Ao injetar o Sidecar na solução de Service Mesh, geralmente há um consumo adicional de recursos. A solução baseada em API pode reduzir o consumo de recursos em 60%. Por que isso é possível?

Primeiro, a configuração é distribuída sob demanda. O Istio vem com algumas políticas sob demanda para o gerenciamento de recursos do Sidecar, como segregação por namespace, mas esse processo impõe um fardo mental adicional e dificuldades de gerenciamento nas operações do usuário.

Em segundo lugar, se a configuração é fácil de entender. Quando você configura uma rota no Envoy, as informações de roteamento, quando verificadas via Dump, mostram que já existem milhares no Envoy, enquanto na realidade não há tantas, o que tem muitas implicações, como afetar a velocidade de inicialização e causar algumas configurações volumosas, aumentando assim o uso de recursos.

Com o APISIX, você pode evitar todos esses problemas. A configuração do APISIX é direta e clara, reduzindo os dados armazenados na memória e, combinados com seu alto desempenho, reduzindo o consumo de recursos da CPU. O consumo de recursos de toda a solução é reduzido em cerca de 60%.

Baixo Custo de Aprendizado e Alta Capacidade de Personalização

Primeiro, como um projeto de código aberto ativo da Apache Software Foundation, o APISIX fornece uma riqueza de documentação e recursos de aprendizado na comunidade, o que reduz o custo de aprendizado para quem deseja começar com o APISIX.

Em segundo lugar, o código-fonte do APISIX é baseado em Lua, que é relativamente fácil de ler e entender, pois é uma linguagem de script leve, então é mais claro visualizar o código-fonte do APISIX.

Finalmente, o desenvolvimento secundário baseado no APISIX é muito fácil. Quando você deseja personalizar plugins para o seu negócio, não apenas a linguagem Lua nativa é suportada, mas você também pode usar o Plugin Runner do APISIX para implementar desenvolvimento secundário em linguagens mais familiares como Python, Java, Go e até mesmo Wasm.

O poder ecológico do APISIX também se deve à forte extensibilidade do produto.

O APISIX em si oferece uma ampla gama de plugins para segurança, registro, observabilidade e muito mais. Esses plugins podem ser usados ao máximo quando o APISIX é usado como um componente de gateway tradicional. No entanto, quando o APISIX é usado em conjunto com o Istio no plano de controle para criar um service mesh, muitos recursos não são definidos no plano de controle do Istio. Então, o que pode ser feito nesse caso?

É aí que entram os CRDs personalizados. Por exemplo, se quisermos fazer um plugin de injeção de falhas, esse plugin já está disponível no APISIX, então só precisamos configurar alguns parâmetros adicionais aqui. Claro, aqui é apenas um exemplo do plugin de injeção de falhas. Há também plugins de autenticação de identidade segura, limitação de taxa e outros plugins comuns no APISIX que podem ser acessados dessa forma para alcançar um controle refinado.

O benefício mais imediato de usar CRDs dessa forma é que torna a extensão mais nativa, usando configuração declarativa para facilitar a aceitação pelos usuários, ao mesmo tempo em que não invade a configuração original do Istio para uma compatibilidade perfeita. Outro benefício é que os custos de migração são menores para usuários que já usam soluções do Istio.

Em resumo, a solução de Service Mesh baseada no APISIX é mais fácil de usar e expansível para desenvolvedores ou usuários e tem excelente desempenho e rico suporte ecológico. Graças à capacidade do produto APISIX, ele também tem um bom suporte no nível de plugins e multi-protocolos. Esperamos trazer a próxima versão do Service Mesh baseado no APISIX no final do ano. Aguardem!

Perspectivas Futuras para a Solução de Service Mesh Baseada no APISIX

Em retrospecto, a solução de Service Mesh baseada no APISIX já está trabalhando em direção aos pontos de dificuldade mencionados no artigo anterior e está caminhando para a solução ideal de Service Mesh.

Com a solução de Service Mesh baseada no APISIX, você pode ver que o tráfego entra de fora através do APISIX Ingress e é processado pelo APISIX no meio. Nesse processo, o APISIX Ingress lida com o tráfego norte-sul, e o Amesh + Istio lida com o tráfego leste-oeste.

Uma arquitetura de implantação como essa pode trazer algum valor em nível de negócios, como economia de custos e uma pilha de tecnologia unificada, onde você pode replicar rapidamente capacidades comuns que eram usadas dentro de gateways tradicionais no Service Mesh. Isso permite um gerenciamento unificado em nível de negócios, controlando custos e reutilizando altamente a experiência no gateway, Ingress e Service Mesh.

Nas iterações subsequentes, a solução de Service Mesh baseada no APISIX continuará a ser aprofundada, realizando direções planejadas como:

Construir implementações de capacidades xRPC em conjunto com a funcionalidade do APISIX.
Realizar suporte nativo a multi-protocolos heterogêneos.
Cobrir todos os tipos de cenários e configurações, incluindo o Istio, para reduzir significativamente os custos de migração do usuário.

Em conclusão, entre as tendências tecnológicas atuais, o Service Mesh certamente será uma tendência popular no futuro. Embora várias soluções ainda não sejam perfeitas, a situação geral é uma espiral ascendente. Claro, o Service Mesh baseado no APISIX também está se movendo em direção à solução ideal de Service Mesh que todos têm em mente.