Prática de API Gateway na Tencent com Apache APISIX

O que é um Gateway de API?

Arquitetura tradicional

Antes de integrar com o Gateway de API, tínhamos poucas maneiras de reutilizar algumas funcionalidades gerais, como:

• Segurança: autenticação, autorização, anti-replay, anti-tampering, anti-DDoS, etc.
• Confiabilidade: degradação de serviço, fusão, limitação de tráfego, entre outros.

Na arquitetura tradicional, a maneira mais comum de lidar com isso era colocá-las em um framework de serviço e implementá-las por meio de AOP, semelhante ao seguinte diagrama de arquitetura:

O diagrama de arquitetura tradicional possui os seguintes módulos.

• Backend: Serviços de backend
• AOP: Camada AOP suportada pelo framework;
• SD: Centro de Serviços, usado para descoberta de serviços internos. Em tecnologias cloud-native, frequentemente usamos Service para substituir esse componente;
• LB: Balanceador de carga, usado na fronteira da rede como ponto de entrada para tráfego externo.

Esse tipo de arquitetura era comum no design dos primeiros anos, o que deu origem a muitos frameworks de serviço abrangentes e completos, como Dubbo, SpringCloud, etc., e percebemos que a maioria deles tem muitas funcionalidades semelhantes.

A vantagem dessa arquitetura é que as relações entre upstream e downstream são mais fáceis e claras, e reduz uma retransmissão na transmissão de rede. Mas suas desvantagens também são evidentes:

• Funcionalidades padrão forçam atualizações de serviços de negócios: como são usadas referências de código, temos que recompilar os serviços de negócios para que as funcionalidades entrem em vigor. Algumas equipes que não conseguem fazer lançamentos contínuos precisam liberar durante o período de inatividade do negócio.
• Dificuldade de gerenciar versões: Como não podemos atualizar todos os serviços para a versão mais recente a cada lançamento, após um tempo, o desempenho de vários serviços ficará inconsistente.

Por que não colocar essas mesmas funcionalidades em um serviço independente, que pode ser atualizado ou mantido separadamente?

Modo Gateway

Comparado com a arquitetura tradicional, podemos ver um componente adicional entre os serviços de backend e o LB: o Gateway.

Um gateway geralmente contém muitas funcionalidades padrão e reutilizáveis, como Autenticação, Gerenciamento de Tráfego, etc. Aqui estão os benefícios que podemos obter:

• O Gateway é um componente dependente nos sistemas, e podemos ter uma experiência de manutenção melhor.
• O Gateway é independente de linguagem.

No entanto, o modo gateway também tem suas desvantagens:

• Como o tráfego é primeiro encaminhado para o gateway, há uma retransmissão adicional e maior latência. Isso aumentará a complexidade de solucionar problemas.
• Se o gateway não funcionar corretamente, ele pode se tornar um gargalo para todo o sistema.

Como equilibrar os benefícios e desvantagens do modelo de gateway é um desafio para a equipe técnica. Vamos ver como o OTeam da Tencent trabalha com o Apache APISIX.

Introdução

OTeam

O OTeam da Tencent é um grupo de equipes, e cada equipe mantém um ou vários produtos técnicos. Eles têm como objetivo construir uma plataforma intermediária estável, mas robusta, para sistemas internos. Um dos OTeams suporta a distribuição personalizada do Apache APISIX dentro da Tencent.

Para integrar as rodas duplicadas dentro da empresa e consolidar a base técnica intermediária, a Tencent colocou vários produtos técnicos da mesma natureza no mesmo OTeam, integrando a equipe de manutenção e unindo-os para que possam gradualmente se fundir em um grande e abrangente produto, que é o OTeam.

Alguns OTeams têm mais de uma dúzia de produtos sob sua responsabilidade, enquanto outros têm apenas um. Por exemplo, o OTeam onde o Apache APISIX está localizado tem apenas um produto, o Apache APISIX. O propósito original desse OTeam é manter as funcionalidades personalizadas do Apache APISIX dentro da Tencent.

Apache APISIX

Apache APISIX é um Projeto de Nível Superior da Apache Software Foundation, e aqui estão alguns pontos-chave:

• O Apache APISIX é um gateway de API cloud-native e dinâmico baseado no OpenResty, com um desempenho de roteamento superior ao do Kong.
• O Apache APISIX oferece ricas funcionalidades de gerenciamento de tráfego, como balanceamento de carga, upstream dinâmico, lançamento canário, circuit breaking, autenticação, observabilidade e muito mais.
• O Apache APISIX é bom em lidar com tráfego tradicional norte-sul, bem como tráfego leste-oeste entre serviços. Ele também pode ser usado como um controlador de ingress do k8s.
• O Apache APISIX usa por padrão o ETCD como centro de configuração, que pode atualizar a configuração em segundos.
• O Apache APISIX se formou na Apache Software Foundation em apenas alguns meses.

Estratégia operacional do OTeam da Tencent

O diagrama acima mostra como o OTeam trabalha com a comunidade do Apache APISIX:

• Os usuários fornecem feedback ou requisitos via GitHub Issue.
• Os membros do OTeam discutem soluções em reuniões semanais ou respondem diretamente no Issue.
• Implementam funcionalidades ou corrigem bugs de acordo com a discussão.
• Revisão de código e verificação de CI, então liberam se necessário.

Esse processo é semelhante a outros projetos de código aberto. Aqui estão alguns pontos-chave:

• Após resolver o Issue, os engenheiros da Tencent determinam se o problema também é comum para a comunidade. Se for, eles enviam um PR para a comunidade.
• O OTeam da Tencent revisa regularmente as novas funcionalidades do Apache APISIX para determinar se são estáveis e se também são um ponto de dor para a Tencent. Se a resposta for sim, eles selecionam os códigos relevantes.

No início, o OTeam sincronizava os códigos com o Apache APISIX a cada 12 horas para poder acompanhar rapidamente o Apache APISIX, mas essa abordagem trouxe alguns problemas:

• Após sincronizar os códigos com o Apache APISIX, podíamos garantir que as regras estavam corretas, mas não podíamos garantir que os códigos estavam estáveis. Alguns erros ocasionais ocorriam em casos de concorrência.
• Os códigos mesclados às vezes causavam conflitos lógicos com vários PRs upstream, mas o CI do Apache APISIX e do OTeam não conseguia detectar isso. Só quando mesclávamos os PRs para o branch principal é que percebíamos que algo estava errado.

Por essas razões, o OTeam agora está migrando para selecionar códigos para funcionalidades necessárias após revisões internas.

Tendência do OTeam

Em maio de 2021, o OTeam implementou o Apache APISIX para mais de dez equipes dentro da Tencent, com um enorme tráfego diário de solicitações de negócios ultrapassando um bilhão. Ao mesmo tempo, o OTeam também desenvolveu mais de dez funcionalidades para o Apache APISIX, incluindo Descoberta de Serviços, Conversão de Protocolo RPC e conexão com a plataforma de monitoramento.

Ao mesmo tempo, o OTeam também contribuiu com algumas funcionalidades padrão para a comunidade do Apache APISIX. Atualmente, dois membros da equipe do OTeam também são PMCs do Apache APISIX, e o OTeam contribuiu com mais de 50 PRs para a comunidade. Acreditamos que o OTeam continuará cooperando com a comunidade do Apache APISIX no futuro.

Funcionalidades internas do OTeam

Pontos de dor internos

A principal responsabilidade do OTeam é manter as funcionalidades do Apache APISIX para a Tencent. Vamos dar uma olhada em quais pontos de dor o OTeam encontrou.

• O framework RPC não é amigável para o frontend: há muitos projetos legados dentro da Tencent que usam o framework TARS, que não suporta diretamente o protocolo HTTP como o TRPC, ele suporta apenas o protocolo TCP mais tradicional do framework RPC, e o conteúdo de transporte usa um protocolo binário específico. Precisamos manter um serviço intermediário para converter essas interfaces em uma forma amigável ao frontend, como HTTP + JSON.
• Diversificação dos centros de serviço: Há muitos Centros de Serviço nos serviços internos da Tencent, como CL5, L5, Polaris, etc. Embora gradualmente usemos o mesmo Centro de Serviço, durante esse período prolongado, usaremos vários centros de serviço simultaneamente. O Apache APISIX inicial não suportava isso.
• Alarme: Como um gateway, o alarme não é uma direção que ele deve priorizar, mas como um componente fundamental, o alarme deve ser um componente obrigatório para a equipe. Como resolver o problema de alarme também é um ponto de dor.
• Segurança: A Tencent tem um grande volume de tráfego e requisitos de segurança. Muitos produtos toC estão usando o OTeam, e eles têm que enfrentar um grande número de abusos de usuários e ataques da rede. Os casos mais típicos são DDos, replay, adulteração de solicitações, etc. Podemos resolver esses problemas na camada do gateway?

Resolução de problemas

O diagrama acima vem de uma simplificação de um caso de implementação dentro da Tencent. Podemos ver que vários problemas levantados foram resolvidos no OTeam:

• Conversão de Protocolo: com base no Apache APISIX, o OTeam alcançou a conversão de protocolo TRPC e TARS. Aqueles que não realizam serviços legados HTTP podem usar diretamente o plugin de conversão no gateway para atender às necessidades de transferência HTTP e RPC sem escrever serviços intermediários.
• Múltiplos Centros de Serviço: Contribuímos com essa funcionalidade para a comunidade. Relatório para a plataforma de monitoramento: O OTeam da Tencent usa plugins para se conectar com plataformas de monitoramento. Os usuários só precisam fazer algumas configurações, e o sistema reportará automaticamente métricas, logs. A propósito, os usuários podem configurar políticas de alarme na plataforma de monitoramento.
• Anti-replay e anti-tampering: O OTeam implementou plugins de anti-replay e anti-tampering, permitindo que negócios externos que precisam dessas capacidades as usem diretamente para proteger a segurança de suas APIs.

Esperamos que esses exemplos possam ajudá-lo a explorar mais cenários de uso do Apache APISIX e usá-lo melhor como uma plataforma útil. Por exemplo, alguém usou o gateway para implementar algumas especificações de API obrigatórias de acordo com as políticas da Tencent Cloud.

Resumo

O OTeam ajudou a equipe de negócios a resolver seus pontos de dor e continuamente melhorou as funcionalidades do Apache APISIX dentro da Tencent, avançando com o desenvolvimento da comunidade.

Se sua equipe não tem um gateway, você pode pesquisar e aprender mais sobre o Apache APISIX e é bem-vindo a participar da comunidade do Apache APISIX.