Como o APISIX Facilita a Implantação Localizada da Plataforma de Mídia Social Beeto no Oriente Médio

Visão Geral

Desafios

• Arquitetura de serviço monolítica resulta em altos custos de manutenção e operação
• Implantação de arquitetura complexa e chamadas de serviço, além de múltiplas pilhas tecnológicas

Resultados

• Unificação do tráfego norte-sul e leste-oeste, economizando recursos e custos de mão de obra, permitindo gerenciamento dinâmico e unificado
• Simplificação da arquitetura de implantação, reduzindo a interação entre o gateway e os usuários
• Os múltiplos plugins de extensão do APISIX ajudaram a Beeto a gerenciar eficientemente a verificação de permissões, distribuição de rotas e funções de verificação de saúde dos serviços
• O APISIX permite que a Beeto lance e migre serviços dinamicamente, o que é amigável para desenvolvedores

Introdução à Beeto

Para o mercado do Oriente Médio, a Beeto é uma plataforma de mídia social em árabe, com design de produto e arquitetura técnica localizados. Já alcançou o 4º lugar na lista dos principais aplicativos da App Store iOS da Arábia Saudita, superando o gigante das redes sociais, o Facebook.

O desenvolvimento da internet no Oriente Médio é maduro, com uma penetração muito alta de usuários ativos em redes sociais. Especialmente na Arábia Saudita, onde 90% das pessoas usavam a internet em 2019. A taxa de penetração de usuários ativos na Arábia Saudita ficou em 9º lugar em 2020.

A maturidade do mercado de internet resultou em softwares sociais internacionais populares como WhatsApp, YouTube e Instagram. No entanto, não há um software social localizado semelhante ao Twitter. Portanto, visando o "mercado de internet maduro, mas com pouca localização" do Oriente Médio, a Beeto lançou o desenvolvimento de produtos localizados na região.

A Localização é Importante para a Beeto

Comparada a aplicativos de fluxo de feed como Twitter e Facebook, a Beeto planejou uma estrutura relativamente completa para implantar sua arquitetura de negócios no Oriente Médio. Por exemplo, estava comprometida em satisfazer a interação de relacionamento de atributos sociais, consumo de conteúdo (texto, transmissão ao vivo de vídeo, publicidade local, etc.), além de vários negócios como recompensas, saques, votação e sorteio de categorias financeiras e de serviços, e até mesmo os requisitos de supervisão da plataforma e revisão de segurança de conteúdo.

Como indicado anteriormente, a maturidade da internet no mercado do Oriente Médio exige inevitavelmente produtos de alta qualidade. Portanto, a primeira versão da arquitetura de negócios da Beeto foi um produto completo que integrava todos os recursos que um software social mainstream deveria ter. Enquanto isso, o objetivo da Beeto é se tornar a maior plataforma social em árabe e a melhor comunidade árabe no Oriente Médio com "recursos de localização". Para alcançar esse objetivo, a Beeto analisou os requisitos de localização conforme abaixo.

Pontos de Dificuldade no Design da Arquitetura da Beeto

A localização inclui as necessidades sociais locais existentes no nível de negócios e operações localizadas no nível técnico, como implantação de serviços e armazenamento de dados. Aqueles familiarizados com o Weibo ou Twitter saberão que são necessárias dezenas ou centenas de sistemas arquitetônicos para colaborar por trás de um produto de fluxo de informações tão grande. Os pontos de dificuldade na arquitetura da Beeto são mostrados a seguir.

Arquitetura de Serviço Monolítica Causa Altos Custos

Os serviços da Beeto podem ser divididos em oito partes, conforme abaixo.

A implementação desses negócios requer implantação localizada no Oriente Médio. Cada serviço é uma arquitetura monolítica separada se cada negócio for dividido por serviço.

O diagrama de arquitetura monolítica acima mostra uma arquitetura de implantação comum. Tomemos o serviço de fluxo de feed da Beeto como exemplo. Se quisermos atender à demanda do usuário de navegar no fluxo de feed, devemos suportar o acesso à rede pública, ou seja, o acesso ao tráfego norte-sul; ao mesmo tempo, o serviço de fluxo de feed também fornece algumas chamadas internas na forma de negócios de tópicos, ou seja, chamadas de tráfego leste-oeste.

Portanto, o serviço geral suporta modos de chamada externa e interna. Após o balanceamento de carga da Camada 7, o tráfego do usuário é distribuído para diferentes servidores, e então diferentes recursos de armazenamento são chamados. O tráfego leste-oeste também é semelhante. O cluster da Camada 7 lida com o tráfego norte-sul e leste-oeste, balanceamento de carga, autenticação e monitoramento de nós.

Quando os serviços de múltiplos negócios são combinados, a arquitetura geral pode ser:

Como você pode ver, os serviços existem nas camadas de adaptação, negócios e serviços básicos. A arquitetura de implantação para cada um desses serviços tem os detalhes arquitetônicos monolíticos mencionados acima, então há vários clusters da Camada 7 no meio, o que é uma arquitetura de sistema muito grande e complexa.

No entanto, como o produto Beeto está em fase inicial e o produto é lançado no Oriente Médio, mas sua equipe de P&D está na China, são necessários grandes custos de servidor e manutenção. Além disso, à medida que os negócios aumentam posteriormente, o número de serviços monolíticos inevitavelmente aumentará, tornando mais difícil controlar tanto os custos quanto as operações de manutenção.

Dificuldade no Lançamento de Múltiplos Serviços

Além da complexidade da implantação da arquitetura, as chamadas entre os serviços dentro do cluster também são muito complexas.

O tráfego norte-sul é distribuído para vários pools de serviços, e o tráfego leste-oeste também é intercalado entre vários serviços, com as relações de chamada entre esses serviços entrelaçadas.

Além disso, essas relações de chamada precisam ser mantidas pelos serviços, o que leva a uma rastreabilidade de chamada pouco clara e uma gestão deficiente.

Além das complexas relações de chamada, também há diferenças nas pilhas tecnológicas entre cada serviço. Por exemplo, no protocolo de chamada, alguns serviços fornecem HTTP, enquanto outros fornecem RPC; Em termos de desenvolvimento de linguagens de programação, há uma mistura de Java, Go e outras linguagens de programação.

Um sistema de arquitetura de múltiplos serviços obviamente expõe o problema de altos custos de implantação e manutenção quando implementado localmente. Além disso, a Beeto precisa investir em custos de servidor em cada conjunto de serviços da Camada 7, enquanto a diferença de tráfego de cada serviço leva a um tráfego desequilibrado, resultando em uma baixa taxa de utilização de recursos como servidores e desperdício de recursos.

Como a Beeto se concentrou mais em atualizações e iterações de negócios, a arquitetura foi projetada para facilitar a manutenção e o gerenciamento unificado, então como alcançar esse objetivo?

O Gateway APISIX Potencializa a Arquitetura da Beeto

Para resolver os problemas de gerenciamento inconveniente de serviços e altos custos e para beneficiar-se do desempenho dinâmico do APISIX com etcd, que está mais alinhado com os requisitos do produto Beeto, o APISIX foi introduzido como um gateway de API na implantação da arquitetura, e um cluster de gateway foi construído, conforme mostrado na figura abaixo.

O cluster de gateway APISIX fornece ferramentas de extensão como um centro de registro, controle de serviços, monitoramento de serviços, encaminhamento de protocolo e plugins para todos os serviços. Clusters de serviços podem ser todos registrados no gateway, e novos serviços podem ser adicionados e removidos diretamente através do gateway.

Após a introdução do gateway, o rastreamento de chamadas de todo o cluster ficou mais claro. O tráfego norte-sul é roteado e encaminhado pelo gateway, e o tráfego leste-oeste é pelo gateway para serviços na intranet. No nível funcional, o APISIX é responsável por manter a autenticação chamada por esse tráfego, para que a camada de gateway possa entender claramente as diferenças de desempenho e tráfego entre os serviços.

Claro, como o gateway carrega todo o tráfego nessa arquitetura, o número de serviços aumentará posteriormente à medida que o serviço se expandir, o custo de manutenção do gateway aumentará e novas soluções precisarão ser consideradas. No entanto, no contexto atual, a solução ainda é a melhor escolha.

Práticas Após a Aplicação do APISIX

O Apache APISIX, como um gateway de API, pode lidar com uma variedade de políticas no nível do gateway, como autenticação, encaminhamento de serviços e verificações de saúde. Portanto, a Beeto fez muitas tentativas no nível de prática de negócios após a introdução do APISIX.

Segurança: Plugin de Autenticação

Tráfego Norte-Sul: Cookie

Como mencionamos anteriormente, o tráfego de acesso de usuários da rede pública passa pelo gateway. A autenticação de usuários da rede pública é uma solicitação de usuário baseada em autenticação de cookie. Quando um usuário solicita trazer um cookie para o gateway, ele é verificado pelo plugin de autenticação.

Como mostrado no fluxograma acima, o plugin primeiro realizará uma validação local e, em seguida, realizará a verificação de autenticação do serviço remoto de acordo com a política. Uma vez que a solicitação é verificada por cookie, ela será encaminhada para o serviço especificado.

As vantagens de fazer isso são duas:

1. A segurança dos cookies dos usuários é garantida. Apenas a camada de gateway pode receber e processar cookies durante a execução, porque os cookies são dados sensíveis. Isso evita problemas de segurança causados por regras de processamento de negócios inconsistentes e evita efetivamente o vazamento de cookies causado por fatores humanos e irregularidades.

2. Reduzindo a complexidade da autenticação de cookies para serviços. Os cookies precisam ser verificados local ou remotamente e exigem atualização simultânea do serviço quando os cookies são atualizados. O APISIX gerencia e verifica de forma unificada, economizando o custo de verificação dos serviços de negócios e indicando os resultados, que podem ser usados para o processamento de regras de negócios, garantindo que cada processamento de negócios seja mais focado no próprio negócio.

Tráfego Leste-Oeste: Token

No diagrama abaixo, o Serviço A chama o Serviço B. Geralmente falando, uma API é tudo o que é necessário para chamar um ao outro. No entanto, no processo interno, é necessário entender "quem chamou a API, como foi chamada, se é necessário verificar a autoridade, e se é necessário controlar o pesquisador", e assim por diante, que precisam ser tratados internamente.

Com o gateway APISIX, o processo se torna muito mais simples. A chamada mútua de todos os serviços internos só precisa ser registrada no serviço de autenticação Auth, e uma chave de aplicativo é emitida para cada serviço para indicar o ID de identidade do serviço. Ao mesmo tempo, a chamada mútua de serviços internos também passará pelo gateway. Após carregar o token através do gateway, o gateway autenticará o token através dos plugins de token. Após a autenticação ser aprovada, o identificador de autenticação será passado para o serviço chamado. Durante todo o processo, o sistema de serviços realizará o registro de autenticação e completará uma chamada mútua.

Graças à regra de token da chave de aplicativo, a operação acima pode ser facilmente rastreada até a origem da chamada, o que pode ser usado para solução de problemas e controle de permissões, e também fornecer controle efetivo sobre chamadas ilegais. Portanto, a vantagem da autenticação unificada é que, seja para tráfego norte-sul ou leste-oeste, ela garante a segurança e uniformidade do cluster, o que ajuda muito no rastreamento de problemas e controle de chamadas.

Escalabilidade: Expansão e Migração de Serviços Sem Estado

A arquitetura de implantação geral do cluster da Beeto, de cima para baixo, é composta por: clusters de gateway APISIX - clusters de serviços de negócios de serviços sem estado - clusters de centro de dados de serviços com estado. Quando implantados localmente no Oriente Médio, todos são implantados em grandes clusters de nuvem. De acordo com a escala de cobertura de nuvem no Oriente Médio e os fabricantes de nuvem em diferentes regiões, é necessário considerar a expansão e migração de serviços em nuvem ao implantar serviços.

No processo de migração, a Beeto focou na migração de serviços sem estado. Não é adequado para ajuste dinâmico devido ao custo limitado de migração do centro de dados; a maioria das solicitações é carregada pelo serviço sem estado, por isso é muito importante garantir que o serviço sem estado tenha boa escalabilidade.

Na arquitetura da Beeto, a escalabilidade do serviço é refletida principalmente em dois aspectos: escalabilidade de serviço monolítico e escalabilidade geral do cluster. Por exemplo, se um serviço monolítico ficar sem recursos e precisar ser expandido, os gateways APISIX podem adicionar nós dinamicamente para escalar. Da mesma forma, em situações de cluster cruzado ou nuvem cruzada, a escalabilidade do cluster pode ser alcançada implantando vários gateways APISIX e migrando diferentes serviços para diferentes nós de gateway.

Para serviços de negócios, a arquitetura geral permanece inalterada, de modo que a expansão e contração dinâmica de vários serviços e a migração de serviços possam ser realizadas na camada de gateway. Todo o processo tem um plano e objetivo claros, e uma vez que mudanças estejam envolvidas, a arquitetura geral não ficará instável.

Extensibilidade Funcional: Encaminhamento Dinâmico de Serviços

Além desses cenários gerais de gateway familiares mencionados acima, o Apache APISIX também fornece assistência significativa à Beeto em termos de encaminhamento dinâmico de serviços.

Aqueles familiarizados com a UI e o backend de APPs devem saber que diferentes páginas de produtos são fornecidas por diferentes serviços. Uma página é composta por diferentes módulos, cujo conteúdo é todo enviado pela API. Seja qual for o dado que a API enviar para o módulo, ele será renderizado nas extremidades. Esta é uma especificação de renderização do lado do cliente para tornar o processo de renderização do lado do cliente mais genérico e o processamento de negócios mais flexível.

Na implementação da PageA na figura acima, por exemplo, o cliente chama a API do Serviço A, envia os dados do módulo correspondente e completa a renderização da PageA. Esta operação causará problemas que o cliente precisa manter cada página e API para cada serviço. Se o conteúdo mudar, é necessário ser resolvido por publicação, o que é muito desfavorável em termos de operabilidade e eficiência.

A solução para o problema acima é implementar uma distribuição unificada de serviços na arquitetura geral. O cliente primeiro solicita o endereço da API, encaminha todas as solicitações desse tipo para uma API, processa os parâmetros da solicitação e as regras de URL para o endereço URL no nível do gateway e, em seguida, introduz o plugin de distribuição. Finalmente, as solicitações analisadas são encaminhadas diretamente para o serviço especificado na camada de gateway de acordo com as regras de configuração.

O cliente só precisa determinar a especificação de renderização durante todo o processo, não a origem dos dados. A camada de gateway assume a responsabilidade de distribuição de serviços e encaminha o tráfego diretamente. O arquivo de configuração do plugin no APISIX pode ser atualizado dinamicamente em tempo real, e as regras de encaminhamento podem ser ajustadas dinamicamente, o que é muito flexível. Na verdade, para aplicativos como a arquitetura BFF (Backend for Frontend), tais requisitos podem ser resolvidos na camada de gateway.

Conclusão

Este artigo apresenta as práticas de aplicação da introdução do Apache APISIX pela Beeto, a partir das perspectivas de pensamento de design e negócios.

O APISIX apoiou a Beeto no controle do custo de recursos e múltiplas linhas de produtos de negócios e ajudou a Beeto a realizar implantação localizada, gerenciamento unificado e operação e manutenção amigáveis no Oriente Médio.