Snowball Finance transforma sua arquitetura ativo-ativo com APISIX

Wenjie Shi, Engenheiro Sênior de Desenvolvimento da equipe de Infraestrutura da Snowball Finance, compartilhou a prática da Snowball Finance com o APISIX no Apache APISIX Summit ASIA 2022. Este artigo é baseado na apresentação, que introduz como a Snowball Finance utiliza o Apache APISIX para alcançar a evolução de sua arquitetura ativa-ativa interna, permitindo uma gestão de serviços mais flexível.

Desafios

• Módulos de autenticação SDK complexos aumentam a complexidade do sistema e os riscos de segurança quando o centro de usuários é acessado entre regiões, devido à arquitetura ativa-ativa estar disponível apenas no módulo de serviço de mercado.
• O OpenResty carece de um sistema robusto de monitoramento para observabilidade e requer scripts personalizados para alcançar escalabilidade, resultando em custos mais altos de desenvolvimento e operação.
• Um centro de registro NGINX incompleto, sem mecanismo de heartbeat, reduz a disponibilidade e a estabilidade, tornando-o incapaz de lidar prontamente com falhas do sistema.

Objetivos

• Minimizar mudanças sem introduzir muitas variáveis, mantendo a transparência para os grupos de negócios.
• Lidar com problemas de forma unificada no nível da infraestrutura e buscar completar os serviços de autenticação dentro do data center local.

Resultados

• Implementou a autenticação unificada, circuit breaking e limitação de taxa na camada do gateway, reduzindo o acoplamento do sistema e melhorando a qualidade do serviço em cenários de data centers duplos.
• Estabeleceu uma solução de monitoramento unificada da camada do gateway até a camada de serviço, aproveitando o sistema de monitoramento do APISIX e fornecendo excelente suporte para solução de problemas globais.
• Forneceu uma abordagem de implementação elegante para conversão de protocolo gRPC e gestão de serviços.

Contexto

Fundada em 2010, a Snowball Finance começou como uma comunidade de investimentos e agora se tornou uma das principais plataformas de gestão financeira online na China, oferecendo diversos serviços, incluindo conteúdo de alta qualidade, serviços de mercado em tempo real, ferramentas de negociação e gestão de patrimônio para investidores.

Entre esses serviços, o serviço de mercado em tempo real está conectado a múltiplas fontes de dados upstream e fornece serviços de dados estáveis para investidores por meio de streaming, armazenamento e distribuição de dados. Portanto, os serviços de mercado em tempo real sempre foram um grande consumidor de recursos no sistema da Snowball Finance.

Consequentemente, uma das tarefas importantes dentro da Snowball Finance é melhorar continuamente a estabilidade, incluindo a otimização de desempenho dos serviços de mercado. Mesmo assim, durante os picos de tráfego, alguns sistemas ainda podem apresentar lentidão ou até mesmo ficar indisponíveis devido ao aumento de dados, afetando a experiência do usuário.

Nesse contexto, a Snowball Finance lançou um plano de transformação ativa-ativa de serviços para fornecer serviços estáveis e de alta qualidade aos investidores, onde o Apache APISIX simplifica drasticamente a implementação. Além disso, como um gateway de API nativo da nuvem, o APISIX possui uma comunidade ativa e um ecossistema rico, suportando múltiplos plugins. Essas vantagens também fornecem uma boa base para a evolução da arquitetura nativa da nuvem da Snowball Finance.

Pontos de Dificuldade na Transformação Ativa-Ativa

No período em que aplicava a arquitetura standalone, o tráfego do usuário entrava por meio do Server Load Balancing (SLB), passava pelo gateway para processamento de lógica comum simples e era então encaminhado para o serviço backend. O serviço backend, por meio de um módulo de autenticação integrado, iniciava a autenticação do usuário com o Centro de Usuários da Snowball usando um SDK e continuava com o processamento subsequente após a autenticação bem-sucedida.

Em cenários práticos de negócios, alguns pontos de dificuldade gradualmente surgiram.

1. Módulos de Autenticação SDK Complexos

Ao implementar a transformação ativa-ativa, o provedor e o consumidor de microsserviços não podem ser implantados e lançados simultaneamente. Quando o serviço de mercado da Snowball Finance foi lançado na nuvem, mas o centro de usuários ainda não era suportado na nuvem, ocorreram chamadas entre data centers. De acordo com estatísticas do centro de usuários, suas chamadas RPC atingiram cerca de dezenas de bilhões por dia, e o volume de pico pode atingir 50.000 QPS, o que pode resultar em maior latência.

Ao mesmo tempo, a lógica de autenticação da Snowball Finance era complexa. Além dos protocolos OAuth2.0/JWT, muitos fatores precisavam ser considerados, como versões do cliente e múltiplos APPs sob a Snowball Finance. Além disso, o módulo de autenticação estava embutido no serviço, tornando a atualização mais difícil.

2. Funcionalidade Limitada do OpenResty

A Snowball Finance usava o OpenResty como seu gateway anteriormente, mas o OpenResty era fraco em algumas funcionalidades. Portanto, os desenvolvedores precisavam fazer mais personalizações ao integrar o OpenResty com seu sistema de monitoramento existente. Além disso, os engenheiros de DevOps precisavam adicionar scripts personalizados para implementar o processo de segunda-desenvolvimento.

3. Dependência do Centro de Registro Desenvolvido Internamente

Atualmente, a Snowball Finance realiza o registro de serviços HTTP solicitando ao Centro de Registro que o registre no gateway quando o serviço backend é iniciado e remova o nó de serviço quando o serviço é parado. O centro de registro periodicamente verifica a saúde dos nós de serviço. No entanto, em comparação com projetos de código aberto, o custo de manutenção de serviços desenvolvidos internamente é maior.

Seleção de Tecnologia de Gateway de API

Com base nos pontos de dificuldade revelados gradualmente em cenários práticos de negócios, a equipe de Infraestrutura da Snowball iniciou pesquisas sobre produtos de gateway.

A equipe internamente espera garantir a transparência dos negócios e minimizar mudanças sem introduzir muitas variáveis. A equipe também deseja resolver problemas de forma unificada no nível da infraestrutura e completar os serviços de autenticação dentro do data center local. Considerando o acima, a Snowball Finance decidiu mover o serviço de autenticação para o gateway de API.

A Snowball Finance espera que o novo gateway de API possa atender aos seguintes requisitos:

• Alto desempenho
• Forte escalabilidade
• Suporte a múltiplos protocolos
• Baixo custo para autenticação no gateway

Abaixo está uma lista detalhada de seleção de tecnologia de gateway de API entre OpenResty, Spring Gateway, Kong e APISIX.

Gateway	Vantagens	Desvantagens	Custo de O&M	Disponibilidade
OpenResty	Altamente personalizável e estável	Observabilidade fraca	Alto	Alta
Spring Gateway	Amigável ao desenvolvimento Java	o nível de desempenho não atende aos requisitos	Médio	Médio
Kong	Poderoso e rico em funções	Banco de dados PostgreSQL de ponto único	Baixo	Médio
APISIX	Nativo da nuvem, suporta múltiplas linguagens de programação e tem forte escalabilidade	/	Baixo	Alta

Após considerar as demandas internas e comparar produtos populares de gateway no mercado, a Snowball Finance finalmente escolheu o Apache APISIX para a arquitetura subsequente.

Prática Baseada no Apache APISIX

Arquitetura Ajustada

Como mostrado na figura acima, a arquitetura ativa-ativa atual dos serviços de mercado da Snowball é exibida à esquerda, que corresponde à arquitetura no data center original com poucas modificações. O lado direito mostra a arquitetura ativa-ativa baseada em um design multi-região após a migração para a nuvem.

A Snowball Finance fez principalmente os seguintes ajustes com base no APISIX:

• Unificou o módulo de autenticação para a camada de proxy e usou o APISIX para autenticação unificada. Para tipos JWT, o plugin jwt-auth do APISIX pode ser usado para autenticação local diretamente.
• Compatível com OAuth 2.0, e utilizou o APISIX para chamar o Centro de Usuários da Snowball Finance para processamento.
• Conectado ao centro de registro de serviços RPC backend da Snowball Finance para usar seus serviços backend para autenticação quando a autenticação JWT falha.

Cenários de Aplicação

Após o serviço backend ser conectado ao APISIX, algumas práticas foram principalmente realizadas nos aspectos de autenticação e observabilidade do gateway.

Cenário 1: Autenticação no Gateway

Como mencionado anteriormente, a arquitetura anterior da Snowball Finance não tinha um método de autenticação unificado. Um método dependia do lado interno do aplicativo, que usava um SDK para chamar o centro de usuários para autenticação, enquanto o outro usava autenticação JWT. Quando esses dois métodos de autenticação coexistiam, causavam problemas de escalabilidade e manutenção.

1. Após integrar o APISIX como um gateway, a Snowball Finance usou a camada de gateway do APISIX para gerenciar uniformemente a autenticação. O método de autenticação JWT original foi substituído pelo plugin oficial jwt-auth. Configurar e usar o plugin jwt-auth é relativamente simples: apenas configurando as informações relevantes, como rotas e upstream no Dashboard, o plugin será ativado.
2. A Snowball Finance usou o plugin grpc-transcode para proxy das chamadas de serviço de autenticação para lidar com o método de autenticação relacionado ao OAuth 2.0 anterior.

A Snowball Finance considerou internamente as seguintes três soluções para chamar gRPC para implementar a autenticação:

• Solução 1: Usar Lua para chamar gRPC diretamente. Como esta solução requer considerar implementações relacionadas, como balanceamento de carga e upstream dinâmico, o processo será mais complicado, então foi descartada.
• Solução 2: Usar corrotina Lua para chamar a lógica Golang de volta. A Snowball Finance abandonou essa maneira por falta de experiência prática correspondente.
• Solução 3: Usar Lua para fazer chamadas HTTP, e a interface gRPC é implementada usando o plugin grpc-transcode do APISIX. Graças às rápidas iterações de otimização de plugins da comunidade APISIX, a Snowball Finance finalmente escolheu esta opção para implementar chamadas gRPC.

Atualmente, é necessária a sincronização manual de arquivos de protocol buffer durante a execução. Isso ocorre porque, se o centro de usuários modificar o arquivo de protocol buffer, que não corresponde à versão salva pelo APISIX, pode resultar em problemas de autenticação.

Cenário 2: Monitoramento Multidimensional sob Observabilidade

É necessário monitorar muitas métricas após o lançamento dos sites na Snowball Finance, focando principalmente nas três partes a seguir:

• Status de conexão NGINX e tráfego de entrada/saída
• Taxa de código de status de erro HTTP (usada para solução de problemas de serviço ou upstream/downstream)
• Latência de solicitação do APISIX (o tempo consumido pela execução da lógica quando o APISIX encaminha a solicitação)

Por exemplo, em alguns casos, a latência do APISIX parece alta (como mostrado na figura abaixo), o que está relacionado à lógica de cálculo da latência. Atualmente, a lógica é o tempo consumido por uma única solicitação HTTP no NGINX menos a latência dessa solicitação roteada para o upstream. A diferença entre os dois tempos consumidos é a métrica de latência do APISIX.

Após usar o APISIX, adicionar ou modificar alguns plugins levará a algumas mudanças de lógica, o que pode levar a desvios nos dados relacionados à latência. Para evitar confundir a autenticidade dos dados, a Snowball Finance também adicionou um plugin de monitoramento de latência. Enquanto garante a precisão de cada monitoramento de dados, também é conveniente para localizar problemas antecipadamente, facilitando a solução de problemas.

Também é possível utilizar as capacidades de observabilidade do APISIX para coletar logs de acesso e entregá-los ao painel de tráfego de forma formatada e padronizada para visualização e resumo. Isso facilita a compreensão proativa das tendências gerais de múltiplas perspectivas, identificando possíveis problemas e resolvendo-os prontamente.

Cenário 3: Escalonamento do Registro ZooKeeper

Na Snowball Finance, as chamadas gRPC são registradas e descobertas com base no registro ZooKeeper. No processo de implementação de autenticação, quando a verificação JWT local falha, o gateway de API precisa acessar o serviço gRPC no Centro de Usuários da Snowball Finance para autenticação, o que requer que o gateway de API obtenha a lista de endereços de serviço gRPC backend do centro de registro.

O plugin oficial do APISIX apisix-seed pode integrar o ZooKeeper para descoberta de serviços. A Snowball Finance realizou algumas personalizações mais específicas para seus próprios negócios.

A implementação específica está principalmente em um nó de conteúdo do APISIX. Quando o processo Worker é iniciado, ele pesquisa o cluster ZK-Rest como o da figura abaixo, e então puxa regularmente os dados de origem e informações de todo o serviço, e os atualiza no cache local do processo Worker para atualizar as listas de serviços.

Também pode ser visto na figura acima que o cluster ZK-Rest acessa os dados do ZooKeeper na forma de Rest. Apenas adicionando uma instância dele pode alcançar recursos de alta disponibilidade, eliminando algumas operações complicadas. Mas esta operação também traz uma desvantagem mais óbvia. Ao pesquisar periodicamente o cluster ZK-Rest, pode causar um atraso na atualização da lista de serviços.

Resumo e Perspectivas

Atualmente, o Apache APISIX está funcionando bem como a camada de gateway dentro da Snowball Finance. Especificamente:

• Funções de autenticação unificada, circuit breaking e limitação de taxa são implementadas na camada do gateway, reduzindo o acoplamento do sistema geral e melhorando a qualidade do serviço sob data centers duplos.
• Com a ajuda do monitoramento do APISIX, uma solução de monitoramento unificada do gateway ao serviço é estabelecida, fornecendo bom suporte para solução de problemas globais.
• Uma abordagem de implementação elegante é fornecida para a conversão e gestão de serviços do protocolo gRPC.

No uso subsequente, a Snowball Finance também planeja:

• Aplicar o APISIX Ingress Controller ao cluster K8s.
• Usar o plugin grpc-transcode para conversão de protocolo HTTP/gRPC para alcançar uma interface backend unificada.
• Usar o plugin traffic-split para rotulagem de tráfego, conectando ao centro de registro Nacos e implementando lançamento canário e outras governanças de serviço.

Nos planos subsequentes, o Apache APISIX será usado para substituir o OpenResty existente e, finalmente, alcançar a gestão do tráfego norte-sul de ciclo de vida completo.