Explorações Técnicas do Gateway de API Open-Source Apache APISIX

Contexto

Apache APISIX é um gateway de API open-source dinâmico, em tempo real e de alto desempenho que oferece funções avançadas de gerenciamento de tráfego, como balanceamento de carga, roteamento dinâmico, lançamento canário, circuit breaker, autenticação e observabilidade.

Como um gateway de API, o Apache APISIX pode ajudar empresas a processar tráfego de APIs e microsserviços de forma rápida e segura em cenários como gateways, Kubernetes Ingress e service mesh. Além disso, ele pode lidar com tráfego norte-sul (do cliente para o servidor) e tráfego leste-oeste (entre microsserviços dentro da empresa).

Lançado como open-source em 6 de junho de 2019, o APISIX foi doado para a Apache Software Foundation em outubro de 2019 e rapidamente se tornou um projeto de nível superior da Apache Software Foundation em poucos meses.

Por que o APISIX cresceu tão rapidamente? Que tipos de explorações técnicas mágicas o APISIX fez? Por que cada vez mais desenvolvedores e empresas estão dispostos a usar o APISIX? Vamos descobrir.

Principais Características do Apache APISIX

Livre de Dependências de Banco de Dados

Antes do surgimento do APISIX, havia muitos gateways de API comerciais ou projetos open-source. O problema potencial desses concorrentes é que a maioria desses produtos armazena seus dados de API, informações de configuração, certificados e rotas em bancos de dados relacionais.

As vantagens aparentes de armazenar em um banco de dados relacional são a facilidade de consultas flexíveis com instruções SQL e a realização de backups e manutenção.

No entanto, toda moeda tem dois lados. Como um middleware básico, o gateway de API lida com todo o tráfego do cliente, o que aumenta os requisitos de disponibilidade. Se o seu gateway de API depende de um banco de dados relacional, o gateway será afetado caso ocorra um erro no banco de dados, como uma falha ou perda de dados. Nesse caso, a limitação da disponibilidade geral do sistema é reforçada.

Portanto, os designers do APISIX tentaram evitar tais problemas desde o nível da arquitetura subjacente.

A arquitetura do APISIX é dividida principalmente em duas partes. A primeira parte, chamada de plano de dados, é o componente que lida com as solicitações e o tráfego dos clientes. Ele suporta autenticação, descarregamento de certificados, análise de logs e observabilidade. O plano de dados não armazena dados, sendo uma estrutura sem estado.

A segunda parte é chamada de plano de controle. O APISIX não usa armazenamento de configuração tradicional como MySQL, mas sim etcd no plano de controle.

As vantagens de fazer isso:

1. Mais alinhado com a arquitetura nativa em nuvem dos produtos
2. Mais adequado para os tipos de dados armazenados pelo gateway de API
3. Melhor reflete as características de alta disponibilidade
4. Notificações de mudanças em milissegundos

Ao usar etcd, o plano de dados só precisa monitorar as mudanças no etcd. Se você consultar o banco de dados, pode levar de 5 a 10 segundos para obter a configuração mais recente. No entanto, se você monitorar as mudanças de configuração no etcd, pode obter feedback em milissegundos, alcançando um efeito em tempo real.

Portanto, usar etcd em vez de um banco de dados relacional torna o APISIX mais compatível com o ambiente nativo em nuvem na camada subjacente e reforça suas vantagens de alta disponibilidade.

Plugins para Múltiplas Linguagens de Programação

Gateways de API são um pouco diferentes de bancos de dados e outros middleware. Em comparação com estes, os gateways são mais frequentemente usados em desenvolvimento personalizado e integração de sistemas.

Embora o APISIX tenha lançado muitos plugins oficiais, ainda é difícil cobrir todos os cenários de uso para diferentes usuários. Portanto, no uso real, alguns plugins personalizados precisam ser desenvolvidos para o negócio, mais ou menos. O APISIX também integra mais protocolos ou sistemas por meio do gateway e, eventualmente, alcança um gerenciamento unificado na camada do gateway.

No início, o APISIX só suportava o desenvolvimento de plugins na linguagem Lua. A vantagem é que os plugins desenvolvidos podem ter alto desempenho por meio da otimização subjacente da linguagem de programação nativa. No entanto, há uma desvantagem óbvia: aprender Lua, uma nova linguagem, requer tempo e custos de aprendizado.

Essencialmente, o APISIX resolve os problemas de duas maneiras.

A primeira maneira é suportar mais linguagens de programação principais, como Java, Python, Go, etc., por meio do Runner Plugin. Se você é um engenheiro de backend, deve conhecer pelo menos uma dessas linguagens; então, você pode facilmente utilizar o protocolo RPC e desenvolver um plugin do APISIX usando a linguagem com a qual está familiarizado.

Por um lado, é benéfico para reduzir custos de desenvolvimento e melhorar a eficiência. No entanto, por outro lado, há alguma latência no nível de desempenho. Então surge a pergunta: haveria uma solução que pudesse alcançar o desempenho nativo do Lua e, ao mesmo tempo, considerar linguagens de alto nível?

Aqui vem o segundo método, mostrado na parte esquerda da imagem acima. O WebAssembly foi inicialmente usado como uma tecnologia no front-end ou navegador e gradualmente oferece suas vantagens no lado do servidor.

Ao incorporar o WebAssembly no APISIX, os usuários podem usá-lo para compilar para bytecode WebAssembly que é executado no APISIX. O efeito final é desenvolver de forma eficiente um plugin do APISIX que seja tanto de alto desempenho quanto escrito em linguagens de programação de alto nível.

Portanto, na versão atual do APISIX, os usuários podem usar Lua, Go, Python, Wasm e outros métodos para personalizar o código com base no APISIX. O design reduz o limiar para desenvolvedores e oferece mais possibilidades para as funções do APISIX.

Recarregamento a Quente de Plugins

O APISIX tem dois avanços significativos em comparação com o NGINX: o APISIX suporta gerenciamento de cluster e recarregamento dinâmico.

Se você já usou o NGINX, sabe que todas as configurações do NGINX são escritas no arquivo de configuração nginx.conf. Para realizar o controle de cluster, você precisa modificar o arquivo nginx.conf em cada servidor. Não há um plano de controle centralizado em todo o processo. Cada NGINX é uma combinação do plano de dados e do plano de controle. O custo de gerenciamento será excepcionalmente alto se os usuários tiverem dezenas ou centenas de servidores NGINX.

No cenário mencionado acima, cada servidor NGINX precisa ser reiniciado para funcionar após a modificação do arquivo nginx.conf. Por exemplo, para atualizações de certificados ou mudanças no upstream, você precisa modificar o arquivo de configuração primeiro e reiniciar o servidor para que as mudanças entrem em vigor. Esse método é aceitável se sua solicitação não for particularmente grande. No entanto, à medida que APIs e microsserviços aparecem cada vez mais, o impacto no cliente será enorme se o servidor precisar reiniciar para cada modificação.

• Atualizações a Quente e Plugins a Quente: Atualiza continuamente suas configurações e plugins sem reinicializações!
• Proxy Rewrite: Suporta a reescrita do host, URI, esquema, método e cabeçalhos da solicitação antes de enviá-la ao upstream.
• Response Rewrite: Define o código de status, corpo e cabeçalho personalizados da resposta para o cliente.
• Balanceamento de Carga Dinâmico: Balanceamento de carga round-robin com peso.
• Balanceamento de Carga Baseado em Hash: Balanceamento de carga com hashing consistente de sessões.
• Verificações de Saúde: Habilita verificações de saúde no nó upstream e filtra automaticamente nós não saudáveis durante o balanceamento de carga para garantir a estabilidade do sistema.
• Circuit-Breaker: Rastreamento inteligente de serviços upstream não saudáveis.
• Proxy Mirror: Fornece a capacidade de espelhar solicitações do cliente.
• Divisão de Tráfego: Permite que os usuários direcionem porcentagens de tráfego incrementalmente entre vários upstreams.

A imagem acima lista os componentes onde o APISIX atualmente implementa o recarregamento a quente. Podemos ver que o código entra em vigor em tempo real, desde o upstream até o certificado e até mesmo o plugin. Alguns membros da comunidade podem entender por que o upstream e os certificados são dinâmicos, pois os dados mudam frequentemente. No entanto, eles perguntariam por que a modificação do plugin precisa ser dinâmica, já que acreditam que a modificação do plugin é infrequente, o que parece desnecessário ser altamente ativo.

Como designers subjacentes do APISIX, esperamos que ele seja totalmente dinâmico, o que traz uma vantagem significativa em aumentar mais possibilidades para as empresas. Por exemplo, os usuários podem solucionar problemas de código enquanto modificam o plugin de depuração sem alterar nenhum código do plugin. Nessas circunstâncias, o usuário pode reproduzir o problema a qualquer momento e registrá-lo sem reiniciar. O plugin com função de depuração combinado com o mecanismo de recarregamento a quente será muito flexível, ajudando os desenvolvedores a economizar tempo e esforço na solução de problemas.

Orquestração Dinâmica de Plugins

Além do recarregamento a quente, o APISIX suporta orquestração dinâmica em tempo real entre plugins. A orquestração dinâmica também traz infinitas possibilidades para a operação de plugins.

O que é orquestração de plugins? Quando apresentamos várias demandas, esperamos transformar uma solicitação em um plugin, como brincar de LEGO. Podemos construir uma infinita variedade de formas possíveis por meio de um padrão unificado, como encaixe e interseção, que é uma das alegrias do LEGO. Para os plugins do APISIX, cada plugin atende a um caso de uso independente. Não podemos parar de perguntar se é possível permitir que os usuários personalizem suas necessidades com plugins como se estivessem brincando de LEGO.

Por exemplo, se houver 100 plugins no APISIX, os usuários verão apenas as funções desses 100 plugins, em vez de sua flexibilidade subjacente. Portanto, ao desenvolver middleware, precisamos considerar o que o produto pode ser e como dotar mais possibilidades quando as pessoas os usam.

Atualmente, o APISIX tem quase 100 plugins, mas tem muito mais do que 100 possibilidades. Consequentemente, após desenvolver sua capacidade de arranjo de plugins, a combinação se torna 100 * 99 * 98 * 97 * 96 * ..., chegando perto do infinito.

Por exemplo, um código de erro geralmente ocorre após você limitar a taxa de um usuário. Você pode tentar conectar um plugin de registro ou um plugin de relatório de erros para o registro subsequente de atividades. A imagem abaixo mostra o modelo de orquestração de plugins do APISIX.

Esse recurso tem um benefício oculto: um conjunto completo de testes cobre o código de cada plugin. Quando o usuário organiza o plugin, ele não precisa escrever nenhum código. O design seria extremamente amigável para gerentes de produto, engenheiros de segurança e engenheiros de operações e manutenção que não precisam gastar longas horas em treinamento e aprendizado. Em vez disso, eles podem criar um novo plugin do APISIX soltando plugins para ajustar algumas configurações. Além disso, a qualidade do código do novo plugin é tão alta quanto o código oficial do APISIX open-source.

Gateway para Tráfego em Todas as Direções

Engenheiros de servidor que fazem algum desenvolvimento relacionado a gateways podem estar familiarizados com dois conceitos básicos: Tráfego Norte-Sul, que se refere ao tráfego de clientes, navegadores ou dispositivos IoT (Internet das Coisas) para o servidor, e Tráfego Leste-Oeste, referindo-se às chamadas mútuas entre sistemas e microsserviços dentro das empresas.

Os componentes são diferentes ao lidar com tráfego norte-sul e leste-oeste. Por exemplo, o tráfego norte-sul pode passar por um balanceador de carga, ir para o gateway de API e, em seguida, entrar em um gateway de serviço. É por isso que existem componentes como NGINX, APISIX e Spring Cloud Gateway. Ao lidar com tráfego leste-oeste com um service mesh, você pode usar componentes como Envoy, que parecem muitos, mas você pode encontrar suas semelhanças se focar em suas funções. A maioria são plugins para roteamento, upstream dinâmico e autenticação segura. Nesse caso, podemos unificar os componentes que lidam com o tráfego norte-sul e leste-oeste? A maneira ideal é que, quando uma solicitação do cliente entra no servidor, tudo seja tratado pelo APISIX. Não importa se é norte-sul ou leste-oeste, todo o tráfego e dados são controlados por meio do plano de controle. Isso é totalmente realizável com a tecnologia atual do APISIX.

Alguns de nossos usuários já confirmam que esse modo pode reduzir significativamente os custos de operação e manutenção do usuário. Ao mesmo tempo, pode reduzir a complexidade, melhorando assim a velocidade de resposta de todo o sistema. Além disso, esse feedback positivo dá uma direção mais clara para as iterações subsequentes do APISIX, permitindo que o APISIX tente mais funções e papéis no nível de gateway de tráfego total.

Suporte a Múltiplos Componentes de Descoberta de Serviços

O gateway é um componente fundamental, mas vital. Ele processa todas as solicitações do cliente e se integra a vários sistemas e projetos open-source, o que é mais importante.

Outro componente essencial - descoberta de serviços e registro - será usado na integração com outros elementos. Os usuários colocarão vários serviços em partes separadas, como Eureka e Nacos. Consequentemente, é comum que vários componentes de descoberta de serviços coexistam em sistemas de TI de grande escala e de longa duração.

Nessa situação, todo o tráfego de entrada e saída se torna um gateway. Quase todos os gateways suportam apenas uma descoberta de serviços. Você precisa especificar um componente de descoberta de serviços Nacos separado na rota A e outro componente Consul na rota B. Consequentemente, você deve implantar vários gateways para corresponder a gateways específicos a diferentes componentes de descoberta de serviços.

Atualmente, o APISIX não apenas suporta descoberta de serviços no plano de dados, mas também gradualmente suporta os componentes de registro e descoberta de serviços no plano de controle. É uma solução altamente eficiente para alguns serviços empresariais de grande escala e de longo prazo. Você pode facilmente conectar-se a vários componentes de descoberta e registro de serviços implantando apenas um gateway de API.

Exploração de Cenários de Multi-Nuvem e Nuvem Híbrida

Se os usuários implantarem o gateway em um ambiente de produção equipado com arquitetura nativa em nuvem, a multi-nuvem e a nuvem híbrida devem ser um cenário técnico de longo prazo. Por outro lado, se o APISIX for configurado com todos os recursos, desempenho, plugins e múltiplas descobertas de serviços, o problema inevitavelmente surge de como fazer os usuários funcionarem melhor em um ambiente de produção. Cenários de multi-nuvem e nuvem híbrida trazem mais desafios para o APISIX. Portanto, mais detalhes precisam ser considerados.

1. Suporte a mTLS no Upstream e Downstream

Anteriormente, não reconhecíamos que a função de suporte ao mTLS no upstream era uma prioridade alta. No entanto, uma vez em um cenário de multi-nuvem, o upstream pode ser um serviço em outra nuvem ou até mesmo se tornar outro serviço SaaS. Assim, é necessário suportar o mTLS no upstream para melhorar a segurança dos dados.

2. Separação Completa da Arquitetura do Plano de Controle e do Plano de Dados

Várias vulnerabilidades de segurança do APISIX foram expostas no ano passado, a maioria das quais vem da implantação híbrida de seus planos de controle e dados. Em outras palavras, o plano de controle e o plano de dados estão no mesmo serviço após o início do serviço APISIX. Então, uma vez que um hacker invade um plano de dados específico por meio de uma brecha de segurança, ele também pode acessar o plano de controle para controlar todos os dados, causando consequências desastrosas.

3. Fortalecimento da Gestão de Segurança

O gateway geralmente armazena alguns dados sensíveis. Por exemplo, alguns usuários podem armazenar o certificado SSL ou as informações críticas para se conectar ao etcd no gateway. Nessas circunstâncias, uma vez que o etcd ou o plano de dados seja violado, pode causar um vazamento grave de dados. Portanto, ao armazenar algumas informações essenciais, é necessário considerar o uso de um componente dedicado para armazenar chaves, como o Vault, para proteger dados sensíveis.

4. Integração com Mais Padrões de Nuvem

Pretendemos garantir que os usuários possam funcionar sem problemas em várias plataformas de nuvem sem configurar nada em cenários de multi-nuvem. Isso não significa que os usuários precisem configurar plugins personalizados, mas permite diretamente que o APISIX integre padrões, APIs ou outros serviços de várias nuvens. Esse modo pode ajudar os usuários a se adaptarem antecipadamente e garantir conveniência e conforto para o uso subsequente.

Apoiadores do Apache APISIX

Ao longo da história de desenvolvimento do APISIX, muitas inovações técnicas foram feitas. Crescentes contribuidores da comunidade trabalham lado a lado desde a fase de construção do código para transformar o APISIX em um gateway de API integrado. Hoje, o APISIX mantém uma rápida iteração, graças aos esforços dos apoiadores.

A iteração e atualização de um produto open-source devem ser atribuídas aos contribuidores e usuários.

Quando o APISIX foi doado para a Apache Software Foundation há três anos, era um projeto imaturo com apenas 20 contribuidores. Felizmente, o APISIX atraiu mais usuários, contribuidores e empresas em todo o mundo devido ao seu rápido desenvolvimento. Por exemplo, nossos clientes incluem empresas como Tencent, WPS, Sina Weibo e iQiyi, lidando com dezenas de bilhões de chamadas de API diariamente. Além disso, muitos usuários internacionais de vários setores, como NASA, European Factory Platform, Swisscom, etc., estão entre nossa lista de clientes.

Tomemos o WPS como exemplo. É uma empresa de software de escritório SaaS na China, fornecendo software como o Microsoft Office 365. Se você trabalha com várias pessoas em telefones celulares, navegadores ou dispositivos terminais, dezenas ou centenas de usuários podem editar o mesmo documento e ver as modificações simultaneamente. A função é realizada por meio de várias chamadas de API.

A maioria dos gigantes lida com dezenas de bilhões de chamadas de API, com um pico de QPS excedendo um milhão. Essa escala de uso também permite que o APISIX obtenha feedback de usuários reais em grandes circunstâncias. Graças ao apoio desses usuários empresariais, o APISIX rapidamente se desenvolveu em um projeto open-source maduro.

Além disso, muitos usuários também compartilham suas experiências ou iterações de código de uso do APISIX na comunidade, contribuindo para o benefício mútuo e uma situação de ganha-ganha para ambas as partes. Isso demonstra que os usuários veem o APISIX como um bom produto e mais como um projeto open-source valioso. Somente após ganharmos a confiança dos desenvolvedores é que temos a oportunidade de nos tornar um projeto open-source valioso.

Os contribuidores adaptam a experiência e o feedback para criar muitos recursos do produto; os usuários podem utilizar esses recursos para trazer valor para as empresas. Surge um círculo virtuoso, que é a essência do open-source. Sempre buscamos esse tipo de verdade, em vez de perseguir cegamente bolhas de numerosos seguidores.

Prévia do APISIX 3.0

Até agora, falamos muito sobre o que o APISIX fez no passado e agora. O processo de desenvolvimento do APISIX pode ser dividido em várias etapas.

O APISIX 1.0 foi para construir sua estrutura, fortalecer a arquitetura subjacente e apresentar algumas funções essenciais do gateway de API. Exploramos mais profundamente na versão 2.0, tornando a base mais flexível e a arquitetura mais madura.

Para um projeto open-source maduro, o sinal de sua maturidade não se concentra em sua grande função, mas em trazer uma melhor experiência para usuários e desenvolvedores.

No estágio atual, o APISIX fez muitas explorações e inovações técnicas, mas não considerou totalmente as experiências do usuário. O problema mostra qualidade instável da documentação e falta de vídeos tutoriais. Portanto, muitos usuários ficam perdidos quando entram em contato com o APISIX pela primeira vez. Eles não sabem como usá-lo ou aplicar certas funções a diferentes casos de uso, e não têm certeza sobre o valor único que o APISIX pode trazer para as empresas.

Portanto, na próxima versão do APISIX 3.0, tentaremos resolver problemas semelhantes e reconstruir muitas falhas que não são amigáveis à experiência do desenvolvedor. Por exemplo, redesenhamos a API para remover a dependência de valores de retorno específicos do etcd e renovamos a documentação oficial para ser mais amigável ao usuário com descrições diretas. No nível de função, o plano de controle e o plano de dados também serão separados para aumentar a segurança; ele suporta mais protocolos de camada 4 e protocolos RPC para que os usuários possam obter rapidamente tráfego de todas as direções do gateway.

Após implementar as funções acima, o APISIX 3.0 se tornará mais seguro, confiável e fácil de usar. Sempre prestamos atenção a operações excelentes e experiência do usuário. Esperamos que o APISIX possa lidar com solicitações de todas as APIs e microsserviços em todo o mundo e ajudar as empresas a gerenciar o tráfego de API e microsserviços de forma mais eficiente.

Espera-se que o APISIX lance uma nova versão, 3.0, no final de 2022. Esperamos que você continue seguindo as tendências da versão mais recente do APISIX e participe ativamente da contribuição do projeto Apache APISIX.

O Futuro do APISIX

O desenvolvimento e a substituição da tecnologia do lado do servidor são muito rápidos, pois muitas tecnologias e frameworks populares há cinco anos estão desaparecendo. A razão não é que os engenheiros prefiram coisas novas, mas que essas tecnologias não atendem às necessidades reais dos engenheiros e das empresas. Seu destino é condenado: serem eliminadas. A realidade crucial nos diz que a tecnologia deve servir aos negócios e produtos e não pode sobreviver sem corresponder às necessidades atuais do mercado.

"Não construa um castelo em um pântano." Esse ditado sempre lembra os desenvolvedores do Apache APISIX de que devem se basear em necessidades e cenários reais para orientar seu desenvolvimento e evolução. Caso contrário, o produto será gradualmente abandonado pelos engenheiros.

Como podemos manter a tecnologia do Apache APISIX na liderança do setor? Essa é a questão crucial de saber se o Apache APISIX pode continuar a atrair desenvolvedores e usuários empresariais no futuro. A resposta é simples: junte-se a empresas e engenheiros em rápido crescimento, cresça junto e apoie-se mutuamente. Isso faz com que o Apache APISIX sempre esteja na vanguarda da tecnologia. Somente assim o APISIX terá o potencial de se tornar um projeto open-source perene de classe mundial.

O futuro do APISIX é melhorar o suporte a cenários Serverless, aprimorar o service mesh, construir plataformas de ciclo de vida completo de API e melhorar a experiência do usuário na nuvem pública. Esses planos não são feitos por alguns desenvolvedores internos, mas por milhares de desenvolvedores da indústria. Então, junte-se a nós para experimentar o charme do open-source!