xRPC será lançado, obtenha mais detalhes sobre o ecossistema APISIX
API7.ai
January 21, 2021
À medida que os cenários e requisitos de negócios se tornam mais complexos e diversos, cada vez mais padrões e protocolos estão surgindo, e o Apache APISIX, como um projeto de código aberto de topo da Apache Foundation, tem participado ativamente e promovido a expansão de aspectos relacionados ao ecossistema.
Neste artigo, trazemos exemplos do futuro framework xRPC do Apache APISIX e dos plug-ins multilíngues, abordando duas perspectivas: proxy multiprotocolo e suporte multilíngue.
Proxy Multiprotocolo
No Apache APISIX, cada solicitação corresponde a um objeto Route. Atualmente, existem dois cenários principais de proxy no Apache APISIX.
O primeiro é o proxy de protocolo HTTP, que atualmente é o proxy de solicitação mais comumente usado no APISIX. Com base no proxy de protocolo HTTP, o Apache APISIX implementou dezenas de capacidades de governança de tráfego, como controle de fluxo granular, segurança e observabilidade.
O segundo é um proxy de protocolo dinâmico e balanceamento de carga baseado em TCP e UDP, que fornece as capacidades mais básicas de admissão de tráfego e registro de logs no nível de link. Esse modelo de proxy pode intermediar qualquer solicitação baseada em protocolos TCP/UDP, como MySQL, Redis, Mongo ou DNS. No entanto, como é um proxy baseado em TCP/UDP sem protocolos de camada de aplicação superior, ele só pode obter algumas informações básicas sobre o quaternion, portanto, é um pouco mais fraco em termos de escalabilidade.
Por que xRPC
Devido às limitações do Stream Route em termos de proxies de protocolo, e ao nosso desejo de suportar mais protocolos de camada de aplicação no APISIX para atender a mais usuários e cenários de aplicação, o framework xRPC foi criado.
O framework xRPC torna muito fácil estender as capacidades de protocolo, tanto para protocolos de dados específicos quanto privados, com granularidade precisa e controle de nível 7 semelhante ao proxy de protocolo HTTP, como observabilidade no nível de solicitação, controle de acesso avançado e políticas de proxy.
O que é xRPC
xRPC literalmente significa que X é uma representação abstrata de um recurso de protocolo. E RPC é o que consideramos como todos os recursos que passam pelo gateway como um despacho de processo, ou seja, é um framework de extensão de protocolo. Portanto, em termos de posicionamento, xRPC é um framework base, e não uma implementação de um protocolo específico.
Como pode ser visto na arquitetura acima, xRPC é um framework baseado em extensões do APISIX Core. Sobre esse framework, os usuários podem implementar diferentes protocolos de camada de aplicação, como Redis, MySQL, Mongo e Postgres. Sobre os diferentes protocolos, é possível abstrair alguns fatores comuns e implementar capacidades relacionadas a plug-ins, para que diferentes protocolos possam compartilhar essas capacidades.
Portanto, o principal papel do xRPC pode ser resumido como: fornecer acesso a protocolos de camada de aplicação padronizados, suportar o compartilhamento de capacidades entre protocolos e permitir que os usuários obtenham a capacidade de estender protocolos personalizados.
Exemplos de Cenários de Aplicação
Com o framework de protocolo xRPC em vigor, quais cenários ele pode abordar? Aqui estão alguns exemplos.
- Exemplo 1: O Redis não suporta TLS em versões anteriores. Se houver várias versões do Redis em nosso sistema, e não pudermos atualizar o Redis em produção por algum motivo, mas precisarmos adicionar capacidade TLS. Nesse caso, podemos usar o Protocolo Redis baseado em xPRC para resolver a situação acima.
- Exemplo 2: Quando queremos limitar a frequência de determinados IPs ou chamadores e queremos visualizar a frequência de cada fonte de chamada, o que o Redis não suporta. Isso é perfeitamente resolvido usando o Protocolo Redis, que é estendido pelo xRPC.
- Exemplo 3: Se você quiser usar o MySQL para ativar temporariamente a função de consulta lenta, basta acessar o Protocolo MySQL e configurar a política relevante no APISIX, o que economiza o passo tedioso de fazer login nas máquinas de instância uma por uma.
Claro, existem muitos cenários de aplicação semelhantes, e esperamos que, após o lançamento do recurso, você possa experimentar e praticar mais na aplicação real. O processo de invocação do xPRC é mostrado no diagrama a seguir.
Uma vez que os serviços upstream são assumidos pelo Apache APISIX, os diferentes serviços de aplicação upstream podem ser gerenciados de forma unificada. Funções como registro de logs, monitoramento, segurança e solução de problemas podem ser realizadas por meio de um conjunto padronizado de políticas.
Fases de Implementação Planejadas
O design atual do framework xRPC do Apache APISIX está inicialmente dividido em 5 fases.
- Fase 1: Leitura de dados e decodificação de protocolo.
- Fase 2: Fase de Acesso. Fornece função de acesso a plug-ins, que pode realizar cenários de demanda de segurança, controle de fluxo e acesso.
- Fase 3: Encaminhamento de dados de proxy e balanceamento de carga. Fornece suporte de acesso para políticas e algoritmos personalizados de balanceamento de carga.
- Fase 4: Envio de dados e codificação de protocolo.
- Fase 5: Fase de Registro. Fornece acesso a plug-ins para realizar cenários de demanda de registro e logging.
Ecossistema Multilíngue
Para atender à base de linguagens de computação cada vez mais rica e ampla, criar suporte de código para ambientes multilíngues tornou-se o primeiro limiar para lidar com o desenvolvimento futuro da tecnologia. O Apache APISIX também fez muita exploração e prática no caminho do desenvolvimento multilíngue.
Por exemplo, recentemente implementou suporte para WebAssembly. Para detalhes e recursos, consulte o artigo "Apache APISIX Abraça o Ecossistema WASM". Claro, o suporte para WASM no Apache APISIX ainda é experimental, e continuaremos a melhorar o suporte para WASM no futuro. Se você estiver interessado neste projeto, sinta-se à vontade para contribuir com o projeto wasm-nginx-module.
Enquanto isso, o Apache APISIX já suporta várias linguagens de desenvolvimento através do "xPluginRunner Multilanguage Plugin Runtime" antes que o suporte a WASM fosse implementado. Ou seja, ao desenvolver plug-ins do APISIX, os usuários podem escrever e estender plug-ins do APISIX não apenas com código Lua, que é nativamente suportado pelo APISIX, mas também com suas próprias linguagens familiares, como Go, Java e Python.
xPluginRunner
A implementação do xPluginRunner é mostrada na figura acima. Todo o processo de comunicação é "antes" e "depois" da execução dos plug-ins internos, o APISIX iniciará solicitações RPC locais para o runtime de plug-ins de cada linguagem. No runner de plug-ins, a computação e o processamento de políticas dentro de cada plug-in são implementados, e o resultado é finalmente respondido ao APISIX para decisões subsequentes com base no resultado da resposta.
O xPluginRunner serve como uma ponte para comunicação com o Apache APISIX e principalmente implementa a análise de protocolos de dados privados e o encapsulamento e desencapsulamento de mensagens RPC.
Atualmente, a solução xPluginRunner do Apache APISIX está em um estágio relativamente estável, e sabemos pelo feedback da comunidade que algumas empresas já começaram a experimentá-la em ambientes de produção. Se você estiver interessado neste projeto, também é bem-vindo para participar de vários projetos de plug-ins de linguagens de desenvolvimento.
Finalmente, mostraremos como desenvolver plug-ins do APISIX com base no Java Plugin Runner com um exemplo simples em Java.
Exemplo de Java Plugin Runner
Primeiro, ao desenvolver o plug-in, precisamos implementar a Interface PluginFilter. O método name na Interface é usado principalmente para identificar e extrair o nome do plug-in, e o método filter é usado para filtrar a solicitação (ou seja, executar a lógica principal do plug-in).
Um ponto adicional a ser observado é que os parâmetros request e response que aparecem no código acima têm lógica fixa no Runner (todos os Runners se aplicam):
- Se você quiser que a solicitação continue a ser encaminhada e apenas fazer algumas configurações de política (como reescrever os parâmetros da solicitação, cabeçalhos, etc.), você pode simplesmente manipular o objeto
request. - Se você quiser terminar a solicitação, pode fazê-lo com o objeto
response(por exemplo, definir o corpo da resposta, cabeçalhos da resposta, códigos de status, etc.).
O APISIX terminará a solicitação atual assim que perceber que o objeto response no Runner foi manipulado.
Uma vez que o desenvolvimento do plug-in estiver concluído, é hora de praticar a aplicação no APISIX.
Primeiro, compile o Runner e os plug-ins no projeto em pacotes jar e configure o caminho absoluto dos pacotes jar no arquivo de configuração principal do APISIX da seguinte maneira.
Finalmente, reinicie o Apache APISIX e você estará pronto para as sessões de configuração de roteamento e plug-in e validação de solicitação.
Resumo
Este artigo traz o próximo lançamento do framework xRPC para o Apache APISIX e detalhes relacionados, bem como uma demonstração detalhada do suporte do Apache APISIX ao desenvolvimento multilíngue.
O artigo também mostra os detalhes do suporte do Apache APISIX ao desenvolvimento multilíngue. Ele mostra os esforços orientados ao ecossistema do Apache APISIX tanto do ponto de vista do proxy multiprotocolo quanto do suporte multilíngue.
Sinta-se à vontade para iniciar uma discussão no GitHub Discussions ou se comunicar via lista de e-mails.