APISIX motiva a atualização do API Gateway no Tencent BlueKing

Este estudo de caso é compartilhado por Lei Zhu, Diretor Técnico da Plataforma BlueKing PaaS, IEG (Interactive Entertainment Group), Tencent

Sobre o BlueKing

O BlueKing é um conjunto interno de pesquisa e operação integrada PaaS incubado dentro do Tencent IEG (Interactive Entertainment Group), servindo várias unidades de negócios e plataformas internas. Seu papel é fornecer serviços de ciclo de vida completo para os projetos da empresa nas etapas de CI (Integração Contínua), CD (Entrega Contínua) e CO (Operação Contínua).

Visão Geral

Desafios

• Baixo Desempenho: Baixo desempenho em condições de alta concorrência e algoritmo de roteamento, resultando em correspondência e encaminhamento lentos de rotas
• Enorme Pressão no Banco de Dados: As políticas de roteamento são armazenadas no MySQL. Portanto, o banco de dados é sobrecarregado com muitas solicitações de recuperação
• Custos Elevados: O Redis é amplamente utilizado em muitos cenários, causando altos custos de sobrecarga
• Isolamento Insuficiente: Não é possível realizar isolamento físico; conexões de longo prazo instáveis
• Suporte a Protocolo Único: Apenas suporta o protocolo HTTP
• Sem Suporte a Roteamento Dinâmico: Não amigável para liberação canário e incapaz de encapsular cenários
• Falta de Descoberta de Serviço: Não amigável para arquitetura de microsserviços

Objetivos

• Transformar as capacidades da plataforma em microsserviços independentes e realizar a transformação em microsserviços para formar uma arquitetura PaaS
• Usar tecnologia de baixo código para desenvolver SaaS de forma eficiente e utilizar as capacidades de microsserviços da plataforma PaaS
• Responder de forma flexível a diferentes cenários de serviço através de vários SaaS

Resultados

• Realizou a operação e expansão unificada do gateway usando o recurso personalizado CRD fornecido pelo K8s
• Forneceu recursos mais ricos integrando o APISIX: gerenciamento de recursos, liberação de versões, documentos automáticos, gerenciamento de permissões, observabilidade, monitoramento e proteção de segurança
• Reduziu os custos para suportar cenários de descoberta de serviço com interfaces e regulamentos unificados para desenvolvedores

Diversidade e Complexidade de Jogos Exigem o Gateway de API BlueKing

Dentro do Tencent, podem existir milhares de jogos. Exceto por alguns jogos desenvolvidos internamente, outros pertencem a agências. Os jogos diferem em idiomas, armazenamento em que dependem e o estilo arquitetônico determina que o BlueKing desenvolveu seu próprio gateway de API.

Diante de um cenário de negócios tão complexo envolvendo um grande número de arquiteturas heterogêneas, o BlueKing, como uma plataforma interna, precisa transformar seu gateway de API para desenvolver uma arquitetura PaaS, então usar a tecnologia de baixo código para desenvolver SaaS de forma eficiente e utilizar a capacidade de microsserviços da PaaS, e usar vários SaaS para lidar com cenários de serviço.

Para abstrair a arquitetura do BlueKing, podemos obter um diagrama de API.

• Por um lado, o BlueKing é uma plataforma complicada com requisitos complexos para um gateway unificado. Além de funcionar como um proxy para chamar a API das plataformas, o BlueKing requer mais capacidades de gateway, por exemplo, descoberta de serviço, autorização e autenticação, roteamento dinâmico, liberação canário e limitação de taxa, etc.

• Por outro lado, com o desenvolvimento da tecnologia de nuvem nativa, muitos SaaS e plataformas internas agora são implantados em clusters K8s. Este cenário coloca novos requisitos para o gateway, como controle de tráfego unificado de solicitações de chamada externa através de um gateway de tráfego unificado ou gateway de API.

Ao mesmo tempo, alguns sistemas de negócios internos usam algumas das capacidades de infraestrutura da plataforma BlueKing, como gerenciamento de contêineres ou monitoramento. Eles também precisam de um gateway de serviço unificado para gerenciar todo o tráfego de chamadas.

Com o desenvolvimento dos requisitos de negócios internos, o gateway de API do BlueKing precisa suportar cenários cada vez mais diversos.

Gateway de API BlueKing 1.0

O Gateway de API BlueKing 1.0 foi projetado para permitir que o chamador das plataformas (incluindo vários SaaS e motores de processo) chame diretamente o gateway de API para completar a conversão de protocolo e verificação de autoridade através do gateway.

A arquitetura também era relativamente simples, dividida em duas partes: o lado do servidor e o lado de gerenciamento. As plataformas devem acessar o lado de gerenciamento, configurar os endereços de recursos de API e suas permissões correspondentes das plataformas, e finalmente registrar seus serviços com o Gateway de API.

Após vários anos, com o aumento de solicitações e cenários complexos, as deficiências do Gateway de API BlueKing 1.0 começaram a aparecer gradualmente. Por exemplo:

• Desempenho ruim do framework: O framework Django foi escolhido para implementação. Seu desempenho é mediano em cenários de alta concorrência e fica sobrecarregado ao processar um grande número de solicitações.

• Desempenho médio de implementação de roteamento: O desempenho do algoritmo usado no roteamento de API é baixo, afetando a velocidade de correspondência e encaminhamento de rotas.

• Banco de dados sobrecarregado: Todas as políticas de roteamento são armazenadas no MySQL. Quando há muitas regras, muitas solicitações de recuperação precisam ser realizadas com grande pressão de consulta.

• Custos elevados de rede: O Redis é amplamente utilizado em vários cenários, resultando em custos de sobrecarga de rede muito altos.

Gateway de API BlueKing 2.0

Para resolver os problemas acima, o BlueKing iterou com base na versão 1.0 e projetou e implementou a versão 2.0. Comparado com a geração anterior, a maior mudança da versão 2.0 foi a reimplementação do framework de gateway e da camada de encaminhamento em Golang, porque o Golang tem mais vantagens que o Python no tratamento de grandes solicitações concorrentes.

Outras mudanças de otimização também foram feitas. Por exemplo, uma implementação de roteamento mais eficiente foi mantida na memória; um cache baseado em memória foi introduzido na camada intermediária para reduzir a dependência do Redis. A nova arquitetura também adiciona gerenciamento de ciclo de vida para gateways com várias versões e ambientes e introduz um mecanismo de plugin estendido para facilitar que os desenvolvedores expandam as capacidades do gateway através de plugins.

No geral, o Gateway de API BlueKing 2.0 resolve problemas de desempenho e a maioria das dores encontradas na versão 1.0. Mas com o passar do tempo, novos problemas começaram a surgir lentamente.

• Isolamento insuficiente: Não é possível alcançar isolamento físico real; o processo de liberação causará desconexão de conexões de longo prazo

• Suporte a protocolo único: Apenas HTTP é suportado, e a demanda por protocolos não HTTP está aumentando em cenários reais

• Sem suporte a regras de roteamento dinâmico: Não suporta regras de roteamento dinâmico correspondidas por condições; não é amigável o suficiente para cenários de liberação canário; incapaz de combinação e encapsulamento baseados em cenários

• Falta de capacidade de descoberta de serviço: Falta de capacidade de descoberta de serviço automática, não amigável para arquitetura de microsserviços

APISIX Destaque na Seleção de Tecnologia do Gateway de API BlueKing

Existem muitos sistemas de produtos na empresa que precisam usar o gateway de API. É muito difícil integrar todos os diversos requisitos para o gateway no mesmo conjunto de gateways.

Portanto, temos a ideia de projetar um gateway distribuído. Ou seja, um grande gateway é dividido em muitos microgateways, que são usados para equilibrar as diferenças nos requisitos de diferentes sistemas para gateways." disse Zhu.

Os componentes da arquitetura de gateway distribuído são principalmente divididos em duas categorias: o lado de gerenciamento e a instância de microgateway.

O lado de gerenciamento gerencia e controla uniformemente cada microgateway, e o administrador de cada gateway configura e gerencia o gateway. As instâncias de microgateway são serviços de gateway individuais implantados de forma independente, que assumem o tráfego de acesso de cada grupo específico de serviços e realizam o controle de acesso relacionado de acordo com as configurações do lado de gerenciamento. Todas as instâncias de microgateway são controladas pelo mesmo conjunto de lados de gerenciamento.

"Em termos de seleção de tecnologia do microgateway, nos referimos a vários gateways de código aberto populares no mercado, como Kong e Tyk. Após comparar popularidade, stack de tecnologia, suporte a protocolos e outros níveis, finalmente escolhemos APISIX como a tecnologia de backend mais importante do nosso microgateway." disse Zhu.

Zhu disse que o BlueKing selecionou o APISIX porque ele é implementado com base em NGINX + Lua, então seu desempenho geral tem vantagens em comparação com aqueles baseados em Golang. Além disso, o APISIX é notável em escalabilidade, e também suporta a expansão de capacidades através de plugins de múltiplas linguagens de programação. Muitos casos de uso típicos foram testemunhados.

Além disso, graças à sua grande compatibilidade, o APISIX pode ser personalizado de acordo com as necessidades do BlueKing. Por exemplo, com base no APISIX, o BlueKing personalizou a superfície de controle do APISIX de acordo com os requisitos internos.

Gateway de API BlueKing 3.0 Baseado no APISIX

No ambiente de nuvem nativa, o K8s é o componente básico mais crítico que precisa de atenção. Como todo o microgateway é projetado para o ambiente de nuvem nativa, a versão 3.0 tem um novo design de arquitetura baseado no K8s.

A parte central é usar o recurso personalizado CRD fornecido pelo K8s para realizar todo o conjunto de operações e expansão do gateway de API.

Como mostrado na figura acima, o gateway introduz um conjunto de recursos CRD do K8s, incluindo BkGatewayStage (ambiente de gateway), BkGatewayService (serviço de backend), etc. Através desses CRDs, o BlueKing pode controlar o comportamento específico de cada instância de microgateway.

Vários "Operators" na figura são a parte central desta arquitetura. Acima está o serviço Plugin Operators, que contém uma série de operadores de plugin. Por exemplo, o Operator responsável pela descoberta de serviço escreverá o endereço do serviço de backend registrado no centro de descoberta de serviço no cluster K8s.

O Operator central no meio monitora todos os recursos CRD relacionados ao gateway. O reconciliador de recursos é responsável por converter a configuração do gateway em um formato que a instância de microgateway APISIX possa entender, realizando assim o gerenciamento de ciclo de vida completo do microgateway.

Este conjunto de microgateway é dividido em dois tipos de implantação:

• Gateway compartilhado: O tipo padrão, que é implantado na plataforma, e o endereço de acesso à API é gerado e gerenciado uniformemente pela plataforma.

• Gateway dedicado: O usuário implanta uma instância de "microgateway", que se torna um "gateway dedicado" após o acesso à plataforma. O endereço de acesso à API precisa ser gerenciado manualmente, e o tráfego flui diretamente do "gateway dedicado" para o serviço de backend.

Há apenas um lado de gerenciamento unificado, cujas capacidades, como gerenciamento de multiambiente e controle de acesso, são compartilhadas por todos os gateways. No entanto, entre os diferentes tipos de instâncias de microgateway que ele gerencia, os conjuntos de recursos suportados diferem uns dos outros.

Tomando a instância de gateway compartilhado como exemplo, o conjunto de recursos que ela suporta é relativamente básico, que inclui principalmente autenticação de login unificada, limitação de taxa e suporte a múltiplos protocolos. Mas as instâncias de gateway dedicado independentes têm suas próprias capacidades personalizadas únicas. Como o gateway dedicado e o negócio pertencem ao mesmo cluster, ele pode realizar rapidamente roteamento dinâmico, descoberta de serviço personalizada, etc., e usar a robusta escalabilidade do APISIX para personalizar mais capacidades.

Com base na arquitetura e modos acima, o Gateway de API BlueKing 3.0 fornece funções mais ricas com o suporte do APISIX. Por exemplo, gerenciamento de recursos, liberação de versões, documentos automáticos, SDK, gerenciamento de permissões, observabilidade, monitoramento e alertas, e proteção de segurança.

Cenários Práticos do Gateway BlueKing 3.0 Usando APISIX

Existem quatro cenários práticos típicos dentro do Tencent: descoberta de serviço, autenticação unificada, roteamento dinâmico e gerenciamento de licenças do cliente.

Descoberta de Serviço

A descoberta de serviço é uma capacidade básica exigida pela arquitetura de microsserviços. Internamente, ela pode ser implementada através do recurso personalizado CRD. Uma definição YAML válida de descoberta de serviço é mostrada no código no lado direito da figura abaixo.

Após os recursos CRD acima serem escritos no cluster K8s, eles acionarão as ações relacionadas dos controladores de descoberta de serviço. Posteriormente, o reconciliador pode capturar a configuração de descoberta de serviço correspondente e criar objetos de programa relacionados à descoberta de serviço.

Então o reconciliador lê as informações de endereço relevantes do centro de descoberta de serviço através da interface de descoberta de serviço embutida como Watcher e Lister e reescreve o endereço obtido de volta no cluster K8s através do recurso CRD BkGatewayEndpoints.

Após algum processamento complexo pelo Operator central à direita, esses endpoints são finalmente sincronizados com o upstream correspondente ao APISIX. Um processo completo de descoberta de serviço é concluído.

Para facilitar o desenvolvimento, o BlueKing implementou um framework de descoberta de serviço geral, que fornece uma interface e especificação de desenvolvimento unificadas e pode ser usado para suportar outros tipos de cenários de descoberta de serviço a um custo baixo.

Autenticação Unificada

A parte de autenticação unificada é relativamente simples. Na prática diária, há solicitações de três fontes: navegadores, plataformas e usuários individuais. Com base no APISIX, o BlueKing personalizou um plugin de autenticação, BK-Auth, para alcançar autenticação unificada.

O processo de implementação específico é mostrado na figura acima. Após a solicitação, o plugin lerá as informações de credencial relevantes do cabeçalho e então chamará uniformemente o serviço de autenticação BK-Auth para verificar a credencial e ler as informações de SaaS correspondentes. Em seguida, o plugin usará a chave privada acordada com o backend para emitir um token JWT e escrevê-lo no cabeçalho da solicitação, e finalmente, escrevê-lo na variável APISIX.

Além da autenticação unificada, também há alguns cenários de autenticação complexos em projetos internos. Sua função principal é julgar se o SaaS tem permissão quando o SaaS chama um determinado recurso de uma plataforma. A autenticação de recurso unificada também é implementada por Golang através do plugin APISIX, como mostrado na figura abaixo.

As solicitações do cliente podem primeiro buscar as informações do aplicativo SaaS através do link de autenticação, então interagir com o plugin de autenticação baseado em RPC ao passar o ext-plugin. Neste momento, o plugin de autenticação consultará diretamente os dados relacionados à autenticação no cache, sincronizado pelo lado de gerenciamento através do mecanismo completo e incremental, e então completará a autenticação.

Roteamento Dinâmico

Um cenário de aplicação típico de roteamento dinâmico vem da plataforma de gerenciamento de contêineres do BlueKing. A plataforma de contêineres do BlueKing gerencia muitos clusters K8s, alguns dos quais são clusters de serviço e alguns são clusters de dados.

Como usuário, você frequentemente precisa solicitar os APIServers desses clusters. Quando uma solicitação de usuário entra no microgateway, o gateway determina para qual APIServer do cluster encaminhá-la com base no caminho da solicitação.

Após a entrada da solicitação, o plugin de roteamento dinâmico primeiro extrai as informações de ID do cluster, então reescreve a rota e, em seguida, determina se o cluster está diretamente conectado.

Para clusters não diretamente conectados, um upstream do gerenciador de cluster BCS é gerado primeiro e então interage com o Agente BCS através dele, e finalmente passa a solicitação para o APIServer do cluster.

Para clusters diretamente conectados, o processo é semelhante ao plugin de autenticação unificada acima, e o plugin sincronizará periodicamente algumas informações básicas relacionadas ao cluster. Após encontrar as informações do cluster, gera o upstream relevante, redefine a lógica de conexão através do plugin APISIX e, finalmente, envia a solicitação para o APIServer do cluster.

Gerenciamento de Certificado do Cliente

Nos cenários práticos do BlueKing, há uma classe de sistemas que usa um modo de verificação de certificado do cliente mais complexo ao registrar recursos no gateway. Portanto, se um usuário deseja solicitar seus recursos, ele deve fornecer um certificado de cliente válido.

A implementação específica é mostrada na figura acima. O gerenciador de gateway precisa configurar o certificado do cliente usado pelo gateway para diferentes ambientes no lado de gerenciamento. Após a configuração, o certificado será publicado no cluster K8s, onde o microgateway correspondente está localizado.

Este processo usa alguns recursos CRD e recursos Secret oficiais do K8s e será continuamente reconciliado pelo serviço Operator central, como encontrar o certificado correspondente de acordo com o domínio. A configuração efetiva do certificado do cliente será finalmente refletida na configuração relevante do Serviço APISIX. (Como mostrado na caixa vermelha no canto superior direito da figura acima)

Resumo

Apache APISIX é um gateway de API de nuvem nativa de código aberto, dinâmico, escalável e de alto desempenho para todas as suas APIs e microsserviços. Sendo doado à Apache Software Foundation pela API7.ai, o APISIX cresceu para se tornar um projeto de código aberto de nível superior da Apache.

Com o desenvolvimento da arquitetura de microsserviços e dos projetos de negócios internos, o gateway de API anterior não consegue mais atender às necessidades. O BlueKing do Tencent não apenas resolveu o problema, mas também forneceu recursos mais ricos aproveitando o APISIX.