iQIYI desbloqueia inovação no API Gateway com Apache APISIX

Visão Geral

Desafios

1. O grande volume de tráfego resulta em inúmeros alertas diários de CPU IDLE muito baixa.
2. Muitos componentes dependem da arquitetura do sistema.
3. Alto custo de O&M (Operação e Manutenção).

Objetivos

1. Escolher um gateway de API de alto desempenho que atenda às necessidades da iQIYI.
2. Minimizar o custo de migração.
3. Encontrar um gateway de API com uma comunidade ativa e um ecossistema saudável.
4. Construir um novo gateway de API para se adequar à tendência de cloud-native.

Resultados

1. O desempenho melhorou 10x em relação ao anterior, suportando milhões de QPS diariamente.
2. Suportou facilmente mais de 9.000 projetos de negócios online com API.
3. Realizou com sucesso a recuperação de desastres de dados em múltiplos sites e níveis em toda a China.

O que aconteceu por trás da iQIYI?

Cong He, engenheiro sênior de P&D da iQIYI, compartilhou uma palestra no Apache APISIX Meetup em Xangai recentemente. Ele trabalha na equipe de computação em nuvem do departamento de infraestrutura IIG e é responsável pelo desenvolvimento do gateway e pelo trabalho de operações na iQIYI. Vamos mergulhar em sua palestra e na história do gateway de API da iQIYI para entender melhor o Apache APISIX.

Fundada em 22 de abril de 2010 pela Baidu, a empresa por trás do maior mecanismo de busca online da China, a iQIYI é atualmente um dos maiores sites de vídeo online do mundo, com quase 6 bilhões de horas gastas em seu serviço a cada mês e mais de 500 milhões de usuários ativos mensais.

A iQIYI costumava desenvolver seu próprio gateway de API chamado Skywalker, um desenvolvimento personalizado baseado no Kong. O Skywalker precisa lidar com um tráfego massivo atualmente, e o pico diário do serviço de gateway pode atingir um milhão de QPS e milhares de rotas de API. No entanto, as deficiências deste produto começaram a aparecer gradualmente.

1. O desempenho do gateway não atende mais às necessidades da iQIYI, e ele recebe inúmeros alertas diários de CPU IDLE muito baixa devido ao grande volume de tráfego.
2. Há muitas dependências de componentes na arquitetura do sistema.
3. O custo de O&M (Operação e Manutenção) é muito alto.

Após assumir este projeto este ano, Cong começou a investigar produtos de gateway semelhantes para resolver os problemas e dificuldades mencionados acima e finalmente encontrou o Apache APISIX.

Como o Apache APISIX supera o Kong

Antes de escolher o Apache APISIX, a iQIYI já havia começado a usar o Kong, mas o abandonou posteriormente.

Por que abandonar o Kong?

Após a prática real com o Kong, Cong demonstra por que sua equipe abandonou o Kong. Abaixo estão algumas das principais desvantagens do Kong.

1. As rotas do Kong usam consultas de travessia, que não são rápidas.
2. O banco de dados Postgres do Kong resulta em uma implantação inchada, sincronização de baixa eficiência e baixa disponibilidade.
3. O código tem alto acoplamento.

Por que escolher o APISIX?

"Comparamos o desempenho entre o Apache APISIX e o Kong durante a investigação e, surpreendentemente, descobrimos que o Apache APISIX era 10 vezes melhor que o Kong em termos de otimização de desempenho. Também comparamos o Apache APISIX com alguns outros principais produtos de gateway, e a latência de resposta do Apache APISIX é sempre mais de 50% menor que a de outros produtos. Além disso, o Apache APISIX ainda pode funcionar de forma estável mesmo que o uso da CPU atinja mais de 70%. O APISIX é realmente incrível!" disse Cong.

Tanto o Apache APISIX quanto o Kong foram desenvolvidos com base no OpenResty no nível técnico, o que traz um custo de migração relativamente baixo. Além disso, o Apache APISIX tem uma excelente adaptabilidade e pode ser facilmente implantado em muitos ambientes diferentes, incluindo plataformas de computação em nuvem.

"Enquanto isso, também descobrimos que o Apache APISIX é um projeto de código aberto altamente ativo que resolve problemas muito rapidamente. Seu framework cloud-native também está alinhado com os planos de acompanhamento de nossa empresa. Assim, escolhemos o Apache APISIX como nosso gateway de API."

Inovação na Arquitetura do Gateway de API da iQIYI após o uso do APISIX

Após escolher o excelente gateway de API, a iQIYI começou a estabelecer sua nova arquitetura de gateway de API, que é mostrada abaixo, incluindo o domínio, o gateway, as instâncias de serviço e o monitoramento de alarmes.

O DPVS é um projeto de código aberto desenvolvido com base no LVS pela iQIYI. O monitoramento de alarmes Hubble também é um desenvolvimento personalizado baseado em um projeto de código aberto, e algumas otimizações no desempenho e alta usabilidade do Consul foram feitas.

Conquista 1: Melhorou os planos de dados e controle para gerenciamento de cluster e serviço

O plano de dados é principalmente voltado para usuários frontend, e toda a arquitetura do LB ao gateway tem implantações multi-site e multi-link para recuperação de desastres, de modo que os usuários possam acessar seu data center mais próximo.

Para o plano de controle, existe uma plataforma de microsserviços para gerenciar múltiplos clusters e serviços. A plataforma de microsserviços permite que os usuários experimentem um serviço de balcão único sem a necessidade de abrir tickets, economizando uma quantidade significativa de tempo. No backend, o controlador do gateway controla principalmente a configuração de todas as APIs, como criação de API e plugins, enquanto o controlador de serviço lida com registro, cancelamento e verificação de saúde.

Conquista 2: Adicionou mais funcionalidades: controle de segurança, limitação de taxa e monitoramento

A iQIYI implementou algumas funcionalidades básicas na arquitetura de API, como limitação de taxa, autenticação, alarme, monitoramento, etc., após ajustar-se ao Apache APISIX.

A primeira parte é sobre HTTPS. Para o controle de segurança, a iQIYI não armazena nenhum certificado ou chave nos servidores do gateway, mas em um servidor remoto dedicado. No entanto, isso era difícil de realizar enquanto usava o Kong; em vez disso, a iQIYI usou o prefixo NGINX para fazer o descarregamento de HTTPS. Após migrar para o Apache APISIX, a iQIYI implementou com sucesso essa funcionalidade no Apache APISIX, o que economiza mais uma camada de transferência no link.

Em termos de limitação de taxa, além das funcionalidades básicas de limitação de taxa, limitação de taxa precisa e limitação de taxa por granularidade de usuário também foram implementadas. Para a autenticação, serviços especializados para autenticação de passaporte foram fornecidos. Além disso, a iQIYI pode acessar a nuvem de segurança WAF da empresa para filtrar a indústria subterrânea.

A funcionalidade de monitoramento de alarmes é alcançada usando o plugin embutido do Apache APISIX - Prometheus, e os dados de indicadores serão enviados diretamente para o sistema de monitoramento da empresa. O Apache APISIX também suporta a iQIYI com serviços de registro e análise de rastreamento.

Conquista 3: Estabeleceu o processo de atualização dinâmica de descoberta de serviço

Em relação à descoberta de serviço mencionada acima, ela registra principalmente serviços em clusters Consul por meio do centro de serviços e, em seguida, usa a descoberta de serviço DNS para atualizá-los dinamicamente. O QAE no gráfico é uma plataforma de microsserviços usada internamente em nossa empresa. Vamos usar um exemplo para demonstrar brevemente o processo de atualização de instâncias.

Ao atualizar as instâncias, primeiro faremos o logout dos nós correspondentes do Consul e enviaremos solicitações de atualização de cache DNS para o gateway por meio do controlador do gateway de API. Quando o cache for atualizado com sucesso, o controlador enviará de volta solicitações para a plataforma QAE para parar todos os nós de aplicativos backend associados para evitar o reencaminhamento de tráfego para quaisquer nós offline.

Conquista 4: Melhorou a capacidade de rotas direcionais

O gateway tem implantações multi-site, e um conjunto completo de links de backup multi-site foi construído antecipadamente. Além disso, Cong também sugere que os usuários tenham implantações de acesso mais próximo multi-site para seus serviços backend. Assim, os usuários poderiam criar um serviço de API na plataforma de gateway Skywalker, e o controlador implantaria rotas de API em todos os clusters de gateway DC. Enquanto isso, o CNAME padrão do domínio do serviço será roteado para um nome de domínio de gateway unificado.

O Apache APISIX poderia fornecer diretamente serviço com implantações multi-site de acesso mais próximo e capacidade de failover para recuperação de desastres e suporta resolução de rotas personalizadas definidas pelos usuários. Além disso, os usuários poderiam personalizar a configuração de resolução de rotas por meio do nome de domínio UUID se precisassem de failover, implantação blue-green e lançamento canário. Adicionalmente, o Apache APISIX também suporta o agendamento personalizado da recuperação de serviços backend.

Conquista 5: Melhorou a tolerância a desastres multi-site e multi-nível

Para lidar com situações como grande volume de tráfego, muitos clusters e um amplo público de clientes, a iQIYI requer acesso ao serviço mais próximo e recuperação de desastres no nível operacional.

Além de backups multi-site e multi-link para recuperação de desastres, a iQIYI ainda precisa considerar questões sobre situações multi-nível e multi-nó. O APISIX ajuda com isso. Quanto mais próximos os clientes estiverem dos nós mortos, maiores serão os impactos nos negócios e no tráfego.

1. Se o nó de serviço backend mais distante estiver inativo, a iQIYI poderia alcançar o corte de nó único ou failover de DC morto por meio do mecanismo de verificação de saúde do centro de serviços e do gateway. Assim, o impacto seria limitado a serviços específicos, sem afetar usuários.
2. Se o gateway estiver inativo, então a iQIYI poderia usar o mecanismo de verificação de saúde do L4 DPVS para cortar nós de gateway com falha, e o impacto é relativamente pequeno, sem afetar usuários.
3. Se as medidas de disjuntor acima não puderem reparar o nó morto, então a iQIYI poderia alcançar o failover automático no DNS por meio do teste de usabilidade multi-nó de granularidade de nome de domínio na extranet. No entanto, esse método é relativamente lento e poderia impactar muitos outros serviços, e os usuários poderiam estar cientes disso.

Plano Futuro da iQIYI

Na integração com o APISIX, a iQIYI está tentando otimizar algumas questões para se adequar melhor ao seu negócio.

1. Considerando os possíveis gargalos de alguns componentes dependentes, como etcd, monitor Prometheus e serviço de registro, a iQIYI planeja usar um método de implantação híbrida. Ou seja: compartilhar informações dentro de grandes clusters e manter pequenos clusters independentes. Por exemplo, os serviços vitais serão implantados com os pequenos clusters.

2. Mais redução e otimização correspondentes para métricas de monitoramento Prometheus serão realizadas, especialmente para descoberta de serviço DNS.

Cong disse: "Esperamos que o Apache APISIX possa suportar mais funcionalidades e manter uma excelente eficiência de desempenho, bem como estabilidade em desenvolvimentos e atualizações futuras."

Procurando suporte para o APISIX?

Você quer acelerar seu desenvolvimento com confiança como a iQIYI? Para maximizar o suporte ao APISIX, você precisa da API7. Fornecemos suporte aprofundado para o APISIX e soluções de gerenciamento de API com base em suas necessidades!

Entre em contato conosco quando quiser: https://api7.ai/contact.