Por que a Beike, a popular plataforma de habitação, escolhe o Apache APISIX

Olá, eu sou Hui Wang, responsável pelo desenvolvimento do sistema de gateway de API na Ke Holdings (Beike), uma plataforma líder integrada online e offline para transações e serviços imobiliários na China. A Beike utiliza o Apache APISIX como gateway de API no sistema de produção. Como uma empresa orientada por dados, milhões de tráfegos de produção passam pelo gateway de API diariamente, e o Apache APISIX consegue fornecer desempenho estável e excepcional. Recentemente, o Apache APISIX ingressou no incubador da Apache, e gostaria de aproveitar esta oportunidade para compartilhar o motivo pelo qual escolhemos o Apache APISIX desde o início e algumas experiências ao utilizá-lo.

Kong ou Apache APISIX

Para os requisitos técnicos do gateway, em primeiro lugar, o gateway deve ter um desempenho excelente e a capacidade de suportar o acesso a um tráfego significativo. Além disso, ele também deve ser estável, com uma taxa de erro zero.

O princípio de seleção do fornecedor é reconstruir uma versão mais estável com base ou aprendendo com outros projetos de código aberto para acessar um tráfego ainda maior. Após avaliar os prós e contras, discuti essa ideia com meu supervisor e decidimos iniciar o projeto. A primeira escolha que veio à minha mente foi o Kong, outro gateway de código aberto famoso.

Depois de navegar pelo site oficial do Kong e ler alguns artigos relacionados, pensei que o Kong era uma opção adequada, pois poderia atender à maioria das necessidades dos usuários, e o desempenho também era muito estável. Imediatamente, clonei o código e comecei a lê-lo. No entanto, mesmo após vários dias de investigação, senti-me bastante confuso. Acho que descobri o motivo pelo qual o Kong tem uma base de código tão grande: ele precisa fornecer uma infinidade de funcionalidades.

De repente, várias perguntas surgiram em minha mente. Quanto tempo levaria para entender completamente o Kong? Quanto tempo levaria para construir um projeto que atendesse a todos os requisitos? Preciso de todas essas funcionalidades que o Kong oferece?

Alguns dias antes, a versão 0.5 do gateway de API Apache APISIX foi lançada. Com uma atitude de aprendizado, rapidamente olhei para este projeto de código aberto e, surpreendentemente, descobri que ele foi desenvolvido por Yuansheng Wang e Ming Wen, dois especialistas na área de API. Eu não poderia recusar este produto com base no endosso desses especialistas.

Como o projeto de código aberto nasceu há pouco tempo, as funcionalidades suportadas pelo Apache APISIX também são bastante limitadas. No entanto, todas as funções essenciais, como balanceamento de carga dinâmico, disjuntor, autenticação de identidade e limitação de taxa, já foram implementadas. Enquanto isso, uma base de código relativamente pequena também reduz o custo de aprendizado. Comparado ao Kong, posso anunciar a vitória do Apache APISIX. O Apache APISIX é mais adequado para minha situação atual, pois pode atender ao meu plano inicial de recursos sem preocupações com funcionalidades desnecessárias.

No entanto, o problema mais crítico é que o desempenho do Apache APISIX pode ser uma desvantagem devido ao seu tempo limitado de código aberto. Comparando os resultados de testes de estresse com o Kong no mesmo ambiente de teste, o Apache APISIX acabou superando o Kong. No entanto, não é justo para o Kong, pois ele é muito mais pesado e complexo. Por outro lado, não há diferença no meu caso de uso, pois todas as funcionalidades necessárias são fornecidas no Apache APISIX. De acordo com o relatório de teste de desempenho do Apache APISIX, uma CPU de núcleo único pode atingir 24k QPS, enquanto a latência é de apenas 0,7 milissegundos.

Em resumo, escolhi o Apache APISIX pelos seguintes motivos:

• Na premissa de que ele pode atender a todas as necessidades do projeto, o custo de aprendizado do Apache APISIX é baixo
• O Kong tem uma base de código grande, o que torna difícil a manutenção do código
• Os autores do Apache APISIX são mais ativos na comunidade OpenResty, o que pode fornecer uma qualidade de código melhor
• O mais importante é resolver rapidamente qualquer dúvida comunicando-se diretamente com os autores

Os motivos fornecidos pelo site oficial do APISIX são mostrados na figura a seguir:

Quais capacidades o Apache APISIX pode fornecer

• Atualizações e Plugins Quentes
• Balanceamento de carga dinâmico
• Verificação de saúde ativa e passiva
• Disjuntor
• Autenticação
• Limitador de taxa
• Conversão de protocolo gRPC
• Broker dinâmico TCP/UDP, gRPC, WebSocket, MQTT
• Painel de controle
• Lista de Proibidos e Permitidos
• Serverless

O Apache APISIX foi lançado em quase dez versões, suportando muito mais funcionalidades do que as listadas aqui. O diagrama de arquitetura foi desenhado de acordo com a situação do negócio, conforme a seguir:

A história de como integramos o APISIX

Após alguns dias de leitura do código, tenho um entendimento básico do Apache APISIX, mas uma pergunta surgiu: eu nunca desenvolvi nenhum projeto de código aberto. Como poderia realizá-lo? Criei três branches diferentes localmente, um branch do Apache APISIX apontando para o repositório de código aberto upstream, outro branch dev usado para iteração regular de negócios e o último branch main usado para atualizações online.

Após duas semanas de trabalho duro, meu projeto finalmente tem algumas estruturas fundamentais. É hora de examinar o resultado; foi assim que começamos a fase de teste de estresse. O serviço é implantado no Tencent Cloud com servidores de 8 núcleos e 32 GB de memória, e o upstream é um ambiente de produção regular em nuvem, então não pode ser testado com muita força. O relatório de desempenho é o seguinte:

Resumo do relatório de desempenho: O tempo de consumo da interface foi reduzido em 47%, nenhum erro foi levantado e a estabilidade foi melhorada. O valor de pico de TPS aumentou em 82%, nenhum erro foi levantado e a estabilidade foi melhorada.

O ambiente de desenvolvimento está pronto e começamos a estudar a implantação em nuvem. O Apache APISIX suporta muitos métodos de instalação: Docker, Pacote RPM, Luarocks e códigos-fonte. A má notícia é que nada pode ser instalado no ambiente de nuvem, e o código-fonte só pode ser colocado em um caminho de rota fixo. Portanto, muitas funcionalidades do Apache APISIX não seriam suportadas, pois são desenvolvidas com base no OpenResty 1.15.8. O que eu poderia fazer? Arquivos compilados são gerados no repositório de código, ele tem que ser compilado em algum diretório especificado, e você não pode usar a ligação estática do PCRE, o que nos custou 1-2 dias. Por fim, ajustamos o lançamento gradual; o tráfego aumentou de 2% para o volume total em algumas semanas. Felizmente, tudo foi bem-sucedido no final.

Após várias semanas de monitoramento, o serviço online está relativamente estável. Muitas funcionalidades do Apache APISIX 0.5 precisam ser implementadas por meio de chamadas de interface API. Os parâmetros de solicitação são propensos a erros de sintaxe, e não há uma página intuitiva e conveniente. Além disso, nosso cenário de negócios precisa ter a funcionalidade de sondagem de serviços upstream. É uma coincidência que a versão 0.7 do Apache APISIX acabou de ser lançada, e a versão 0.7 suporta console e exploração de serviços upstream, o que é exatamente o que precisamos agora. Que ótima notícia! Temos que atualizar!

O branch do Apache APISIX é fácil de atualizar para 0.7, mas como poderíamos mesclar o código? As mudanças de código entre essas duas versões são enormes. Tento mesclá-las primeiro, mas há muitos conflitos, e estamos em um ritmo tão perigoso. O método padrão de resolução de conflitos é irrealista, o que poderia causar muitos bugs ocultos. Existe alguma solução eficiente? Pesquisei online e encontrei os métodos abreviados: git checkout –ours e git checkout –theirs (por favor, pesquise se você não os usou), e completei a atualização do APISIX 0.5 para 0.7 em alguns minutos. Claro, também devo agradecer à robustez do código do APISIX, que me permitiu apenas adicionar plugins de negócios sem qualquer acoplamento.

Como a versão 0.7 do Apache APISIX fornece um console, não há mais necessidade de digitar JSON. Rapidamente examinei a verificação de saúde, e não houve problema inicialmente, e pude perceber o status do serviço upstream. No entanto, ao verificar os logs do serviço upstream, descobri que após várias reinicializações, a frequência da verificação de saúde continuava aumentando. Acho que pode haver um bug na verificação de saúde. Após ler o código-fonte, descobri que o verificador para cada roteador não é globalmente único. Em vez disso, cada worker tem um verificador. Poderíamos resolver esse problema usando o mesmo nome para todos os workers criados. Mesmo que seja uma correção menor, um PR de hot-fix é necessário.

Atualizei o APISIX de negócios online para 0.7 e monitorei o uso de recursos do serviço. Afinal, foi uma mudança significativa de versão, e não senti nada nas primeiras horas, semelhante à última mudança de 0.5. Vou dar uma segunda olhada quando sair do trabalho. Parece que o uso de memória não está correto. A versão 0.5 tem sido relativamente estável, mas a versão 0.7 parece ter vazamentos de memória. Como o uso de memória está crescendo muito lentamente, decidi monitorá-lo por uma noite inteira. No dia seguinte, comparei os dados monitorados, determinei que havia um vazamento de memória e rapidamente reverti para a versão anterior. Após tudo ser feito, forneci feedback ao Yuan Sheng sobre esse problema. De acordo com o cenário que descrevi, encontrei o problema por meio de testes de estresse. Era um problema com a árvore radix. O mesmo problema nunca ocorreu depois que atualizei as dependências, pois Yuan Sheng lançou a nova versão da árvore radix.

Após relançar o projeto, a versão 0.7 do Apache APISIX ainda poderia me surpreender de vez em quando. A dependência de roteamento usada na versão 0.5 do Apache APISIX era o libr3, enquanto a versão 0.7 usava a árvore radix, que tem um desempenho melhor. As porcentagens de uso de CPU e memória diminuíram. No Apache APISIX 0.5, o uso de CPU é de 1-10%, e a memória é de 0,1%. No Apache APISIX 0.7, o uso de CPU foi reduzido para 1-2%, e a memória é inferior a 0,1%, o que é excelente.

Plano Futuro

O Apache APISIX foi lançado há dois meses, e não houve falhas nem erros. Este é apenas o começo, e podemos fazer muito mais no futuro para mostrar mais capacidades aos provedores de serviços. O gateway fornece um proxy reverso e ajuda algumas equipes que não têm tempo para desenvolver funções para garantir a estabilidade do serviço, incluindo serviços como limitação de taxa, disjuntor, monitoramento e plataformas de acesso.

Por fim, gostaria de agradecer a Yuan Sheng e Wen Ming por fornecerem um produto tão excelente e à comunidade Apache APISIX pelas funcionalidades iterativas contribuídas. Agora, o tráfego diário do gateway ultrapassou 100 milhões, e não há problemas de desempenho. Obrigado pelo seu tempo e atenção!