Por que o Apache APISIX é o melhor API Gateway?

Atualmente, os telefones móveis são usados para todo tipo de coisa, e diversos aplicativos estão disponíveis na AppStore, incluindo redes sociais, utilitários, jogos, estilo de vida, compras online, etc. A construção desses aplicativos é inseparável das APIs. Portanto, as empresas que fornecem serviços por meio de APIs devem escolher um gateway de API confiável para garantir a velocidade, estabilidade e segurança de seus serviços.

No panorama de gateways de API da CNCF, existem quase 20 tipos de gateways de API (sem incluir os serviços dos fornecedores de nuvem), incluindo Apache APISIX, Kong, Tyk, etc. Muitos deles se autodenominam o projeto de gateway de API de código aberto mais popular, o gateway de API de próxima geração, mas será que são?

Neste artigo, vamos analisar vários gateways de API nas dimensões de popularidade entre desenvolvedores, suas licenças de código aberto, desempenho e o ecossistema como um todo. Nesta análise, veremos como o Apache APISIX é o gateway de API de próxima geração, superando seus pares em muitos aspectos.

Engenheiros de Software Sabem Bem

Engenheiros de software são os usuários e desenvolvedores de APIs e gateways de API, portanto, a popularidade entre os engenheiros é um indicador direto da tendência. Abaixo está um gráfico comparando o número total de contribuidores no GitHub de quatro gateways de API: Apache APISIX, Kong, Tyk e Gloo.

Podemos ver no gráfico que tanto Kong quanto Tyk começaram por volta de 2015, enquanto Apache APISIX e Gloo começaram mais tarde, em 2019. Mais significativamente, também podemos ver que o mais jovem Apache APISIX tem a curva mais íngreme entre todos e acumulou mais de 320 contribuidores, superando o segundo colocado Kong por 57 pessoas, tornando-se o projeto de gateway de API com o maior número de contribuidores.

Além do número total de contribuidores, o número de contribuidores ativos mensais indica mais significância. Os contribuidores ativos mensais para Tyk têm sido apenas em torno de 5 e raramente ultrapassam 10, enquanto Kong e Gloo têm flutuado entre 10 e 20. Enquanto isso, o Apache APISIX tem contribuidores ativos mensais acima de 20 de forma estável, e quase 40 no pico, tornando-o o projeto de gateway de API mais ativo.

Por trás dos quatro projetos de gateway de API de código aberto, existem quatro empresas comerciais correspondentes. Portanto, outro indicador que faz o APISIX se destacar é a proporção do número de contribuidores ativos mensais em relação ao número de funcionários.

Em 2022, Kong e Tyk têm uma proporção de 4%, e Gloo tem uma proporção de 24%. Em contraste, o APISIX quase atingiu 100%. A razão por trás disso é que, desde o início, quando a empresa API7.ai iniciou o projeto APISIX, ela tem se esforçado continuamente na comunidade de código aberto e ganhou sua reputação entre os desenvolvedores.

Licença de Código Aberto: O Fator Mais Importante na Escolha de um Gateway de API de Código Aberto

Desde que o MongoDB mudou sua licença de código aberto para SSPL (Server Side Public License) em 2018, as empresas agora precisam abrir o código-fonte de seus próprios sistemas quando o MongoDB é usado como um serviço gerenciado. Como resultado, as empresas precisam levar em consideração a licença de código aberto de um projeto ao escolher um projeto.

Superficialmente, Apache APISIX, Kong e Gloo usam a licença Apache License Version 2.0, amigável para negócios, e Tyk usa a Mozilla Public License Version 2.0. No entanto, ao se aprofundar, Kong, Gloo e Tyk são todos apoiados por fornecedores de código aberto comercializados. Eles podem mudar sua licença a qualquer momento, assim como o MongoDB, limitando o uso gratuito por nuvens públicas ou outras empresas e forçando você a pagar para acessar as novas versões.

Ninguém sabe a probabilidade de mudanças na licença. Esse risco, no entanto, é como a espada de Dâmocles, pairando sobre os usuários.

Nessas circunstâncias, escolher um projeto de código aberto da Apache Software Foundation (ASF) ou da CNCF é a melhor escolha, porque eles não podem modificar a licença do projeto. O Apache APISIX é um desses projetos. É um projeto de nível superior da ASF, o que significa que nenhuma empresa comercial tem controle absoluto sobre o projeto Apache APISIX, todo o código pertence à ASF e a licença não será alterada. Os usuários empresariais podem usá-lo livremente sem se preocupar em receber e-mails de advogados e departamentos de conformidade.

Desempenho do Apache APISIX, Kong e Gloo

Uma pergunta frequente na comunidade: qual tem o melhor desempenho, o Gloo baseado em Envoy ou o APISIX baseado em NGINX? Embora o desempenho não seja a métrica mais crítica, é inegavelmente a métrica mais direta. A tabela abaixo mostra os resultados de benchmark do Apache APISIX e Gloo. O QPS do Apache APISIX é 4,6 vezes o do Gloo, e a latência do Apache APISIX é apenas 7% da do Gloo.

A escolha entre NGINX ou Envoy não é o principal fator da diferença de desempenho, mas a otimização subjacente que o APISIX fez em seu código-fonte. Mesmo comparado ao KONG, que também é baseado em NGINX, o APISIX tem uma grande vantagem de desempenho. O gráfico abaixo é extraído do relatório da GigaOm sobre o teste da edição empresarial do Kong e da edição empresarial do API7 (Você pode entrar em contato conosco para obter os dados completos).

A latência do Kong é dezenas ou até centenas de vezes maior que a do API7 (edição empresarial criada pelos autores do Apache APISIX).

Por que o APISIX tem uma vantagem de desempenho tão grande? Não há segredos diante do código.

Falar é Fácil, Mostre-me o Código

Agora, vamos analisar o Apache APISIX, Kong e Gloo do ponto de vista técnico. A vantagem do Apache APISIX depende principalmente da otimização e inovação do código-fonte. As vantagens dessas tecnologias não são necessariamente refletidas em um PoC (Proof of Concept) simples, mas mostradas em um ambiente de produção mais complexo.

Antes do surgimento do projeto APISIX, havia muitos gateways de API comerciais ou produtos de gateway de API de código aberto. Esses produtos armazenavam dados de API, informações de roteamento, certificados e dados de configuração em um banco de dados relacional. As vantagens de armazenar esses dados em bancos de dados relacionais são muito óbvias. Os usuários podem usar instruções SQL para realizar consultas flexíveis, e também é conveniente para os usuários realizar backups e manutenções subsequentes.

No entanto, o gateway é um middleware que lida com todo o tráfego do cliente. A exigência de disponibilidade é extremamente alta. Se o gateway de API depender de um banco de dados relacional, significa que, uma vez que o banco de dados relacional falhe (como uma queda ou perda de dados), o gateway de API também será afetado, e a disponibilidade de todo o sistema também sofrerá.

Para reduzir o dano, o APISIX estruturou sua arquitetura para evitar a possibilidade de queda e perda de dados. O APISIX usou o etcd para armazenar dados de configuração em vez de um banco de dados relacional, e as vantagens de fazer isso são as seguintes:

1. Está mais alinhado com a arquitetura nativa em nuvem
2. Representa melhor o tipo de dados necessário para o gateway de API
3. Terá maior disponibilidade
4. As alterações podem ser notificadas em nível de sub-milissegundo

Após usar o etcd para armazenar dados de configuração, os usuários só precisam monitorar as atualizações do etcd para alterações de dados. O APISIX será capaz de obter a configuração mais recente em milissegundos, alcançando um efeito em tempo real. Se estivéssemos fazendo polling no banco de dados, no entanto, pode levar de 5 a 10 segundos para obter as informações de configuração mais recentes. Portanto, usar o etcd como esquema de armazenamento não apenas torna o APISIX mais nativo em nuvem, mas também com maior disponibilidade.

Algoritmo de Correspondência de Rotas de Alto Desempenho

Para processar uma solicitação, o Gateway de API precisa corresponder a expressão de destino com as informações de host, URI, métodos HTTP e outras informações de cada solicitação. Assim, um algoritmo de correspondência eficiente é crucial. O algoritmo baseado em hash tem bom desempenho, mas não pode realizar correspondência difusa. Expressões regulares podem realizar correspondência difusa, mas o desempenho não é tão bom. A solução do Apache APISIX é usar uma árvore, uma estrutura de dados de busca eficiente que suporta correspondência difusa. Para ser mais preciso, o Apache APISIX usa uma árvore radix (árvore de prefixo comprimido), uma estrutura de dados que comprime apenas nós intermediários com um filho. Entre todos os produtos de gateway de API conhecidos, o Apache APISIX é o primeiro a aplicar a árvore radix na correspondência de rotas e suporta o cenário em que um prefixo pode corresponder a várias rotas. Para detalhes de implementação, consulte lua-resty-radixtree.

Ao corresponder uma solicitação, o algoritmo com a árvore radix a corresponderá progressivamente, com uma complexidade O(K) (K é o comprimento do URI na rota, e é independente do número de APIs). Este algoritmo se adapta muito bem em cenários onde há um grande número de rotas, como em nuvens públicas ou CDNs. Ele também não tem problemas para lidar com um grande número de rotas que aumentam rapidamente.

Algoritmo de Correspondência de IP de Alto Desempenho

Um endereço IP tem duas notações: notação padrão de IP e notação CIDR, tomando o IPv4 de 32 bits como exemplo:

• Notação padrão de IP: 192.168.1.1
• Notação CIDR: 192.168.1.1/8

A correspondência de IP e a correspondência de rotas do Apache APISIX usam algoritmos diferentes. Tomando o IP 192.168.1.1 como exemplo, como o intervalo de cada segmento de IP é de 0 a 255, podemos pensar que o endereço IP é composto por quatro números inteiros de 16 bits, e o comprimento do IP é fixo. Assim, podemos usar um algoritmo mais eficiente para completar a correspondência.

Suponha que haja uma biblioteca de IP contendo 500 registros IPv4, o APISIX armazenará em cache os 500 registros IPv4 na tabela hash e usará a tabela hash para correspondência de IP. A complexidade de tempo é O(1). Outros gateways de API completam a correspondência de IP por meio de iteração de lista, e cada solicitação enviada ao gateway pode ser iterada até 500 vezes. Portanto, o algoritmo de correspondência de IP de alta precisão do APISIX melhora muito a eficiência de cenários que exigem correspondência massiva de listas de permissões e negações de IP (como WAF).

Refinamento de Rotas

Os Gateways de API correspondem as regras pré-definidas com várias informações das solicitações, como informações de host, URI, parâmetros de consulta URI, parâmetros de caminho URI, métodos HTTP, cabeçalhos de solicitação, etc. Essas informações são suportadas pela maioria dos gateways de API. No entanto, o Apache APISIX suporta mais dados além desses para resolver casos mais complexos.

Primeiro, o Apache APISIX suporta variáveis internas do NGINX, o que significa que podemos usar dezenas de variáveis internas do NGINX como parâmetros de correspondência, incluindo uri, server_name, server_addr, request_uri, remote_port, remote_addr, query_string, host, hostname, arg_name.

Para uma lista de variáveis internas do NGINX, consulte Variáveis do NGINX.

Segundo, o Apache APISIX suporta expressões condicionais como regras de correspondência, e sua estrutura é [var, operador, val], ...]], onde:

• var pode ser variáveis internas do NGINX.
• operador suporta igual, maior que, menor que, expressões regulares, contém, etc.

Supondo que a expressão seja ["arg_name", "==", "json"], significa se há um valor de parâmetro name igual a json nos parâmetros de consulta URI da solicitação atual. O Apache APISIX implementa esse recurso por meio de sua biblioteca lua-resty-expr. Para detalhes, consulte lua-resty-expr. Esse recurso dá ao usuário muita flexibilidade e é altamente extensível.

Além disso, o Apache APISIX permite que os usuários configurem o ttl (tempo de vida) das rotas.

$ curl http://127.0.0.1:9080/apisix/admin/routes/2?ttl=60 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/aa/index.html",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "39.97.63.215:80": 1
        }
    }
}'

O código acima significa que o APISIX excluirá automaticamente a configuração de rota após 60 segundos, o que será necessário para alguns cenários de verificação temporária, como lançamento canário. Também é muito conveniente para divisão de tráfego online, um recurso que outros produtos de gateway não possuem.

Por fim, o Apache APISIX suporta funções de filtro personalizadas, onde é possível escrever funções Lua personalizadas no parâmetro filter_func, por exemplo:

$ curl http://127.0.0.1:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '
{
    "uri": "/index.html",
    "hosts": ["foo.com", "*.bar.com"],
    "filter_func": "function(vars)
                    return vars['host'] == 'api7.ai'
                end",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

O parâmetro de entrada de filter_func é vars, e as variáveis do NGINX podem ser obtidas de vars, e então a lógica de filtragem pode ser personalizada.

Suporte a Plugins Multilíngue

Os usuários frequentemente precisam personalizar alguns dos desenvolvimentos e integrações de sistema do gateway de API para cenários específicos.

O APISIX atualmente suporta mais de 80 plugins, mas ainda é difícil cobrir todos os cenários do usuário. Assim, a maioria das empresas desenvolve plugins personalizados para negócios específicos, integra mais protocolos e sistemas por meio do gateway e alcança gerenciamento unificado na camada do gateway.

Nas versões anteriores do APISIX, os desenvolvedores só podiam usar Lua para desenvolver plugins. Embora os plugins desenvolvidos em linguagens de computação nativa tenham desempenho muito alto, aprender Lua, uma nova linguagem de desenvolvimento, requer tempo e custos de aprendizado.

Em resposta a essa situação, o APISIX fornece duas soluções.

A primeira solução é suportar mais linguagens de programação principais (como Java, Python, Go, etc.) por meio do Plugin Runner. Usando o Plugin Runner, os engenheiros de back-end podem se comunicar por meio de RPC local para desenvolver plugins do APISIX usando as linguagens de programação com as quais estão familiarizados. A vantagem disso é reduzir os custos de desenvolvimento e melhorar a eficiência de desenvolvimento. A desvantagem será a perda de desempenho. Então, existe uma maneira de alcançar o desempenho quase nativo do Lua usando linguagens de alto nível que os desenvolvedores conhecem?

A segunda solução é usar Wasm para desenvolver plugins, como mostrado na parte esquerda da figura acima. Wasm (WebAssembly) foi inicialmente usado como uma nova tecnologia que roda em navegadores, mas agora também está gradualmente mostrando suas vantagens no lado do servidor. Nós incorporamos o Wasm ao APISIX, e os usuários podem usar o Wasm para compilar bytecode Wasm para rodar no APISIX. Para usar o Wasm, desenvolvemos um plugin Wasm onde os usuários podem desenvolver plugins do APISIX quase nativos usando linguagens de programação de alto nível.

Como resultado, os usuários podem usar Lua, Go, Java, Python, Node.js e Wasm para escrever plugins personalizados no APISIX. Ao facilitar o desenvolvimento, abre portas para o desenvolvimento de plugins do APISIX.

Conclusão

Neste artigo, analisamos e comparamos produtos de gateway de API de várias perspectivas, como engenheiros de software, protocolos de código aberto, avaliação de desempenho, tecnologia e ecossistema. Podemos ver que o Apache APISIX é superior em muitos aspectos, um pioneiro na rede de API.

O Apache APISIX não é apenas um gateway de API que pode lidar com tráfego norte-sul, mas também possui produtos de código aberto como o APISIX Ingress Controller e Service Mesh.

Ele também fornece produtos empresariais e SaaS baseados no APISIX.

Experimente os produtos Apache APISIX e API7 Enterprise hoje!