Open-Source Project

Community-Driven

High Availability, Stability

Ultimate Performance,

Developer Friendly

Go for Apache APISIX

Looking for the best API Gateway?

Companies choose Apache APISIX as their API gateway after comparing it with Kong. Not only is Apache APISIX is faster, but the experience is also excellent.

Apache APISIX vs Kong:

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

### Desafios

1. O grande volume de tráfego resulta em inúmeros alertas diários de CPU IDLE muito baixa.
2. Muitos componentes dependem da arquitetura do sistema.
3. Alto custo de O&M (Operação e Manutenção).

### Objetivos

1. Escolher um gateway de API de alto desempenho que atenda às necessidades da iQIYI.
2. Minimizar o custo de migração.
3. Encontrar um gateway de API com uma comunidade ativa e um ecossistema saudável.
4. Construir um novo gateway de API para se adequar à tendência de cloud-native.

### Resultados

1. O desempenho melhorou **10x** em relação ao anterior, suportando **milhões de QPS diariamente**.
2. Suportou facilmente **mais de 9.000 projetos de negócios online com API**.
3. Realizou com sucesso a recuperação de desastres de dados em **múltiplos sites e níveis em toda a China**.

## O que aconteceu por trás da iQIYI?

Cong He, engenheiro sênior de P&D da [iQIYI](https://en.wikipedia.org/wiki/IQIYI), compartilhou uma palestra no Apache APISIX Meetup em Xangai recentemente. Ele trabalha na equipe de computação em nuvem do departamento de infraestrutura IIG e é responsável pelo desenvolvimento do gateway e pelo trabalho de operações na iQIYI. Vamos mergulhar em sua palestra e na história do gateway de API da iQIYI para entender melhor o Apache APISIX.

Fundada em 22 de abril de 2010 pela Baidu, a empresa por trás do maior mecanismo de busca online da China, a [**iQIYI**](https://www.iq.com/?lang=en_us) é atualmente um dos maiores sites de vídeo online do mundo, com quase 6 bilhões de horas gastas em seu serviço a cada mês e mais de 500 milhões de usuários ativos mensais.

A iQIYI costumava desenvolver seu próprio gateway de API chamado Skywalker, um desenvolvimento personalizado baseado no Kong. O Skywalker precisa lidar com um tráfego massivo atualmente, e **o pico diário do serviço de gateway pode atingir um milhão de QPS e milhares de rotas de API**. No entanto, as deficiências deste produto começaram a aparecer gradualmente.

1. O desempenho do gateway não atende mais às necessidades da iQIYI, e ele recebe inúmeros alertas diários de CPU IDLE muito baixa devido ao grande volume de tráfego.
2. Há muitas dependências de componentes na arquitetura do sistema.
3. O custo de O&M (Operação e Manutenção) é muito alto.

Após assumir este projeto este ano, Cong começou a investigar produtos de gateway semelhantes para resolver os problemas e dificuldades mencionados acima e finalmente encontrou o Apache APISIX.

## Como o Apache APISIX supera o Kong

Antes de escolher o Apache APISIX, a iQIYI já havia começado a usar o Kong, mas o abandonou posteriormente.

### Por que abandonar o Kong?

Após a prática real com o Kong, Cong demonstra por que sua equipe abandonou o Kong. Abaixo estão algumas das principais desvantagens do Kong.

1. As rotas do Kong usam consultas de travessia, que não são rápidas.
2. O banco de dados Postgres do Kong resulta em uma implantação inchada, sincronização de baixa eficiência e baixa disponibilidade.
3. O código tem alto acoplamento.

### Por que escolher o APISIX?

> "Comparamos o desempenho entre o Apache APISIX e o Kong durante a investigação e, surpreendentemente, descobrimos que **o Apache APISIX era 10 vezes melhor que o Kong em termos de otimização de desempenho**. Também comparamos o Apache APISIX com alguns outros principais produtos de gateway, e **a latência de resposta do Apache APISIX é sempre mais de 50% menor que a de outros produtos**. Além disso, o Apache APISIX ainda pode funcionar de forma estável mesmo que o uso da CPU atinja mais de 70%. O APISIX é realmente incrível!" disse Cong.

Tanto o Apache APISIX quanto o Kong foram desenvolvidos com base no OpenResty no nível técnico, o que traz um custo de migração relativamente baixo. Além disso, o Apache APISIX tem uma excelente adaptabilidade e pode ser facilmente implantado em muitos ambientes diferentes, incluindo plataformas de computação em nuvem.

> "Enquanto isso, também descobrimos que o Apache APISIX é um projeto de código aberto altamente ativo que resolve problemas muito rapidamente. Seu framework cloud-native também está alinhado com os planos de acompanhamento de nossa empresa. Assim, escolhemos o Apache APISIX como nosso gateway de API."

## Inovação na Arquitetura do Gateway de API da iQIYI após o uso do APISIX

Após escolher o excelente gateway de API, a iQIYI começou a estabelecer sua nova arquitetura de gateway de API, que é mostrada abaixo, incluindo o domínio, o gateway, as instâncias de serviço e o monitoramento de alarmes.

![Diagrama da Arquitetura do Gateway de API da iQIYI](https://static.api7.ai/2022/12/02/6389647220deb.jpeg)

O DPVS é um projeto de código aberto desenvolvido com base no LVS pela iQIYI. O monitoramento de alarmes Hubble também é um desenvolvimento personalizado baseado em um projeto de código aberto, e algumas otimizações no desempenho e alta usabilidade do Consul foram feitas.

### Conquista 1: Melhorou os planos de dados e controle para gerenciamento de cluster e serviço

O plano de dados é principalmente voltado para usuários frontend, e toda a arquitetura do LB ao gateway tem implantações multi-site e multi-link para recuperação de desastres, de modo que **os usuários possam acessar seu data center mais próximo**.

Para o plano de controle, existe uma plataforma de microsserviços para **gerenciar múltiplos clusters e serviços**. A plataforma de microsserviços permite que os usuários experimentem um serviço de balcão único sem a necessidade de abrir tickets, **economizando uma quantidade significativa de tempo**. No backend, o controlador do gateway controla principalmente a configuração de todas as APIs, como criação de API e plugins, enquanto o controlador de serviço **lida com registro, cancelamento e verificação de saúde**.

![microsserviço-gateway.webp](https://static.api7.ai/2022/11/21/637b4c61c02c0.webp)

### Conquista 2: Adicionou mais funcionalidades: controle de segurança, limitação de taxa e monitoramento

A iQIYI implementou algumas funcionalidades básicas na arquitetura de API, como limitação de taxa, autenticação, alarme, monitoramento, etc., após ajustar-se ao [Apache APISIX](https://github.com/apache/apisix).

A primeira parte é sobre HTTPS. Para o controle de segurança, a iQIYI não armazena nenhum certificado ou chave nos servidores do gateway, mas em um servidor remoto dedicado. No entanto, isso era difícil de realizar enquanto usava o Kong; em vez disso, a iQIYI usou o prefixo NGINX para fazer o descarregamento de HTTPS. Após migrar para o Apache APISIX, a iQIYI implementou com sucesso essa funcionalidade no Apache APISIX, o que **economiza mais uma camada de transferência no link**.

Em termos de [limitação de taxa](https://apisix.apache.org/docs/apisix/plugins/limit-count/), além das funcionalidades básicas de limitação de taxa, **limitação de taxa precisa e limitação de taxa por granularidade de usuário também foram implementadas**. Para a autenticação, **serviços especializados para autenticação de passaporte** foram fornecidos. Além disso, a iQIYI pode acessar a nuvem de segurança WAF da empresa para filtrar a indústria subterrânea.

**A funcionalidade de monitoramento de alarmes é alcançada usando o plugin embutido do Apache APISIX - [Prometheus](https://apisix.apache.org/docs/apisix/next/plugins/prometheus/)**, e os dados de indicadores serão enviados diretamente para o sistema de monitoramento da empresa. O Apache APISIX também suporta a iQIYI com **serviços de registro e análise de rastreamento**.

### Conquista 3: Estabeleceu o processo de atualização dinâmica de descoberta de serviço

Em relação à descoberta de serviço mencionada acima, ela registra principalmente serviços em clusters Consul por meio do centro de serviços e, em seguida, usa a descoberta de serviço DNS para atualizá-los dinamicamente. O QAE no gráfico é uma plataforma de microsserviços usada internamente em nossa empresa. **Vamos usar um exemplo para demonstrar brevemente o processo de atualização de instâncias.**

Ao atualizar as instâncias, primeiro faremos o logout dos nós correspondentes do Consul e enviaremos solicitações de atualização de cache DNS para o gateway por meio do controlador do gateway de API. Quando o cache for atualizado com sucesso, o controlador enviará de volta solicitações para a plataforma QAE para parar todos os nós de aplicativos backend associados para evitar o reencaminhamento de tráfego para quaisquer nós offline.

![Processo de atualização dinâmica de descoberta de serviço da iQIYI](https://static.api7.ai/2022/12/02/63897fa31ff83.jpeg)

### Conquista 4: Melhorou a capacidade de rotas direcionais

O gateway tem implantações multi-site, e um conjunto completo de links de backup multi-site foi construído antecipadamente. Além disso, Cong também sugere que os usuários tenham implantações de acesso mais próximo multi-site para seus serviços backend. Assim, os usuários poderiam criar um serviço de API na plataforma de gateway Skywalker, e o controlador implantaria rotas de API em todos os clusters de gateway DC. Enquanto isso, o CNAME padrão do domínio do serviço será roteado para um nome de domínio de gateway unificado.

**O Apache APISIX poderia fornecer diretamente serviço com implantações multi-site de acesso mais próximo e capacidade de failover para recuperação de desastres e suporta resolução de rotas personalizadas definidas pelos usuários.** Além disso, os usuários poderiam personalizar a configuração de resolução de rotas por meio do nome de domínio UUID se precisassem de failover, implantação blue-green e lançamento canário. Adicionalmente, **o Apache APISIX também suporta o agendamento personalizado da recuperação de serviços backend**.

![Diagrama de rotas direcionais da iQIYI](https://static.api7.ai/2022/12/02/63898546bd508.jpeg)

### Conquista 5: Melhorou a tolerância a desastres multi-site e multi-nível

Para lidar com situações como grande volume de tráfego, muitos clusters e um amplo público de clientes, a iQIYI requer acesso ao serviço mais próximo e recuperação de desastres no nível operacional.

**Além de backups multi-site e multi-link para recuperação de desastres, a iQIYI ainda precisa considerar questões sobre situações multi-nível e multi-nó. O APISIX ajuda com isso.** Quanto mais próximos os clientes estiverem dos nós mortos, maiores serão os impactos nos negócios e no tráfego.

1. Se o nó de serviço backend mais distante estiver inativo, a iQIYI poderia alcançar o corte de nó único ou failover de DC morto por meio do mecanismo de verificação de saúde do centro de serviços e do gateway. Assim, o impacto seria limitado a serviços específicos, sem afetar usuários.
2. Se o gateway estiver inativo, então a iQIYI poderia usar o mecanismo de verificação de saúde do L4 DPVS para cortar nós de gateway com falha, e o impacto é relativamente pequeno, sem afetar usuários.
3. Se as medidas de disjuntor acima não puderem reparar o nó morto, então a iQIYI poderia alcançar o failover automático no DNS por meio do teste de usabilidade multi-nó de granularidade de nome de domínio na extranet. No entanto, esse método é relativamente lento e poderia impactar muitos outros serviços, e os usuários poderiam estar cientes disso.

## Plano Futuro da iQIYI

Na integração com o APISIX, a iQIYI está tentando otimizar algumas questões para se adequar melhor ao seu negócio.

1. Considerando os possíveis gargalos de alguns componentes dependentes, como etcd, monitor Prometheus e serviço de registro, **a iQIYI planeja usar um método de implantação híbrida. Ou seja: compartilhar informações dentro de grandes clusters e manter pequenos clusters independentes.** Por exemplo, os serviços vitais serão implantados com os pequenos clusters.

2. Mais **redução e otimização correspondentes para métricas de monitoramento Prometheus** serão realizadas, especialmente para descoberta de serviço DNS.

> Cong disse: "Esperamos que o Apache APISIX possa suportar mais funcionalidades e manter uma excelente eficiência de desempenho, bem como estabilidade em desenvolvimentos e atualizações futuras."

## Procurando suporte para o APISIX?

Você quer acelerar seu desenvolvimento com confiança como a iQIYI? Para maximizar o suporte ao APISIX, você precisa da API7. Fornecemos suporte aprofundado para o APISIX e soluções de gerenciamento de API com base em suas necessidades!

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


A equipe técnica da iQIYI compara o APISIX com o Kong, atualiza e integra a infraestrutura da iQIYI para construir com sucesso um novo gateway de API.

iQIYI desbloqueia inovação no API Gateway com Apache APISIX

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

Apache APISIX vs Kong:
93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

iQIYI desbloqueia inovação no API Gateway com Apache APISIX

API Gateway para Web3: Como o APISIX Capacita a Hyperchain

Pronto para gerenciar suas APIs?

Apache APISIX vs Kong:.css-j8kk69{background-image:var(--chakra-colors-gradient-600);color:transparent;-webkit-background-clip:text;background-clip:text;}93x Faster & 200% QPS

APISIX vs Kong Performance Report

Looking for the best API Gateway?

Go for Apache APISIX

Community-Driven

Open-Source Project

Ultimate Performance,

High Availability, Stability

Developer Friendly

Apache APISIX vs Kong

Case Studies

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

iQIYI desbloqueia inovação no API Gateway com Apache APISIX

API Gateway para Web3: Como o APISIX Capacita a Hyperchain

Pronto para gerenciar suas APIs?

Apache APISIX vs Kong:
93x Faster & 200% QPS