Como Implementar a Orquestração de Plugins no API Gateway

Assistir ao Vídeo

Primeiro, deixe-me me apresentar. Eu sou Ming Wen, co-fundador da API7.ai. Sou VP e membro do PMC do projeto de código aberto Apache APISIX. Também sou committer do Apache SkyWalking. Além disso, sou fundador do Comitê de Código Aberto da Qihoo 360, Tencent Cloud TVP e membro do TOC da TARS Foundation. Tenho mais de 40 patentes de segurança.

No tópico de hoje, vou apresentar 4 partes. Primeiro, uma breve introdução ao Apache APISIX. O que é o Apache APISIX e como ele pode nos ajudar? A segunda parte é o desenvolvimento personalizado no gateway de API, e a terceira parte é o plugin no Apache APISIX. Como podemos gerá-lo automaticamente? A última parte são algumas reflexões sobre o futuro do gateway de API.

Primeiro, deixe-me apresentar brevemente o Apache APISIX. Em uma frase, é um gateway de API nativo da nuvem. Aqui está o endereço do repositório do Apache APISIX no GitHub.

Apache APISIX é um projeto muito jovem. Foi aberto ao público em junho do ano passado e doado ao incubador da Apache em outubro. Em julho deste ano, ele se formou no incubador da Apache e se tornou um projeto de nível superior. Esta é uma comunidade de crescimento rápido, levou apenas nove meses.

Para desenvolvedores que não estão familiarizados com o Apache APISIX, você pode simplesmente pensar nele como uma versão aprimorada do NGINX, que cobre todas as funções do NGINX enquanto usa Lua. Ele traz mais recursos dinâmicos ao NGINX, transformando-o em um gateway de API muito poderoso. A maior característica do Apache APISIX é que ele é totalmente dinâmico, incluindo roteamento, certificados SSL, plugins, etc. No Apache APISIX, todos os recursos são configurados dinamicamente através da API de administração, sem a necessidade de reiniciar o serviço. No Apache APISIX, as necessidades de negócios dos usuários são todas realizadas usando Lua para desenvolver plugins. O APISIX tem mais de 40 plugins embutidos, incluindo autenticação, limitação de taxa, limitação de solicitação, segurança, log, observabilidade, etc., que basicamente cobrem todos os recursos que os usuários podem encontrar na empresa.

Então, vamos ver o que o Apache APISIX pode fazer por você? Ele pode lidar com tráfego de camada 4 e camada 7, incluindo HTTP, HTTPS, TCP, UDP, MQTT, etc.

Como o Apache APISIX é baseado no NGINX, você pode naturalmente usar o Apache APISIX em vez do NGINX para lidar com o tráfego norte-sul. Ao mesmo tempo, o Apache APISIX também pode lidar bem com o tráfego entre microsserviços, então você pode usá-lo para substituir o Envoy. Também temos alguns usuários que usam o Apache APISIX como o controlador de entrada do Kubernetes. Ao mesmo tempo, com a ajuda do plugin MQTT do Apache APISIX, podemos usar o Apache APISIX como um gateway IoT, ou usar o plugin IDP para transformar o APISIX em um gateway de confiança zero. Portanto, o APISIX está mais preocupado com o poder no próprio gateway. Através de plugins, os usuários podem transformar o APISIX em vários gateways exigidos por seus negócios.

Esta é a arquitetura técnica do Apache APISIX. A partir disso, podemos ver que o APISIX tem duas partes, a esquerda é o plano de dados, e a direita é o plano de controle.

Vamos primeiro olhar para o plano de dados. Após a solicitação do usuário ser processada pelo Apache APISIX, ela pode ser passada para API privada, API pública ou API de parceiros. Dentro do Apache APISIX, os plugins são construídos de maneira semelhante a blocos de Lego. Você pode facilmente remover ou adicionar um plugin sem reiniciar o serviço.

Então, vamos olhar para o plano de controle. No plano de controle, o administrador escreve as configurações no cluster etcd através da API de administração, e o plano de dados do APISIX observará o etcd, para que as configurações possam alcançar todos os planos de dados em milissegundos. Após os nós do plano de dados processarem os dados, eles relatam algumas métricas e dados de log para componentes como SkyWalking, Prometheus, etc.

A partir deste diagrama de arquitetura, podemos ver que o APISIX depende apenas do etcd, e não tem RDS como MySQL e PostgreSQL. Portanto, o APISIX é melhor projetado para alta disponibilidade. Ao mesmo tempo, sua arquitetura será mais simples, conveniente para implantação e operações.

Esta imagem é o panorama do Apache APISIX. Olhando da esquerda, o APISIX suporta muitos protocolos de camada 4 e camada 7. Ele não apenas suporta tráfego de navegadores e aplicativos móveis, mas também suporta vários dispositivos IoT para relatar tráfego ao APISIX.

O Apache APISIX também suporta muitos centros de descoberta de serviços externos, incluindo etcd e Consul.

Como um software de infraestrutura muito importante, o gateway de API geralmente é colocado na entrada do tráfego. Portanto, ele não apenas precisa processar todas as solicitações do cliente, mas também precisa se conectar a alguns serviços de backend, como SkyWalking, Datadog, Kafka, etc.

Na parte inferior desta imagem, o APISIX não apenas suporta execução em bare metal, mas também em servidores em várias nuvens públicas. Também suportamos execução na plataforma ARM.

OK, a Parte 1 é uma breve introdução ao APISIX, e então na Parte 2, vou apresentar o desenvolvimento de plugins personalizados no Gateway de API.

O desenvolvimento personalizado é um ponto muito importante quando usamos gateways de código aberto, e tem uma barreira alta. O gateway não é um software que pode ser usado diretamente. Isso é diferente de banco de dados e fila de mensagens. MQ e banco de dados podem ser usados diretamente após a instalação, mas o gateway não. Isso porque o gateway requer mais ou menos desenvolvimento personalizado.

Por exemplo, se sua empresa tem alguns sistemas antigos, ou alguns protocolos especiais, como alguns protocolos na indústria financeira e de segurança, você precisa fazer algumas transcodificações no nível do gateway.

Por outro lado, embora o APISIX forneça mais de 40 plugins, ele definitivamente não consegue atender a todas as necessidades da empresa, porque cada empresa tem algumas necessidades únicas. Então, frequentemente precisamos fazer algum desenvolvimento personalizado de plugins existentes para atender às nossas necessidades. Isso é realmente um grande problema, porque o desenvolvimento de plugins ainda requer mais habilidades. Para o desenvolvimento de plugins, diferentes projetos de código aberto têm soluções diferentes.

Vamos dar uma olhada no Kong primeiro. É um projeto de gateway de API bem conhecido. Tem 5 anos. A pilha de tecnologia do Kong é basicamente a mesma do APISIX, e ambos são implementados com base no NGINX e Lua. Mas a arquitetura técnica do Kong não é a mesma do APISIX. O Kong é baseado em RDS como PostgreSQL e Cassandra. O APISIX usa etcd, e a solução do APISIX está mais próxima do Kubernetes e da nuvem nativa.

O ponto comum entre Kong e APISIX é que os desenvolvedores precisam usar Lua para desenvolver plugins. Lua não é uma linguagem de programação popular, e muitos desenvolvedores não estão familiarizados com ela, embora o Lua em si seja simples. Então, além de tornar o plugin mais simples, qual é a melhor solução?

A solução do Kong é suportar Go para escrever plugins. Essa abordagem atrairá mais desenvolvedores de Go para escrever plugins para atender às necessidades personalizadas de sua própria empresa. Essa é uma boa ideia, mas, por outro lado, o Kong é nativamente implementado com base no Nginx e Lua, e os plugins escritos em Go precisam chamar outro processo, o que terá uma comunicação entre processos, o que tem problemas de desempenho.

Vamos dar uma olhada no segundo, que também é um projeto de plano de dados de código aberto muito conhecido para processar tráfego leste-oeste, o Envoy, que é escrito em C++. Então, o plugin do Envoy é naturalmente implementado em C++ também. Então, não é fácil começar.

O Envoy também suporta outras linguagens para desenvolvimento. Por exemplo, o Envoy suporta filtros Lua, e o filtro Lua tem o mesmo problema do Kong, ou seja, há poucos desenvolvedores familiarizados com Lua. Então, o Envoy também suporta WASM, que pode atrair mais desenvolvedores de outras linguagens para escrever plugins. Essa solução não é perfeita, e a estabilidade e o desempenho do WASM ainda precisam de tempo para melhorar.

As soluções do Kong e do Envoy são as mesmas: eles esperam que mais desenvolvedores tenham a capacidade de desenvolver plugins, seja usando Go, Lua ou WASM. Então, voltando ao APISIX, esperamos encontrar uma bala de prata.

Então, como é essa bala de prata? Achamos que, no nível do gateway, os dois problemas a seguir devem ser resolvidos primeiro para resolver o problema do desenvolvimento personalizado.

O primeiro é que muitos plugins que precisam ser desenvolvidos são realmente simples. Como reutilizar os mais de 40 plugins de código aberto que já existem?

O segundo é permitir que o lado da demanda do gateway na empresa, como gerentes de produto, equipes de operações e segurança, implementem suas próprias necessidades no gateway com o menor custo possível, seria melhor se não precisassem escrever nenhum código.

Se pudermos resolver esses dois problemas, então temos a oportunidade de permitir que mais pessoas, não apenas desenvolvedores, possam desenvolver o gateway de API.

Primeiro, vamos ver como resolver o primeiro problema, que é a reutilização de plugins existentes. Microsserviços já são uma tecnologia muito popular, então podemos introduzir esse conceito nos plugins do gateway de API?

Podemos fazer com que cada plugin faça apenas uma função, assim como um microsserviço, que também é o mesmo que o design de processos no Linux. Portanto, propusemos um conceito chamado micro-plugin.

Cada um de nossos plugins faz apenas uma função independente. Então, precisamos de um design semelhante ao pipe do Linux para conectar esses micro plugins.

Por exemplo, primeiro chamo um plugin de bloqueio de URI. Após a chamada ser concluída, vou julgar se o URI foi realmente bloqueado. Se foi bloqueado, então continuo a chamar o plugin Kafka.

Usando esse método de pipe, esses plugins podem ser conectados. O Apache APISIX agora tem mais de 40 plugins. A permutação de mais de 40 plugins tem possibilidades ilimitadas, o suficiente para atender às necessidades dos usuários.

Mas o problema agora é que, em todos os gateways de API que foram abertos ao público, os plugins não compartilham contexto e não podem cooperar entre si. Então, precisamos conectar esses plugins. Somente fazendo isso, podemos resolver o problema de reutilização de plugins com micro-plugins.

O segundo problema é, depois que temos o micro-plugin, como podemos reduzir o custo de desenvolvimento de novos plugins do gateway de API para zero o máximo possível para atender às necessidades dos usuários. Esperamos que, para não desenvolvedores, ou seja, aqueles gerentes de produto e segurança que não têm formação técnica e não sabem programar, possam realizar suas necessidades sem desenvolvimento, porque eles entendem nossas necessidades melhor.

Ao mesmo tempo, isso diminuirá a barreira para o desenvolvimento de gateways de API, permitindo que mais e mais pessoas contribuam para o gateway de API. Se usarmos um slogan, isso é "da criatividade à criação", podemos não apenas escrever nossas próprias ideias em documentos para desenvolvedores, mas também criar diretamente um novo plugin.

Isso parece uma boa ideia, então pode ser realizado? Na verdade, podemos sair do pensamento técnico para ver como outras indústrias são resolvidas.

Por exemplo, no processo de motor da indústria médica, eles são construídos de forma GUI, porque seus usuários são médicos. Então, o Lego para crianças é o mesmo. Você pode usar um número limitado de blocos para construir um número infinito de formas possíveis.

Juntando as ideias de GUI e Lego, então podemos ver que é na verdade o Scratch, que é como as crianças aprendem a programar, então a barreira será muito baixa.

Com base nos dois problemas anteriores que resolvemos, o APISIX propôs exclusivamente um novo conceito: orquestração de plugins. Aqui está uma demonstração da orquestração de plugins, podemos dar uma olhada neste pequeno vídeo primeiro.

Neste vídeo, primeiro criamos um plugin de bloqueio de URI, e então criamos uma condição de julgamento. Se o bloqueio de URI for verdadeiro, então adicionaremos ao plugin de injeção de falhas; se o resultado do bloqueio de URI for falso, passaremos para o plugin Kafka para registrar logs.

Então configuramos cada plugin e a condição de julgamento. Finalmente, vamos verificar com curl para ver se este novo plugin realmente funciona no nó do gateway. Sim, funciona.

Em seguida, vou explicar como essa orquestração de plugins é implementada. Isso também pode ser uma questão técnica que todos estão preocupados.

Para implementar a orquestração de plugins, precisamos seguir três etapas.

Na etapa 1, precisamos usar DAG para descrever este novo plugin. Podemos ver que o gráfico com a seta à esquerda é na verdade um DAG (grafo acíclico direcionado), que é o mesmo que o código descrito no vídeo anterior. Então, esta é uma forma de descrição amigável para humanos. Para o computador, temos que transformá-lo em uma linguagem de descrição de uma estrutura de dados à direita. Por exemplo, o nó número 1 seguido por 2 4 6 significa o nó 1, que aponta para o segundo, o quarto e o sexto nós; o valor do número 3 é nulo, o que significa que não há outros nós atrás do nó número 3, e os outros são semelhantes. Dessa forma, convertemos um DAG em uma descrição de estrutura de dados.

Depois de ter essa estrutura de dados, então convertemos essa estrutura de dados em uma string JSON, e passamos essa string JSON para o servidor. A string JSON à direita é convertida do plugin que vimos na demonstração.

Após a etapa 1, já temos uma string descrita por JSON, mas como convertemos essa string em código que pode ser executado pelo APISIX?

Sabemos que no APISIX estamos executando código Lua, então precisamos de um compilador, para analisar o JSON em uma AST (árvore de sintaxe abstrata), e finalmente gerar código Lua. Neste momento, usamos jsonschema para fazer essa etapa. Abaixo está o repositório de código aberto.

Depois de gerar o código Lua, usamos o plano de controle do APISIX para escrever o código Lua no etcd através da API de administração, e então o nó do plano de dados do APISIX obtém o código Lua através do watch etcd. O APISIX tem a capacidade de executar dinamicamente o código Lua, assim como o plugin serverless do APISIX.

Portanto, o novo plugin gerado pela orquestração de plugins, desde o DAG até a execução real do nó de dados, todo o processo é dinâmico, o que é uma característica muito importante do APISIX.

Se você chegou até aqui, você tem uma pergunta, onde posso experimentar? Não se preocupe, há um projeto de código aberto aqui, e também temos uma demonstração online.

Na última parte, quero falar sobre nossas reflexões sobre o futuro do gateway de API. O gateway de API existe há muito tempo. Há muitas empresas e projetos de código aberto fazendo gateways de API há mais de dez anos. Então, na era da nuvem nativa, o gateway de API está enfrentando mudanças nas necessidades dos usuários, e requisitos mais altos são colocados para os gateways de API.

Uma tendência é que os gateways de API tradicionais norte-sul comecem a processar tráfego leste-oeste de microsserviços. Por exemplo, o NGINX lançou o NGINX Control e o NGINX Unit. Kong e APISIX também atuam como gateways de API de microsserviços.

Ao mesmo tempo, o projeto de mash de serviço leste-oeste também está tentando atuar como o gateway de acesso norte-sul. Então, para projetos de código aberto, todos querem processar todo o tráfego.

Projetos de código aberto sobre processamento de tráfego estão florescendo, podemos ver o BFE da Baidu e o MOSN da Alibaba. Todos estão focados em tráfego.

O segundo é o baixo código. A melhor solução é que o PM possa implementar recursos diretamente por orquestração de plugins, para que os desenvolvedores prestem mais atenção ao próprio gateway.

Dessa forma, o negócio e o núcleo do gateway de API são desacoplados. Você pode permitir que pessoas que não entendem de tecnologia e desenvolvimento de plugins contribuam com plugins para o projeto de código aberto. Isso é muito importante.

O terceiro ponto é o tempo real. Com a popularização do 5G e IoT, e a adoção do Kubernetes nas empresas, isso colocou requisitos muito altos para o efeito em tempo real da configuração, o processo de solicitações e a análise de dados em tempo real. Para o gateway, se você não puder ser em tempo real, com muito alto desempenho e com latência muito baixa, então ele não sobreviverá nos próximos três a cinco anos.

Por último, mas não menos importante, é o código aberto. Podemos ver que o software está comendo o hardware, e o software de código aberto está comendo o software. No final, todo o software de infraestrutura é de código aberto.

O mesmo vale para o gateway de API. O código aberto permite que as empresas o usem a um custo mais baixo, sem se preocupar com o bloqueio de fornecedores. Além disso, a oportunidade comercial do código aberto também trará mais para os desenvolvedores de código aberto. Este é um bom modelo para uma situação de ganha-ganha.