## Contexto

Nos últimos anos, muitos softwares de conferência online conhecidos surgiram com o desenvolvimento de reuniões online e trabalho remoto. O Zoom, um exemplo típico, tornou-se uma ferramenta popular para home office, ensino online e cenários sociais. Ele possui 350 milhões de participantes diários em reuniões e quase 470.000 clientes empresariais pagantes usando a plataforma. Além disso, dados recentes mostram que a quantidade de minutos usados para facilitar reuniões atingiu mais de 3,3 trilhões por ano.

No entanto, como outras empresas de SaaS e internet, o Zoom enfrentou desafios técnicos à medida que seu negócio se expande rapidamente.

- **Um número significativo de microsserviços**: Devido ao rápido crescimento dos negócios e das equipes do Zoom, mais de 100 serviços de backend precisam ser entregues. No entanto, é difícil gerenciar um grande número de microsserviços de forma eficiente.

- **Diversos ambientes de implantação**: Empresas de SaaS frequentemente encontram cenários em que os clientes precisam implantar em nuvens dedicadas, nuvens privadas e multi-nuvens. Como os serviços de negócios do Zoom estão espalhados pelo mundo, há desafios técnicos com um grande número de ambientes de nuvem híbrida.

- **Infraestrutura complexa**: Empresas de internet de médio e grande porte geralmente têm equipes de infraestrutura dedicadas responsáveis por gateways de API, centros de configuração, gerenciamento de chaves, logs, monitoramento de alarmes, bancos de dados, etc.
Como as equipes de P&D do Zoom estão distribuídas globalmente, é um grande desafio integrar esses middlewares e infraestruturas complexas no pipeline de entrega contínua.

**Os desafios acima não são uma relação simples de adição, mas uma relação multiplicativa. Em outras palavras, a situação real é muito mais complexa.** No entanto, as ferramentas de código aberto que o Zoom usava anteriormente não atendem mais aos requisitos atuais. É por isso que um pipeline de entrega contínua confiável é tão importante.

Abaixo estão os motivos detalhados pelos quais o Zoom não continuou a escolher essas ferramentas de código aberto anteriores.

| Helm/Kustomize  | Terraform/Pulumi  | KubeVela + Crossplane  |
| ------------ | ------------ | ------------ |
| Incapaz de conectar sistemas além do Kubernetes  | Difícil usar o Terraform nas camadas do Kubernetes e middleware, a menos que sejam desenvolvidos Providers extras  | Tecnologia muito nova com atualizações rápidas, não segura e estável o suficiente para ser adotada em ambiente de produção  |
| Difícil controlar centralmente a plataforma no modo de sub-repositório Git  | Aumenta o custo de aprender outra linguagem de gerenciamento de configuração: hcl  | A definição de Trait + templates Cuelang do Kubevela e suas capacidades de expressão de programação não são suficientes para cobrir várias plataformas de middleware não nativas da nuvem fora do sistema Kubernetes  |
| Difícil de manter e depurar devido à lógica complexa do Helm Chart Template  | O modo de controle centralizado Mono Repo não é adequado para equipes grandes  | /  |
| Sistema de parâmetros não poderoso o suficiente para gerenciar parâmetros dinâmicos em um grande número de ambientes  | /  | /  |

Devido às limitações das ferramentas de código aberto mencionadas acima, o Zoom finalmente investigou algumas soluções principais para construir o pipeline de entrega contínua subjacente.

Após algumas rodadas de comparação e verificação, o Zoom acabou escolhendo o APISIX Ingress Controller para suportar seu novo pipeline de entrega contínua.

## Apache APISIX Ingress Controller

### O que é o Apache APISIX Ingress Controller?

[Apache APISIX Ingress Controller](https://github.com/apache/apisix-ingress-controller) é um controlador de entrada (ingress) nativo da nuvem que usa o Apache APISIX como o plano de dados para transportar o tráfego e estende a funcionalidade do Kubernetes utilizando CRD (CustomResourceDefinition). Ele é responsável por interagir com o servidor de API do Kubernetes, aplicar controle de acesso baseado em função (RBAC), monitorar mudanças, implementar conversão de objetos dentro do controlador de entrada, comparar as mudanças e, em seguida, sincronizar com o Apache APISIX. Além disso, ele pode suportar recursos personalizados, incluindo APISIX Route, APISIX Upstream e outros ingressos nativos do Kubernetes, para controlar o tráfego externo que acessa serviços implantados no Kubernetes.

Abaixo está o [Diagrama de Tempo do APISIX Ingress Controller](https://apisix.apache.org/docs/ingress-controller/design/#timing-diagram).

![Diagrama de Tempo do APISIX Ingress](https://static.api7.ai/2022/10/27/635a5613af56a.jpeg)

## Por que o Zoom escolheu o APISIX Ingress Controller?

De acordo com o contexto acima, surge a pergunta: que tipo de pipeline de entrega contínua o Zoom deseja construir, e como ele adota o APISIX Ingress para estabelecer seu pipeline de entrega contínua subjacente?

O Zoom anteriormente usava o NGINX como um gateway de API. No entanto, com o rápido desenvolvimento dos negócios e o aumento dos microsserviços, as limitações da solução atual do NGINX estão se tornando mais evidentes.

Diferentes equipes precisam manter o NGINX separadamente, e milhares de linhas de arquivos de configuração do NGINX tornam a manutenção difícil. Além disso, o NGINX não pode escalar rapidamente ao implantar muitas linhas no servidor em nuvem. Sobre o modo de recarregamento do NGINX, você pode verificar [este blog](https://api7.ai/blog/how-nginx-reload-work). Os negócios do Zoom começaram a evoluir em direção ao Ingress Controller.

A equipe do Gateway de API pesquisou algumas soluções de código aberto. Após simular a migração e análise da configuração real do negócio no NGINX e uma grande quantidade de testes de benchmark de desempenho e comparação do ecossistema de plugins, o Zoom finalmente escolheu o projeto APISIX Ingress Controller da Apache Software Foundation, explorando um gateway mais avançado nativo da nuvem.

Considerando seus cenários de negócios, o Zoom deu mais ênfase às duas partes abaixo, que podem ser satisfeitas pelo APISIX Ingress.

- **Segurança dos Dados**: O Zoom leva a privacidade do cliente e a segurança do serviço a sério; portanto, a autenticação e verificação mTLS são amplamente usadas em salas de reunião online e chamadas telefônicas. No entanto, muitos gateways de API semelhantes só podem fornecer esse serviço em sua versão empresarial, enquanto o APISIX Ingress oferece grande viabilidade e conveniência para alcançar esse objetivo.

- **Estabilidade do Serviço**: Os serviços de backend do Zoom exigem implantações Multi-AZ (Multi-Availability Zones) para alta disponibilidade em diferentes regiões. Geralmente, ele coloca os negócios em outro DC. Se ocorrer um erro no DC original, o tráfego do cliente precisa ser transformado para outro, no qual o APISIX Ingress pode atender com sucesso ao requisito.

### Recursos do Apache APISIX Ingress Controller

Usando o Apache APISIX como seu plano de dados para transportar o tráfego de negócios, o Apache APISIX Ingress Controller herda as seguintes vantagens do Apache APISIX.

- **Alto Desempenho e Estabilidade**: Como um gateway de API dinâmico de alto desempenho e código aberto, o Apache APISIX é resiliente e estável em seu desempenho, sendo usado em muitos [cenários de tráfego em larga escala de empresas](https://apisix.apache.org/blog/tags/case-studies/).

- **Comunidade Ativa**: Como um projeto de gateway de API de código aberto de nível superior e mais ativo, o Apache APISIX possui uma comunidade ativa e manteve uma excelente taxa de crescimento desde o primeiro dia.

- **Ecossistema Rico**: O Apache APISIX suporta protocolos L7, incluindo HTTP(S), HTTP2, Dubbo, protocolo IoT MQTT, etc. Além disso, o APISIX suporta protocolos L4 como TCP/UDP. Além disso, o suporte completo ao ARM64 é suportado no Apache APISIX 3.0.

- **Múltiplos Plugins**: Existem quase 100 plugins lançados oficialmente pelo APISIX que os usuários podem usar com um simples arrastar. O recarregamento dinâmico e a orquestração de plugins oferecem grande conveniência aos usuários.

Além disso, o APISIX Ingress Controller também possui as seguintes vantagens únicas:

- **Boa Compatibilidade**: O APISIX Ingress Controller suporta várias versões de recursos de entrada e pode ser compatível com diferentes versões do Kubernetes.

- **Atualização Dinâmica**: Não é necessário recarregar o serviço ao modificar rotas, certificados e outras configurações, garantindo a operação suave do negócio.

- **Escalabilidade Flexível**: Como o APISIX Ingress Controller adota uma estrutura que separa o plano de controle e o plano de dados, o cluster de plano de dados do Apache APISIX pode ser expandido independentemente sem escalar o APISIX Ingress Controller.

![Arquitetura do APISIX Ingress Controller](https://static.api7.ai/2022/10/27/635a56148940c.jpeg)

- **Amigável para Operação e Manutenção**: Na arquitetura atual, os usuários podem escolher implantar o cluster de plano de dados APISIX no cluster Kubernetes ou no ambiente de máquina física bare-metal, de acordo com a situação real. Além disso, devido à separação arquitetônica do APISIX ingress, o APISIX no plano de dados transporta o tráfego enquanto o APISIX ingress controller é o componente do plano de controle. Portanto, a falha do APISIX Ingress Controller não impactará o tráfego de negócios.

Após a seleção do gateway, a equipe do Gateway de API enfrentou um novo desafio: como migrar a configuração original do gateway de API de centenas de serviços para o APISIX Ingress? A equipe de Infraestrutura do Zoom estava desenvolvendo o pipeline de entrega contínua, o que pode reduzir significativamente o custo de migração da conversão de nginx.conf e outras configurações de Ingress para o APISIX Ingress.

## O Processo e as Funções da Construção do Pipeline de Entrega Contínua

### Pipeline de Entrega Contínua do Zoom

O pipeline de entrega contínua é um sistema de entrega de aplicativos de ponta a ponta que implementa um único modelo para declarar todos os requisitos de entrega de aplicativos e organizar e executar todas as etapas de entrega contínua em uma linha.

![Pipeline de Entrega Contínua do Zoom](https://static.api7.ai/2022/10/27/635a56149b270.jpg)

Há seis partes no pipeline de entrega contínua:

1. **Preparar**: preparar recursos predefinidos, incluindo infraestrutura, middleware, recursos de serviço em nuvem, etc.;

2. **Configurar**: preparar os arquivos de configuração e chaves necessários para o aplicativo;

3. **Implantar**: usar o K8s para implantação em cenários nativos da nuvem (incluindo informações sobre contêineres, imagens de contêineres, parâmetros, versões e instâncias);

4. **Acessar**: criar um Kubernetes Service e configurar automaticamente as regras de roteamento do Apache APISIX Ingress se a implantação exigir acesso externo;

5. **Observar**: Realizar configurações relacionadas à observabilidade, como monitoramento, alarmes, logs e análise de rastreamento;

6. **Escalar**: Declarar as regras de escalonamento dinâmico do KEDA (Kubernetes Event-driven Autoscaling) por meio de métricas de monitoramento.

### Como Adotar o APISIX Ingress no Pipeline

![Visão Geral da Arquitetura do Pipeline do Zoom](https://static.api7.ai/2022/10/27/635a5616254ed.jpg)

**Gerenciamento de Projetos**

Os Gerentes de Projetos se preocupam mais com as iterações de P&D e como gerenciar melhor o progresso de lançamento iterativo e a eficiência do pessoal na linha do tempo correspondente às iterações. O Zoom usa um fluxo de trabalho GitOps internamente para integrar a configuração do Gateway de API ao modelo de entrega de aplicativos. Sob esse modelo, a definição das regras de roteamento do APISIX é integrada com "Implantar" e outros links, entregando o controle de mudanças ao GitHub. Com a criação e mesclagem de branches do GitHub, o pipeline realiza linhas do tempo consistentes entre o lançamento e o rollback da configuração do aplicativo e do gateway.

```yaml
# Trecho de Código do Pipeline de CD do Zoom no Repositório Git
deploy:
  type: Deployment
  replicas: ~{ replicas, 2 }
  version: "latest"
  containers:
    - name: my-app
      image: "busybox"
      command: "echo 'Demo' && sleep 99d"
access:
  - protocol: https
    host: my-domain.my-org.com
    cert: my-tls-cert
    apisix:
      routes:
        http:
          - name: my-api
            authentication:
              # ......
            match:
              paths:
                - /my-api/*
```

Dessa forma, simplifica o gerenciamento de lançamentos em gerenciamento de fluxo de trabalho dentro do GitHub e resolve o problema do descompasso de tempo entre sistemas upstream e downstream ao corresponder mudanças quando múltiplas iterações são processadas simultaneamente.

**Desenvolvimento de Aplicativos**

Os desenvolvedores se concentram principalmente nas capacidades de roteamento e autenticação das APIs, que estão fortemente relacionadas aos serviços de negócios e devem ser preenchidas pelos desenvolvedores para alcançar o efeito automático. Além disso, eles se preocupam com o desenvolvimento e implementação de funções de negócios e o nível superior do negócio, esperando construir uma infraestrutura pronta para uso.

A partir dos códigos mencionados acima, podemos ver que os desenvolvedores só precisam definir `Authentication` e `Match` neste pipeline de entrega contínua. Eles não precisam saber a lógica subjacente:

- Primeiro, traduzir isso em Kubernetes Deployment e Service.
- Em seguida, chamar a API da plataforma para verificar a correção do caminho.
- Por fim, traduzir isso em objetos ApisixRoute.

Integrar a configuração do APISIX e o fluxo de trabalho do pipeline de entrega contínua oferece aos desenvolvedores uma maneira mais eficiente.

**Gerenciamento de Ambiente**

Requisitos complexos de gerenciamento e controle de ambiente frequentemente ocorrem em cenários toB, e questões de entrega em alguns cenários de nuvem privada, nuvem dedicada e nuvem híbrida devem ser consideradas.

Algumas configurações do APISIX ingress foram implementadas para atender ao requisito de ocultar diferenças ambientais. Dessa forma, os gerentes de sistema podem controlar de forma abrangente as diferenças em alguns ambientes heterogêneos. Todos os serviços implantados no ambiente são eficazes, evitando o fardo cognitivo e operações de implantação especiais causadas por diferenças ambientais para desenvolvedores de aplicativos e operações. Por exemplo, o Zoom pode usar configuração personalizada para desativar o rastreamento para alguns ambientes, converter objetos ApisixRoute em objetos Ingress nativos e Anotações do NGINX Ingress, e usar diferentes imagens para puxar segredos.

Além disso, o isolamento de múltiplos inquilinos é necessário quando várias linhas de negócios estão usando o ambiente APISIX. **O APISIX Ingress fornece um seletor de Anotação** que permite que diferentes objetos ApisixRoute sejam capturados por diferentes instâncias do APISIX Ingress Controller.

**Gerenciamento de Infraestrutura**

A equipe do Gateway de API precisa controlar todas as instâncias do APISIX, configurar políticas de segurança de forma abrangente, implementar múltiplas zonas de disponibilidade, e assim por diante.

Cada plugin do pipeline fornece itens de configuração para engenheiros de infraestrutura. No plugin `ingress-apisix`, há uma propriedade `defaultPlugins`.

Após a equipe do gateway de API configurar a propriedade, a configuração entrará em vigor para todos os serviços, o que é adequado para uma estratégia unificada de segurança e controle de riscos.

## Conclusão

O APISIX Ingress Controller desempenha um papel importante no pipeline de entrega contínua do Zoom, aliviando a pressão no gerenciamento de projetos, desenvolvimento de aplicativos, gerenciamento de ambiente e gerenciamento de middleware e infraestrutura. O caso do Zoom vale a pena ser estudado por outras empresas, e esperamos que o APISIX Ingress Controller contribua para a inovação de mais empresas.

Além disso, o Apache APISIX Ingress lançou oficialmente a versão V1.5 em agosto de 2022, que unifica a proposta de todas as versões de API de recursos e atualiza todas as versões de API de CRD para V2. Ao mesmo tempo, ele suporta a maioria dos recursos da API Gateway. O Apache APISIX Ingress permitiu que recursos de Ingress usassem plugins arbitrários do APISIX ao adicionar uma nova Anotação “k8s.apisix.apache.org/plugin-config-name” aos recursos de Ingress. Dessa forma, aumentará significativamente a facilidade de uso do APISIX Ingress Controller e reduzirá o custo para os usuários migrarem de outros Controladores de Ingress para o APISIX Ingress Controller.

Para mais informações, consulte [Apache APISIX Ingress V1.5](https://apisix.apache.org/blog/2022/08/05/apisix-ingress-1.5rc1-release/).


A Zoom integra o APISIX Ingress Controller em seu pipeline de entrega contínua para realizar a gestão geral de projetos, aplicações, ambientes e infraestrutura.

Como o Zoom usa o APISIX Ingress em seu pipeline de entrega contínua?

## Visão Geral

Desde maio de 2021, a [vivo](https://www.vivo.com/en) introduziu o [Apache APISIX](https://apisix.apache.org/) como seu API Gateway. Após mais de um ano de prática na vivo, o APISIX resolveu muitos pontos problemáticos técnicos e de negócios e foi utilizado em larga escala.

### Pontos Problemáticos Antes de Usar o APISIX

- **Gerenciamento Complexo de Cenários de Negócios e Manutenção do Sistema**

    Devido ao rápido crescimento dos negócios, há diversos cenários e sistemas que os atendem, e a vivo precisava de uma maneira unificada para gerenciá-los.

- **Interação entre o Plano de Dados e o Plano de Controle**

    Para empresas de médio e grande porte como a vivo, é inesperado que pequenos problemas que ocorrem no plano de dados afetem o plano de controle.

- **Sem Suporte para Recursos Multidimensionais**

    Projetos diversos levam a vários domínios e URLs. O departamento de negócios precisa pesquisar de acordo com diferentes dimensões de recursos.

- **Impacto Incontrolável de Problemas**

    Como os projetos da vivo são complexos, o efeito dos problemas encontrados é incontrolável. O uso de alguns plugins complicados intensifica isso.

Ao substituir o NGINX pelo APISIX, a vivo finalmente obteve uma série de conquistas, conforme descrito abaixo.

### Conquistas Após Usar o APISIX

- **Alta Disponibilidade**

    Nenhuma falha grave ocorreu desde que o APISIX foi lançado na vivo, e a disponibilidade do sistema excede **99,99%**.

- **Alto Desempenho**

    Suportando um tráfego online significativo e atendendo a um grande número de serviços, o tráfego de encaminhamento online atual chega perto de **um milhão de QPS** (Queries-per-second).

- **Recursos Abundantes**

    Graças aos [recursos ricos](https://apisix.apache.org/blog/2022/11/02/apache-apisix-v3-preview/) do APISIX, ele pode cobrir quase todos os cenários comuns de proxy do NGINX. Cerca de 50% dos projetos da vivo foram migrados do NGINX para os clusters do APISIX.

- **Apoiando a Construção e Desenvolvimento de Cloud-Native**

    O K8s bare metal que suporta a containerização atingiu uma escala de **10.000**. Cerca de 40% dos projetos foram migrados de bare metal e máquinas virtuais para a plataforma de contêineres K8s, apoiando e promovendo o progresso da containerização da vivo.

## Design do Sistema da Vivo Baseado no APISIX

A seguir, vamos ver o design do sistema da vivo após a adoção do APISIX.

### Exibição da Arquitetura Personalizada no APISIX

![Arquitetura do gateway de API da vivo com APISIX](https://static.api7.ai/2022/11/23/637dc2f51318e.jpg)

A partir do diagrama acima, podemos analisar que a vivo:

- Concluiu a construção de gateways de tráfego de **Camada 4** e **Camada 7**, que são suportados pelo APISIX
- Realizou o acesso ao tráfego e a implantação mista de bare metal, máquinas virtuais e contêineres
- Implementou o gerenciamento de clusters do APISIX
- Conectou a plataforma interna de DevOps e os serviços de implantação de negócios para acessar o tráfego de forma rápida e automática
- Melhorou a construção de monitoramento

### Melhorias no Gerenciamento de Configuração e Lançamento

Para atender melhor às necessidades reais do departamento de negócios, a vivo realizou uma série de adaptações no APISIX. Abaixo estão algumas dessas adaptações, incluindo alterações no plano de controle, gerenciamento de separação de clusters e encaminhamento de dados.

#### Alteração no Plano de Controle

O processo completo pode ser o seguinte:

Após a configuração dos dados na plataforma de alterações A6, as informações serão entregues via RPC notify ao ManagerAPI, que foi construído pela vivo com base no [APISIX Dashboard](https://github.com/apache/apisix-dashboard) de código aberto.

Em seguida, o tráfego será enviado para o `apisix-agent`. O APISIX consulta o apisix-agent regularmente através do processo privilegiado para obter tarefas de alteração em lote. Em seguida, o processo privilegiado notifica o `worker` através de filas compartilhadas para realizar a alteração na memória.

Enquanto isso, o APISIX informa o `apisix-agent` sobre o resultado das tarefas e, em seguida, as entrega ao ManagerAPI. Além disso, a plataforma de alterações A6 pode consultar o ManagerAPI para obter os resultados das tarefas.

![Modo de gerenciamento e publicação da vivo](https://static.api7.ai/2022/11/25/638036da44e7f.jpeg)

O [etcd](https://etcd.io/docs/v3.5/learning/why/#comparison-chart "etcd") é um destaque do APISIX, permitindo a operação independente dos planos de controle e dados. Considerando a singularidade de sua arquitetura, a vivo descartou o etcd no processo acima. Aqui estão algumas razões.

Devido à diversidade dos projetos da vivo, há vários domínios e URLs. Além disso, os departamentos de negócios precisam consultar diferentes dimensões. Graças à adaptabilidade do APISIX, que não funciona apenas com etcd, mas também com diversos tipos de bancos de dados, a vivo pôde facilmente utilizar bancos de dados como o MongoDB para trabalhar em conjunto com o APISIX.

Além disso, a vivo fez as seguintes contribuições para ser compatível com o Apache APISIX.

- **Desenvolvimento do Componente Agent**

    Desde maio de 2021, a vivo introduziu o Apache APISIX. Considerando o contexto técnico, a vivo não estava confiante em adotar o APISIX porque não tinha experiência com OpenResty e Lua. Além disso, há muitas tarefas não relacionadas ao encaminhamento, como coleta de logs e manipulação de monitoramento, o que pode aumentar a complexidade de gerenciamento do plano de dados. Consequentemente, a vivo desenvolveu o componente agent para reduzir a complexidade do desenvolvimento.

- **Gravação de Dados no Disco**

    Para tornar o sistema ajustável e permitir que o plano de dados funcione de forma independente, reduzindo assim a dependência do plano de controle, a vivo escreveu o arquivo de configuração no disco. Quando o APISIX é iniciado, ele suporta a obtenção completa do centro de configuração e também suporta a obtenção direta de recursos de configuração do diretório de arquivos do disco local. Essa maneira melhora drasticamente a independência dos dados e a robustez do sistema. Além disso, é muito intuitivo entender as informações de rota e upstream configuradas no disco, o que é útil para solucionar problemas.

- **Retorno do Resultado da Tarefa de Alteração**

    Como uma empresa de grande porte, a vivo precisa garantir que as alterações em recursos como roteadores e upstreams possam ser efetivas e bem-sucedidas, e que o sistema possa relatar o erro mesmo que essas alterações falhem. Essa lógica de ACK (Código de Confirmação) garante que os workers do NGINX em uma máquina possam retornar. Quando as tarefas de retorno são bem-sucedidas, todos os workers do APISIX atualizarão as alterações de recursos para a memória relevante.

#### Gerenciamento de Separação de Clusters

![Gerenciamento de Separação de Clusters](https://static.api7.ai/2022/11/25/6380381595b00.jpeg)

A versão de código aberto do APISIX fornece [etcd](https://apisix.apache.org/docs/apisix/FAQ/#why-does-apache-apisix-use-etcd-for-the-configuration-center) para todos compartilharem. No entanto, os projetos da empresa são complexos, e os problemas encontrados são incontroláveis. Além disso, é inevitável o uso de plugins complicados, o que afeta o desempenho do sistema.

Portanto, o gerenciamento é feito por separação de clusters para realizar o isolamento da configuração do cluster no APISIX, o que pode:

- Controlar o domínio de falhas e suportar efetivamente a complexidade dos projetos sem afetar outros projetos
- Reduzir efetivamente a carga causada pela camada não de encaminhamento do APISIX quando os nós de contêineres mudam frequentemente
- Reduzir o impacto de carga causado pela verificação de saúde

#### Aumento do QPS Suportado por HTTPS

De acordo com os requisitos relevantes do Ministério da Indústria e Tecnologia da Informação da China, o tráfego da rede externa deve passar pelo protocolo HTTPS. Como um protocolo de criptografia HTTP baseado em TLS, o HTTPS sobrecarrega a CPU no processo de criptografia e descriptografia.

Quando as configurações de roteamento e outras são as mesmas, o tráfego que o HTTPS pode suportar é cerca de **1/8 - 1/10** do que o HTTP.

Após aplicar o patch no acelerador Intel® QAT (QuickAssist Technology), a vivo entrega o tratamento de descriptografia ao acelerador QAT, o que libera a CPU, aumentando assim o QPS suportado por HTTPS em uma única máquina. Como pode ser visto na figura abaixo, **a capacidade de carga HTTPS de uma única máquina é aproximadamente dobrada**.

![Dados mostrando a melhoria da vivo na capacidade de suportar tráfego](https://static.api7.ai/2022/11/23/637dc306a5fa1.jpg)

## Como a Vivo Combina Negócios com o APISIX

### Apoiando o Desenvolvimento de Containerização

Para apoiar o desenvolvimento de containerização, a vivo desenvolveu um controlador de ingress K8s. Abaixo estão algumas de suas funções.

1. Adaptando-se ao mecanismo de alteração de configuração de push assíncrono modificado pela vivo

2. Realizando notificações de processamento de eventos de múltiplos clusters K8s para o APISIX

3. Lidando com cenários de projetos complexos, como:

- Um servidor com várias portas

- Quando outros servidores de framework RPC, como Dubbo e gRPC, são conectados ao K8s, é necessário um conjunto unificado de lógica de processamento para notificar o APISIX ou outros frameworks sobre as informações de porta de acordo com as características de configuração dos projetos

4. Adaptando-se às necessidades específicas do DevOps interno da empresa e outros cenários de automação, facilitando a implantação rápida e permitindo o tráfego

### Ajudando na Migração de Projetos do NGINX para o APISIX

Os projetos da vivo são implantados no cluster NGINX existente e têm sido executados de forma estável por um longo tempo. No entanto, isso traz cargas de trabalho não relacionadas aos negócios e instabilidade aos projetos. Consequentemente, é desafiador realizar a migração. Então, como promover a migração dos projetos para o APISIX?

- Primeiro, encontrar um projeto de um departamento cooperativo, atender bem ao departamento de negócios para estabelecer um benchmark e fornecer orientação técnica e treinamento

- Construir um sistema de plano de controle fácil de usar para facilitar o acesso dos negócios e o gerenciamento multidimensional dos departamentos de negócios

- Fornecer capacidade de conversão automática e configuração básica para converter a configuração do NGINX para a configuração do APISIX

### Atualizando o APISIX e Apoiando Sua Versão de Código Aberto

Com base na versão 2.4 do APISIX, a vivo fez alguns ajustes e lançou a nova versão, que foi atualizada para uma versão mais recente no segundo trimestre deste ano.

Por um lado, graças à arquitetura modular do APISIX, é relativamente fácil integrar o código Lua modificado pela vivo ao branch da versão mais recente do APISIX. Por outro lado, a vivo também continua atualizando a seção do OpenResty, com cerca de uma versão por ano. Como a vivo utiliza muitos PATCHs e algumas funções úteis como o QAT, a atualização desse componente é difícil e trabalhosa.

A versão gratuita da comunidade do NGINX tem atualizações lentas e é inativa. A vivo está considerando se deve construir em conjunto com o APISIX. Para reduzir a mão de obra necessária para fazer testes de sistema relacionados, a vivo adotou o Robot Framework, um framework genérico de automação de testes para testes de integração de sistema. Eles estão promovendo os componentes relevantes para a cobertura de testes unitários e o modelo de desenvolvimento de TDD (Desenvolvimento Orientado a Testes).

## Planejamento Futuro da Vivo

No próximo ano, a vivo planeja estender o [APISIX](https://apisix.apache.org/blog/2022/09/13/why-is-apache-apisix-the-best-api-gateway/) como um gateway de tráfego para um gateway de API, utilizando suas vantagens de [limitação de taxa](https://apisix.apache.org/docs/apisix/plugins/limit-count/#attributes), [autenticação](https://apisix.apache.org/docs/ingress-controller/tutorials/mtls/), interrupção de circuito, etc. Considerando a combinação do APISIX com o DPDK-NGINX, a vivo também cultivará pessoal técnico e se juntará ao estabelecimento da comunidade. Além disso, consolidará as habilidades básicas para estabelecer uma boa base, construindo governança de tráfego e serviços.

Bem-vindo a saber mais sobre o Apache APISIX.

Você pode entrar em contato conosco em [https://api7.ai/contact](https://api7.ai/contact).


Como a famosa fabricante de dispositivos móveis vivo adota o APISIX como seu gateway de API e o ajusta para se adequar aos seus negócios?

Como o vivo se integra com o APISIX

## Visão Geral

### Desafios

- Um desafio significativo na governança de dados à medida que os negócios da Airwallex se expandem globalmente
- A gestão complicada de vários sistemas e interconexões causa problemas em outros sistemas quando um problema ocorre

### Resultados

- Desempenho estável por **15 meses** em ambiente de produção
- **99%** dos atrasos de resposta estão dentro de **23 ms** quando o roteamento dinâmico, limitação de taxa multi-inquilino, lista branca de IP multi-inquilino, autenticação e autorização estão habilitados
- Suporte seguro e eficiente à soberania de dados, cobrindo mais de **50 moedas** em mais de **130 países e regiões**

## Sobre a Airwallex

Como uma empresa global de fintech, a [Airwallex](https://www.airwallex.com/us) construiu uma plataforma financeira global, com sua rede de pagamentos cobrindo mais de 50 moedas em mais de 130 países e regiões em todo o mundo, e fornece produtos de fintech digital para empresas.

![Negócios da Airwallex](https://static.api7.ai/apisix-webp/202108/1646626634389-7d9a0a82-a76c-4645-93b6-8a431bb1f9a1.webp)

> Este artigo vem da entrevista com Yang Li, Ph.D., Committer do Apache APISIX e Líder Técnico de Plataforma da Airwallex, responsável pela evolução da plataforma tecnológica da Airwallex.

## A Soberania de Dados Representa um Desafio para a Airwallex

[A soberania de dados](https://api7.ai/blog/leveraging-api-gateway-for-data-sovereignty-and-data-compliance) está se tornando cada vez mais importante na governança de dados no ciberespaço. A Airwallex atende usuários em várias regiões, o que naturalmente envolve o problema da soberania de dados.

Antes, sem a exigência de soberania de dados, os dados podiam ser colocados na Europa e sincronizados para a Ásia ou qualquer data center no mundo. O diagrama de interação de dados era assim:

![Interação Multi-cluster](https://static.api7.ai/202108/1635907812257-962b1247-f5ca-448f-904d-fd47c3ea4586.png)

No entanto, em uma era onde a soberania de dados é valorizada, os dados estão sob controle, e a arquitetura anterior não pode ser adotada. Na Europa, apenas dados europeus podem ser processados, e da mesma forma, apenas dados asiáticos podem ser processados na Ásia. As mudanças na interação de dados são as seguintes.

![Interação em ambiente de soberania de dados](https://static.api7.ai/uploads/2023/02/01/63Z7AhJx_2.webp)

Como resultado, a soberania de dados representa um desafio significativo para os negócios globais da Airwallex. A Airwallex pretende migrar dados da Europa para outras regiões e precisa garantir que os requisitos de soberania de dados de países terceiros estejam alinhados com os da UE.

## Por que a Airwallex Escolheu o APISIX?

Ao selecionar o gateway de API, a Airwallex comparou principalmente os principais produtos de gateway em seis dimensões:

- **Estabilidade**: A Airwallex dá grande importância à garantia da estabilidade do gateway de API. Entre os 1000 principais sites do mundo, **62,1% são baseados em NGINX**, o que mostra que os servidores web baseados em NGINX passaram no teste de cenários complexos e diversos em ambiente de produção. O Apache APISIX é baseado no NGINX. Além disso, o design do recurso **[totalmente dinâmico](https://api7.ai/blog/how-nginx-reload-work)** do Apache APISIX também torna possível modificar a rota sem recarregar e manter a conexão longa do cliente. Além disso, **a Airwallex também realizou testes de estresse no Apache APISIX, que ainda pode funcionar de forma estável quando o uso da CPU atinge mais de 70%.**

- **Desempenho**: Cada solicitação de API passará pelo gateway de API. Reduzir a [perda de desempenho](https://api7.ai/blog/apisix-kong-3-0-performance-comparison) do gateway pode reduzir significativamente o tempo geral de resposta das APIs da Airwallex.
  
    > "No PoC, comparamos os principais produtos de gateway: **o atraso de resposta do Apache APISIX é mais de 50% menor do que o de outros gateways**. Além disso, o plano de dados independente do Apache APISIX permite instâncias independentes nos clusters, tornando-o inerentemente suportável à expansão horizontal." disse Li.

- **Escalabilidade**: A Airwallex precisa que o APISIX funcione como um gateway de API que suporte **[autenticação](https://api7.ai/blog/api-gateway-authentication) complexa, controle de permissões, [descoberta de serviços](https://api7.ai/blog/what-is-service-discovery-in-microservices), [limitação de taxa](https://api7.ai/blog/rate-limiting-in-api-management), degradação, balanceamento de carga, lista branca e roteamento dinâmico**.

- **Comunidade Ativa**: Uma comunidade ativa é fundamental para que o Gateway de API acompanhe o ritmo da evolução tecnológica.

    > **A [comunidade](https://api7.ai/category/community) do Apache APISIX estava ativa desde que ainda era um projeto de incubação da Apache, julgando pelo número de contribuidores, tempo de resposta de problemas e número de Pull Requests.** Li compartilhou.

- **Implantação Privada**: O gateway de API é um componente central da arquitetura técnica da Airwallex, que implanta o gateway de API na borda de sua própria rede privada. **O Apache APISIX tem boa adaptabilidade ambiental e pode ser facilmente implantado em vários ambientes, incluindo plataformas de computação em nuvem.**

- **Licença Open-source Amigável para Negócios**: A Licença Apache 2.0 permite que a Airwallex modifique o código do APISIX e o comercialize sem se preocupar com o bloqueio de fornecedores.

## Solução de Roteamento Inteligente do Apache APISIX

**A Airwallex escolheu o Apache APISIX para fazer uma solução de roteamento inteligente**, e é o gateway Apache APISIX que decide onde os dados devem ser processados.

![Gateway de Duas Camadas da Airwallex](https://static.api7.ai/uploads/2023/02/01/cGg9YfNp_3.webp)

O gateway é composto por duas camadas. A primeira camada é responsável por rotear as solicitações, determinando para qual data center a solicitação deve chegar com base nas condições. A segunda camada é responsável pelo encaminhamento de tráfego.

Além disso, **a Airwallex implementou as principais funções como [plugins](https://api7.ai/blog/how-to-implement-plugin-orchestration-in-api-gateway) personalizados** para atualizar para uma nova versão do Apache APISIX a qualquer momento. Dessa forma, não haverá condição de corrida entre a biblioteca de código da Airwallex e o código principal do repositório do Apache APISIX. No entanto, modificar o código principal é necessário às vezes. Nesse momento, Li tentaria ao máximo implementar essas funções na comunidade open-source. **Os contribuidores da comunidade são muito entusiasmados em discutir a implementação de funções e, na maioria dos casos, podem fornecer rapidamente soluções disponíveis.**

## Como a Airwallex Está se Beneficiando do Uso do APISIX?

Abaixo está um diagrama mostrando a integração da Airwallex com o APISIX.

![Diagrama de Integração da Airwallex e APISIX](https://static.api7.ai/uploads/2023/01/31/Q0LbIb0E_88.webp)

A Airwallex utiliza o Apache APISIX como o componente central do modelo de gateway de microsserviços. Ele é implantado na borda da rede e fornece uma função de gateway geral para todo o tráfego que entra na Airwallex. Os problemas que ele resolve incluem:

- **Soberania de Dados**: Para infraestrutura financeira que opera além das fronteiras, a soberania de dados é um requisito regulatório crítico. Para isso, **a Airwallex desenvolveu um plugin de roteamento dinâmico em conformidade com as regulamentações, aproveitando as capacidades de seleção dinâmica de upstream do Apache APISIX**. O roteamento dinâmico pode selecionar inteligentemente upstreams para distribuição de solicitações de acordo com as características das solicitações dos usuários, abstraindo questões complexas de colaboração multi-data center da camada de serviço para a camada de gateway. A essência do roteamento dinâmico é responder a duas perguntas: como agrupar upstream e como combinar solicitações e grupos.

- **Isolamento em Microsserviços**: A Airwallex espera que as equipes de engenharia de cada microsserviço possam controlar independentemente seus próprios serviços, reduzir efetivamente o custo de comunicação e coordenação e melhorar a eficiência de engenharia. Esse conceito arquitetônico exige que componentes de infraestrutura compartilhados por várias equipes, como o Gateway de API, possam suportar o isolamento de inquilinos. **O APISIX é perfeito para satisfazer o isolamento de inquilinos.** Enquanto garante a robustez e o controle de custos de todo o sistema, o APISIX permite que as equipes de negócios configurem e expandam as funções do gateway de acordo com suas próprias necessidades, mantendo a independência das equipes e serviços de microsserviços.

- **Limitação de Taxa Multi-inquilino**: Em um ambiente multi-inquilino, as características de tráfego de cada inquilino são diferentes. Aplicar a mesma limitação de taxa a diferentes inquilinos não atende às necessidades comerciais. **A [limitação de taxa](https://api7.ai/blog/rate-limiting-in-api-management) multi-inquilino pode ser mais apropriada com base nas características do usuário.**

- **Lista Branca de IP Multi-inquilino**: O IP de acesso de cada inquilino varia em um ambiente multi-inquilino. **A lista branca de IP multi-inquilino permite que cada inquilino controle sua própria lista branca sem se preocupar com a invasão de seus próprios recursos por outros usuários.**

- **Autenticação**: A atualização frequente de chaves é um elo crítico para garantir a segurança dos recursos do usuário. **O APISIX suporta não apenas a [autenticação](https://api7.ai/blog/understanding-microservices-authentication-services) de solicitações, mas também a atualização dinâmica de chaves.**

- **Autorização**: O gerenciamento de permissões de aplicativos empresariais é muito complicado, e diferentes cenários de aplicação têm modelos de gerenciamento de permissões completamente diferentes. **O APISIX pode verificar se o usuário solicitante tem permissões suficientes para acessar a interface de acordo com a configuração de roteamento e interceptar tráfego ilegal na primeira vez.**

O ambiente de produção da Airwallex está em execução há **15 meses**, e o desempenho geral é extremamente estável. Cerca de **99% dos atrasos de resposta estão dentro de 23ms** quando o roteamento dinâmico, limitação de taxa multi-inquilino, lista branca de IP multi-inquilino, autenticação, autorização e outras funções estão habilitadas.

**Graças ao excelente mecanismo de plugins do Apache APISIX, a Airwallex pode adicionar plugins privados que atendam às necessidades de negócios sem modificar seu código principal.** O sistema de teste completo garante ainda mais a qualidade do software, e você pode aumentar com segurança os requisitos personalizados do plugin enquanto garante que a lógica principal original não seja danificada.

## Plano Futuro

O plano de acompanhamento da Airwallex inclui principalmente três aspectos:

1. Usar uma rede de várias camadas para dividir a lógica do gateway em diferentes camadas, como distribuir tráfego de acordo com a soberania de dados ou outra lógica de gateway.

2. Gerenciamento de roteamento fácil de ler e usar é crítico para o sucesso do gateway de API. O gerenciamento de roteamento precisa ser amigável para os desenvolvedores, para que eles possam entender facilmente o que o gateway pode fazer por eles e como configurá-lo e publicá-lo.

3. Usar solicitações codificadas por cores para ajudar a implementar testes em ambiente de produção. Usar solicitações codificadas por cores do gateway de API para implementar testes em ambiente de produção pode trazer mais flexibilidade e facilidade de uso.

## Procurando Suporte para o APISIX?

[Apache APISIX](https://api7.ai/apisix) é um gateway de API nativo da nuvem, open-source, 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 open-source de alto nível da Apache.

Você quer acelerar seu desenvolvimento com confiança como a Airwallex? Para maximizar o suporte ao APISIX, você precisa da [API7](https://api7.ai/). Fornecemos suporte aprofundado para o APISIX e soluções de gerenciamento de API com base em suas necessidades!

Entre em contato conosco agora: [https://api7.ai/contact](https://api7.ai/contact).

Mais sobre o entrevistado:

![Yang Li, Airwallex](https://static.api7.ai/uploads/2023/01/31/uGbiZnt5_Airwallex2.webp)


Airwallex resolves technical challenges that data sovereignty brings and makes intelligent routing solutions with the help of Apache APISIX.

What is Apache APISIX?

Why Apache APISIX?

APISIX vs alternatives

To Maximize APISIX, You Need API7

Case Studies

Como o Zoom usa o APISIX Ingress em seu pipeline de entrega contínua?

Como o vivo se integra com o APISIX

Como a Airwallex Capacita Pagamentos Globais Usando o Apache APISIX?

Looking for Apache APISIX Support?