Dynamic

Rich Features

Cluster Management

Go for Apache APISIX

Looking for the best API Gateway?

Built on NGINX, with more features than NGINX.

 Many companies have migrated from NGINX to Apache APISIX, immediately achieving fast growth and reducing operational costs.

Apache APISIX vs NGINX:

## Visão Geral

Como fornecedor líder mundial de infraestrutura de blockchain de consórcio empresarial e provedor de soluções, a [Hyperchain Technologies](https://www.hyperchain.cn/en/about/company) está comprometida em construir infraestrutura inovadora e capacitar o desenvolvimento digital da sociedade. Durante seu rápido crescimento, a Hyperchain enfrentou vários problemas ao estabelecer sua plataforma de blockchain Hyperchain, conforme descrito abaixo:

- Falta de gerenciamento de tráfego padronizado com risco potencial de colapso do sistema
- Controle de segurança e gerenciamento de autenticação incompletos
- Controle de permissões inconveniente
- Alto custo com endereços IP de rede pública
- Nós de blockchain instáveis: nó único vulnerável a ataques
- Falta de gerenciamento unificado de múltiplos protocolos

A Hyperchain tentou usar Kong e NGINX, mas infelizmente, eles não conseguiram atender aos cenários de negócios da Hyperchain. **No entanto, após adotar o Apache APISIX, todos os problemas mencionados acima foram resolvidos, conferindo à plataforma de blockchain Hyperchain uma vitalidade infinita.**

### Sobre a Plataforma de Blockchain Hyperchain

A plataforma de blockchain Hyperchain refere-se à integração do framework de blockchain na plataforma de computação em nuvem, aproveitando as vantagens de infraestrutura de serviços em nuvem para implantação e gerenciamento. É uma plataforma de blockchain aberta que pode fornecer aos desenvolvedores um ecossistema de blockchain conveniente e de alto desempenho, além de serviços de suporte relacionados, e também suportar a expansão e operação de negócios dos desenvolvedores no web3.

**A plataforma de blockchain Hyperchain pode construir a rede de blockchain de forma rápida e flexível. Com a plataforma, as empresas podem gerenciar o negócio de blockchain de forma unificada.** Por exemplo, através da plataforma, podemos assinar contratos no ambiente de desenvolvimento integrado e, em seguida, implantar os contratos na rede de blockchain criada. O módulo de serviço superior pode chamar contratos relacionados ao blockchain para continuar o processo de negócios.

Como há muitos nós na cadeia, variando de dezenas a milhares, torna-se difícil monitorar e manter a operação da cadeia sem o suporte da plataforma. **Ao usar a plataforma de blockchain Hyperchain, os usuários podem não apenas economizar custos, mas também gerenciar o blockchain de forma mais conveniente e aumentar a segurança de todo o sistema.**

Vamos usar a Hyperchain como exemplo para entender como e por que as empresas de blockchain devem escolher o Apache APISIX entre muitos gateways de API. Abaixo, analisaremos a aplicação do APISIX tanto na plataforma de blockchain Hyperchain quanto no nó de blockchain.

## Aplicação do APISIX na Plataforma de Blockchain Hyperchain

Abaixo está um diagrama de interação de aplicação do APISIX na plataforma de blockchain Hyperchain. O serviço de backend registra as informações do serviço no etcd de acordo com suas características de negócios e, em seguida, registra o serviço no APISIX por meio do módulo de registro de rotas.

O APISIX funciona como a entrada unificada dos microsserviços internos no sistema. As solicitações externas são primeiro enviadas ao APISIX; em seguida, elas acessam a camada de acesso através da API após passar pela autenticação e, posteriormente, acessam os serviços principais por meio de RPC (chamada de procedimento remoto).

![Diagrama de interação de aplicação da Hyperchain](https://static.api7.ai/2022/11/15/637335a53d73c.png)

### Encaminhamento de Rotas

Às vezes, espera-se que as APIs sejam expostas sob o mesmo nome de domínio. Nesse caso, podemos adicionar alguns prefixos ao caminho da API do mesmo serviço, como `/baas-core` ou `/baas-other`. Quando o cliente solicita essas APIs, o gateway de API precisa remover esses prefixos adicionados e, em seguida, encaminhar a solicitação para o serviço de backend. O [plugin proxy-rewrite do APISIX](https://apisix.apache.org/docs/apisix/plugins/proxy-rewrite/) pode nos ajudar a lidar com esses casos de forma conveniente.

Por exemplo:
Ao acessar: http://apisix:8080/baas-{service}/api/v1/…
A solicitação pode ser encaminhada para http://{service}/api/v1/…
escrevendo uma expressão regular: `^/baas-core/(.*)$,/$1`

![Edição do plugin proxy-rewrite](https://static.api7.ai/2022/11/15/637335b538dc0.png)

### Gerenciamento de Limite de Tráfego

Os usuários podem escolher blockchains de consórcio de acordo com suas necessidades, não apenas da Hyperchain, mas também do IBM Data Fabric, Baidu XuperChain, etc. Portanto, a Hyperchain precisa realizar o gerenciamento do ciclo de vida de todos os blockchains de consórcio no sistema.

Ao criar uma cadeia de consórcio, a Hyperchain só precisa escrever o código hardcode na plataforma de blockchain e carregar os componentes de driver plugáveis na plataforma de blockchain para chamar e criar a cadeia de consórcio. Em alguns casos de implantação privada, os componentes de driver plugáveis podem suportar rapidamente.

Cada chamada aos componentes de driver é um processo que precisa ser limitado, especialmente quando o número é grande. Consequentemente, o [plugin limit-req do APISIX](https://apisix.apache.org/docs/apisix/plugins/limit-req/) pode ser benéfico para restringir a entrada e saída de tráfego da plataforma para garantir sua estabilidade.

O plugin limit-req permite configurações personalizadas sobre taxa e burst.

![Modelo do plugin limit-req](https://static.api7.ai/2022/11/15/637335b790f49.jpeg)

### Controle de Segurança e Gerenciamento de Autoridade

Para colaborar com o APISIX, a Hyperchain desenvolveu um plugin para circunstâncias de implantação privada. A Parte A geralmente prefere usar seus serviços de autenticação ou sistema de contas de serviço. Quando o tráfego do frontend visita o site, ele primeiro passa pelo plugin Access-auth, e só pode acessar o backend BFF (Backend for Frontend) se passar na autenticação.

![Diagrama do processo de autenticação](https://static.api7.ai/2022/11/15/637335b994030.png)

De acordo com os três fatores-chave da especificação padrão Restful (as informações de autenticação, o caminho Restful e os verbos HTTP como GET, POST, PUT, DELETE, PATCH, etc.), a autenticação de conta-role-autoridade é realizada. Se a autenticação for aprovada, as informações do usuário serão retornadas no cabeçalho; caso contrário, retornará 403.

![Caminho de autenticação da API](https://static.api7.ai/2022/11/15/637335bd3e080.png)

### Recarregamento a Quente

O APISIX oferece [recarregamento a quente](https://apisix.apache.org/docs/java-plugin-runner/hot-reloading/) de plugins desenvolvidos internamente. Isso economiza tempo durante o desenvolvimento e permite que os usuários alterem partes de seu código sem reiniciar todo o plugin runner. Dessa forma, os desenvolvedores podem fazer ajustes na interface no backend, que entram em vigor imediatamente, o que é conveniente e amigável para o lançamento online.

### Por que não o Kong?

A Hyperchain havia usado o Kong antes, mas finalmente o substituiu pelo Apache APISIX principalmente porque:

- **Alto Custo de Implantação e Manutenção**

    O cluster do Kong precisa cooperar com o banco de dados Postgresql e requer um administrador de banco de dados específico para alta disponibilidade. A implantação do cluster do banco de dados Postgresql é relativamente difícil de implementar e aumenta o custo de operação e manutenção posterior.

- **Aumenta a Complexidade do Sistema e a Taxa de Falhas**

    A plataforma de blockchain Hyperchain usa o banco de dados MySQL, resultando em dois bancos de dados relacionais no sistema se o Kong for adotado, o que torna o sistema mais complicado. Também aumenta a taxa de falhas ao melhorar a compatibilidade entre dois conjuntos de bancos de dados.

## Aplicação do APISIX no Nó de Blockchain

![Diagrama de blockchain da Hyperchain](https://static.api7.ai/2022/11/15/637335bfa08dc.png)

### Economia de Custos com Endereços IP de Rede Pública

O usuário adquire blockchains através da plataforma de blockchain Hyperchain. Em seguida, os negócios de nível superior e os clientes desenvolvedores podem se conectar aos nós. Os serviços podem se conectar a um ou mais nós, e os usuários podem acessar um ou mais nós, o que traz um problema: quase todos os nós serão visitados, sobrecarregando a pressão de visitação de um único nó.

É relativamente fácil de lidar em alguns ambientes de emprego privado. No entanto, muitos nós e IPs públicos são necessários para sistemas que visam usuários da internet. O preço de cada IP público de 4 megabytes de tráfego pode chegar a quase 200 CNY por mês. Há milhares de nós na plataforma Hyperchains, o que consome um alto custo de IP público.

O APISIX gerencia todas as solicitações de visita e distribui o tráfego para os nós de blockchain correspondentes. Dessa forma, a Hyperchain economizou um alto custo.

![Modo da Hyperchain com APISIX](https://static.api7.ai/2022/11/15/637335c23f4f8.png)

### Controle de Permissões Conveniente

Há vários blockchains na plataforma de blockchain Hyperchain, e cada cadeia tem um controle de permissões RBAC complicado. Portanto, diferentes tipos de certificados precisam ser adicionados no lado do cliente, como certificados TLS, o que também confunde os usuários.

Atualmente, o [plugin key-auth do APISIX](https://apisix.apache.org/docs/apisix/plugins/key-auth/) pode ser usado para resolver esse problema de forma eficiente. Usuários autorizados podem acessar diretamente o blockchain sem se preocupar com a configuração de permissões, pois o APISIX unifica a cadeia subjacente.

### Cluster Melhora a Estabilidade dos Nós

Como mencionado acima, os nós são visitados com frequência. Alta concorrência existe na maioria dos usuários bancários, pois o TPS (Transações Por Segundo) pode atingir 40.000-50.000 vezes.

Acontece que um único nó no blockchain é vulnerável porque cada transação impactará o nó visitado.

A Hyperchain implantou o Apache APISIX no K8s com o Horizontal Pod Autoscaler. Como o APISIX usa etcd com boa escalabilidade dinâmica, ele pode resolver efetivamente o problema de impacto de tráfego de ponto único.

### Suporte a Múltiplos Protocolos

Os protocolos das cadeias heterogêneas na plataforma de blockchain Hyperchain são diversos, como protocolo HTTP, protocolo Websocket, protocolo gRPC, protocolo TCP, protocolo UDP, etc.

O APISIX suporta múltiplos protocolos, adaptando-se flexivelmente às camadas subjacentes de diferentes blockchains, reduzindo assim os custos de desenvolvimento.

### Por que não o NGINX?

Parece que a Hyperchain poderia utilizar o NGINX para resolver seus problemas. No entanto, após o teste, a Hyperchain desistiu porque:

- **Inadequado para Expansão Dinâmica**

    A Hyperchain precisa adicionar e excluir nós na plataforma de blockchain com frequência, o que só entra em vigor após a reinicialização, o que é inconveniente para os desenvolvedores. Além disso, os desenvolvedores precisam escrever códigos de regras complexas para plugins no arquivo conf do NGINX.

- **Difícil de Clusterizar**

    O NGINX não suporta cluster, o que é relativamente complexo e pouco amigável para os usuários.

- **Sem Suporte Direto para TCP e UDP**

    O NGINX só pode fazer proxy do protocolo de camada 7, em vez do protocolo de camada 4, e não suporta diretamente os protocolos TCP e UDP. Além disso, o módulo não é compilado por padrão, exigindo processamento adicional.

- **Sem Dashboard**

    Não há interface visualizada do NGINX, o que dificulta o gerenciamento de tantos nós por desenvolvedores e operadores.

## Resumo

A partir do conteúdo mencionado acima, sabemos que o Apache APISIX é um gateway de API dinâmico que pode ser aplicado na área de blockchain. Além disso, o Apache APISIX fornece recursos ricos de gerenciamento de tráfego, como Balanceamento de Carga, Upstream Dinâmico, Lançamento Canário, Circuit Breaker, Autenticação, Observabilidade, etc.

Esperamos que o APISIX possa apoiar mais empresas de blockchain a entrar em outra fase de desenvolvimento.
Bem-vindo a saber mais sobre o Apache APISIX.
Você pode entrar em contato conosco em https://api7.ai/contact.


Como a empresa unicórnio de blockchain, Hyperchain, utiliza o APISIX, um gateway de API de código aberto, para capacitar a Plataforma de Blockchain Hyperchain a gerenciar o tráfego de blockchain no web3, mencionando a comparação entre APISIX, Kong e NGINX.

API Gateway para Web3: Como o APISIX Capacita a Hyperchain

## 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

## 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.

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway para Web3: Como o APISIX Capacita a Hyperchain

Como o vivo se integra com o APISIX

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

Pronto para gerenciar suas APIs?

Apache APISIX vs NGINX:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}Dynamic Configuration,Cluster Management

Looking for the best API Gateway?

Go for Apache APISIX

Dynamic

Rich Features

Cluster Management

Apache APISIX vs NGINX

Case Studies

API Gateway para Web3: Como o APISIX Capacita a Hyperchain

Como o vivo se integra com o APISIX

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

Pronto para gerenciar suas APIs?

Apache APISIX vs NGINX:
Dynamic Configuration,
Cluster Management