Desista do Spring Cloud Gateway! Como o Huanbei, um APP de Fintech, Utiliza o Apache APISIX

Amor e Ódio por Java

Por que os Sistemas Financeiros Preferem Java

Java sempre foi popular e preferido por muitos desenvolvedores desde seu lançamento devido às suas vantagens linguísticas e ao enorme ecossistema.

Nos últimos 15 a 20 anos, muitos sistemas financeiros escolheram Java como sua principal pilha tecnológica. Após algumas investigações, concluímos as seguintes vantagens do Java:

Devido às razões acima, Java ganha a preferência dos sistemas de software financeiro.

O Status Quo do Java na Era Cloud-Native

Com o rápido desenvolvimento da tecnologia, a indústria abandonará em breve a arquitetura monolítica, e os microsserviços e a cloud-native se tornarão o mainstream. No entanto, no ambiente tecnológico dos últimos anos, Java começou a perder seu papel dominante em alguns cenários de negócios.

Primeiro, Java tem um desempenho fraco; você entenderia por que estou dizendo isso comparando Java com a pilha tecnológica relacionada ao C.

Segundo, Java roda em máquinas virtuais, e as máquinas virtuais cuidam do gerenciamento de memória do Java. Portanto, Java se torna menos competitivo quando há necessidade de alto desempenho ou mudanças dinâmicas.

Além disso, Java precisa de muito mais recursos. Um framework é fácil de construir sem se preocupar com o custo. No entanto, como os cálculos se tornaram muito mais detalhados e granulares na era cloud-native, os recursos se tornaram mais preciosos do que nunca. Além disso, Java custaria enormes recursos para rodar porque é pesado e precisa ser reiniciado de tempos em tempos. Como resultado, Java teria problemas com uma alta demanda por QPS e continuidade dos negócios.

Por último, mas não menos importante, a questão do ponteiro também vale a pena discutir. O ponteiro é um bom recurso para desenvolvedores familiarizados com C/C++. No entanto, Java está rodando em uma máquina virtual, o que significa que o gerenciamento de memória é tratado pelo GC (Garbage Collection) em vez dos desenvolvedores. Nesse caso, o desempenho do Java pode não ser suficiente para algumas circunstâncias quando há uma demanda estrita por alta concorrência, tráfego e desempenho.

Por que o HuanBei Escolheu o APISIX

Shuhe Group é uma plataforma de tecnologia financeira que fornece serviços eficientes e inteligentes para empresas e indivíduos nos negócios; possui produtos como HuanBei, EnjoyPay, etc. HuanBei é uma plataforma que oferece um serviço de parcelamento que atende a múltiplas cenas de consumo. Ao trabalhar com instituições financeiras licenciadas, HuanBei também fornece serviços de empréstimo pessoal e oferece fundos de empréstimo para startups. HuanBei sempre usa uma pilha tecnológica Java para desenvolver seus produtos nos negócios.

Spring Cloud Gateway é um gateway que visa gerenciar melhor os microsserviços no ecossistema Spring Cloud. Spring Cloud Gateway é um gateway API decente para empresas que usam Java como sua principal linguagem de desenvolvimento. No entanto, na recente atualização do gateway API, HuanBei abandonou o Spring Cloud Gateway, usado há muito tempo, e começou a usar Apache APISIX.

Diferenças Arquiteturais Entre Spring Cloud Gateway e APISIX

HuanBei usou três sistemas diferentes de gateway API antes de adotar o APISIX. HuanBei usou Spring Cloud Gateway como gateway de sistemas de operação e saída e OpenResty como gateway de sistemas de negócios.

HuanBei usou Spring Cloud Gateway como gateway de sistemas de operação e saída inicialmente devido ao enorme ecossistema do Spring Cloud Gateway e ao sistema de desenvolvimento distribuído fácil de implantar e manter. Para construir rapidamente modelos de negócios, HuanBei usou todos os serviços fornecidos pelo Spring Cloud quando a base de negócios foi construída.

Com o desenvolvimento dos negócios, o gateway começou a ter alguns problemas de estabilidade na arquitetura original, como estouro de memória, alto uso de CPU, etc. Portanto, HuanBei usa o Apache APISIX como o único gateway na arquitetura para melhorar o desempenho do gateway e gerenciar uniformemente vários gateways.

No novo framework de gateway, o gateway transferiria diretamente o tráfego de solicitações para o sistema de negócios via descoberta de serviços. No entanto, se o aplicativo de backend não suportar a descoberta de serviços ou não tiver um Pod saudável no Consul, o sistema redirecionará o tráfego para o K8s Ingress da intranet anterior.

A Aplicação Prática do APISIX

Huanbei teve que modificar a configuração do APISIX em cenários reais de negócios, pois não podia usar o Apache APISIX diretamente devido aos seus múltiplos frameworks de gateway internos.

Construção e Implantação do APISIX

Durante o desenvolvimento interno, HuanBei colocou os códigos-fonte do gateway APISIX e os códigos personalizados em diferentes caminhos de rota e os fez cooperar e iterar independentemente. HuanBei usou uma imagem Docker para implantar o gateway. Primeiro, criaria uma imagem padrão com base em uma versão específica do APISIX e, em seguida, usou códigos personalizados para envolvê-la em uma nova imagem.

O envolvimento dos códigos personalizados não usou lua_package_path para especificar o diretório do código; em vez disso, cobriu diretamente a imagem padrão apisix no diretório de códigos-fonte se houvesse um arquivo com o mesmo nome. O Dockerfile é mostrado abaixo:

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

O log do APISIX é armazenado localmente (pode ser coletado por Syslog ou outros plugins); poderíamos modificar o modelo de configuração do NGINX e verificar o Profile usado para decidir se queremos armazenar os logs localmente ou armazená-los no FLUENTD através do Syslog. Também precisamos substituir a variável FLUENTD_HOST ao construir as imagens mostradas abaixo:

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

No modelo de configuração do NGINX, HuanBei não apenas modificou o armazenamento de logs, mas também adicionou variáveis de ambiente ENV e configurou lua_shared_dicts em loops e corrigiu alguns parâmetros de otimização do NGINX.

HuanBei separa o tráfego com base em diferentes necessidades de negócios e cria vários gateways com funcionalidades semelhantes. Portanto, HuanBei usa um plano de "único código-fonte, mas múltiplas aplicações de gateway" internamente. Primeiro, HuanBei configura o arquivo config-xxx.yaml de cada gateway usando a função Profile e, em seguida, pode construir diferentes imagens Docker do gateway com base no nome da aplicação ao construir as imagens através da plataforma DevOps.

Plugins Personalizados de Nível Empresarial

Ao visitar o sistema de operação internamente, o sistema chamaria muitas APIs de backend para buscar dados, e essas APIs precisam ser incluídas na lista branca da configuração do gateway API. O sistema de permissões deve manter uma lista de APIs relacionadas, pois a página ofereceria diferentes intervalos de API com base no papel de cada usuário logado no sistema de operação. Sempre que há uma nova chamada de API da página, os desenvolvedores precisam adicionar configurações duas vezes no gateway e no sistema de permissões, o que é redundante e repetitivo.

Para alcançar isso, HuanBei remove a barreira entre a configuração do gateway e a configuração do sistema de permissões, mantendo apenas a entrada do sistema de permissões. O sistema de gerenciamento de configuração do gateway buscaria a API de permissões periodicamente e a converteria na configuração da lista branca de APIs do gateway. Esse comportamento omitiria uma ação de configuração desnecessária e ajudaria o sistema de permissões a fazer o controle de permissões. Além disso, garante que a API de backend chamada na página de operação exista na configuração do sistema de permissões.

Em cenários de negócios, sempre há algumas necessidades que os plugins nativos não podem satisfazer, o que requer desenvolvimento personalizado. O APISIX fornece muitas ferramentas que podem ajudar a personalizar os plugins nativos facilmente. A tabela a seguir lista alguns plugins personalizados desenvolvidos com base no APISIX dentro do HuanBei:

Lançamento Canário do Gateway

Anteriormente, HuanBei usou OpenShift como seus contêineres K8s (atualmente atualizado para o cluster ACK), e o Ingress foi construído com Haproxy.

Devido ao fato de que o Haproxy do Ingress K8s da rede pública não poderia dividir o tráfego de um único domínio em dois caminhos de rota de Namespace diferentes, precisamos considerar a implantação do novo gateway no mesmo Namespace em vez do gateway antigo. Em outras palavras, cada caminho de rota de domínio teria vários serviços, e poderíamos controlar o tráfego do novo e do antigo gateway atribuindo diferentes porções do tráfego total.

O fluxo de implementação real é mostrado abaixo, ele adicionaria grupos c e d para implantar um novo gateway sob o Namespace do gateway antigo, e poderia controlar a proporção de tráfego dos gateways novo e antigo.

Fatores do Gateway Relacionados ao Java

Muitos desenvolvedores Java escolheriam Spring Cloud na arquitetura de microsserviços, pois o Spring Cloud pode suportar Java perfeitamente e incorpora bibliotecas de classes nos códigos-fonte. No entanto, situações difíceis de atualização aparecem na prática. Por exemplo, se a equipe precisar manter várias bibliotecas de classes, e houver 10 linguagens diferentes com 10 versões diferentes, então essa equipe precisará manter 100 bibliotecas de classes diferentes.

Agora, podemos facilmente usar um proxy (gateway API) para resolver problemas de múltiplas versões e múltiplas linguagens. Então, quais são os benefícios para empresas que usam uma pilha tecnológica Java e escolhem o APISIX como seu gateway API? Concluímos com base em dois aspectos da experiência prática do HuanBei.

Para a Empresa

1. Ótima Funcionalidade e Desempenho

O QPS do APISIX pode atingir 80k se HuanBei usar máquinas virtuais de 4 núcleos sem nenhum plugin para testar o APISIX. Além disso, o APISIX resolve perfeitamente o problema de desempenho do Spring Cloud Gateway ao receber o tráfego do consumidor, e seu desempenho melhora em 30% no ambiente de produção em comparação com os gateways anteriores.

Além disso, o APISIX pode atender a todos os requisitos da empresa sob testes reais, como autenticação e identificação, observabilidade, descoberta de serviços, limitação de taxa e transferência de tráfego de camada quatro e sete. Em relação à extensão de recursos, o APISIX suporta mais de 70 plugins, e a maioria dos negócios pode usar seus plugins nativos, o que reduz uma quantidade tremenda de trabalho de desenvolvimento.

2. Reduzir Custos de Negócios

Antes de usar o APISIX, as empresas precisavam aumentar o número de servidores para resolver problemas de desempenho, aumentando significativamente os custos de hardware.

HuanBei calculou o custo e descobriu que o custo dos servidores reduziu em cerca de 60% após o uso do APISIX. Além disso, após unir a pilha tecnológica, o negócio pode estender diferentes recursos rapidamente com base na arquitetura nativa do APISIX, reduzir despesas de desenvolvimento e acelerar o tempo de lançamento do produto.

Para Desenvolvedores

1. Atender às Necessidades do Negócio

Todo software ou tecnologia usada no negócio deve servir às necessidades. No entanto, a partir dos resultados práticos de teste e pesquisa, o APISIX tem melhor estabilidade, observabilidade e extensibilidade.

O software visa servir o negócio. Portanto, se um requisito de negócio puder ajudar a empresa a economizar recursos, independentemente da pilha tecnológica que a empresa usa, ela também deve usar os componentes que correspondem à empresa.

2. Reduzir Custos de Manutenção

Comparado ao OpenResty anteriormente usado, o APISIX tem um custo de aprendizado mais baixo e é mais fácil de manter. Enquanto isso, os ricos plugins do APISIX simplificam a implantação e o desenvolvimento de alguns recursos padrão, reduzindo o tempo de lançamento do produto.

Além disso, os poderosos logs e o recurso de depuração dinâmica do APISIX ajudam a detectar os pontos de falha no negócio, para que possamos localizar rapidamente o erro e economizar tempo.

Conclusão: Tendências do Desenvolvimento da Indústria Financeira

No estágio de crescimento brutal, a única coisa que importa é a eficiência. Portanto, o diretor preferiria sua linguagem familiar para construir o sistema e escolher diferentes pilhas tecnológicas durante as seleções de framework de baixo nível para lançar os modelos de negócios mais rapidamente. Diferentes diretores escolheriam outras pilhas tecnológicas, o que causaria muitos problemas futuros. No entanto, a maioria das empresas financeiras ativas e empresas de serviços financeiros enfrentariam o mesmo problema técnico: o problema de múltiplas pilhas tecnológicas. Quando esse problema ocorre, eles precisam combinar suas pilhas tecnológicas em uma.

Quando o negócio da empresa está no caminho certo, é hora de a empresa dividir seu sistema verticalmente. A empresa precisa transformar sua arquitetura de silo de informação em uma arquitetura de três camadas consistindo de front-end, middle-end e back-end. Então, quando o sistema opera de forma estável, é hora de as empresas implementarem componentes de baixo nível por si mesmas.

O objetivo final de construir um sistema é compartilhar. O sistema tem menores custos de manutenção se tiver maior repetibilidade. Portanto, quando a operação do negócio se estabiliza, muitas empresas começam a divisão vertical ou a implementação de componentes fundamentais de baixo nível para controlar os custos de manutenção.

Para as empresas, o custo é sempre o princípio mais importante a considerar. No estágio de crescimento brutal, as empresas só precisam lançar e deixar os negócios operarem o mais rápido possível. Ainda assim, o custo deve ter a maior prioridade sob o orçamento neste grande ambiente. Nesse caso, temos que escolher entre eficiência e custo. Portanto, as empresas não usariam tecnologia de ponta se o orçamento fosse limitado. Da mesma forma, a equipe técnica não consideraria as seguintes questões ao escolher a pilha tecnológica: Como essa nova tecnologia afetaria a equipe? Quantos benefícios essa nova tecnologia traria para a infraestrutura atual?

A equipe técnica consideraria apenas o custo dessa nova tecnologia.