Soluções de API Gateway para a Indústria Automotiva

Sob a onda de digitalização e inteligência, as indústrias de manufatura e automotiva enfrentam oportunidades e desafios sem precedentes. Os carros não são mais apenas um produto mecatrônico para transporte, mas sim um terceiro espaço além de casa e empresa. Os carros evoluíram para se tornarem mais inteligentes, com uma integração profunda de software e hardware.

Do ponto de vista dos consumidores, a manobrabilidade e a segurança se tornaram configurações padrão dos automóveis. Todos têm exigências mais altas para os carros, um produto industrial que existe há mais de 100 anos: os carros inteligentes. Isso se reflete não apenas na assistência ao motorista, mas também na programação OTA (Over-the-air), controle por voz, controlador central com tela sensível ao toque, etc., o que exige maior capacidade de processamento de dados em tempo real, poder de computação e iteração de software automotivo.

Do ponto de vista das aplicações empresariais, a IoV (Internet of Vehicles) e os dados de upstream e downstream estão se tornando cada vez mais complexos. Como resultado, quebrar os silos de informação, abrir dados de diferentes sistemas e acelerar a inovação empresarial tornaram-se pontos de dor para as empresas de manufatura e automotivas.

Do ponto de vista da mudança tecnológica, o software de código aberto e nativo da nuvem traz suporte técnico para que as empresas de manufatura e automotivas acelerem sua transformação digital. Essas empresas podem aproveitar a oportunidade na conversão fazendo bom uso das tecnologias nativas da nuvem.

Hoje, mais de 5.000 chips estão presentes em um carro elétrico com função de assistência ao motorista, executando centenas de milhões de linhas de código. A nova era dos "Veículos Definidos por Software (SDV)" está gradualmente se aproximando.

Através da análise das estatísticas e pesquisas da comunidade de código aberto Apache APISIX, descobrimos que o Apache APISIX é amplamente utilizado na Quarta Revolução Industrial, cobrindo fábricas digitais, veículos inteligentes, chips de IA, direção autônoma, governança de microsserviços em empresas automotivas, finanças automotivas, vendas B2B de automóveis, vendas de carros usados para B2C e outros campos.

Abaixo estão alguns exemplos:

1. Fábrica Digital: Plataforma de Fábrica Europeia
2. Empresas Automotivas: Geely Auto, XPeng Motors, Lotus Cars, Li Auto, BeyonCa Autos
3. IA e Direção Autônoma: Horizon Robotics, Momenta
4. Finanças Automotivas: BMW Financial Services
5. Reconhecimento de Voz: AiSpeech

Como um gateway de API nativo da nuvem, o Apache APISIX é um componente fundamental que pode processar solicitações de API de vários terminais, como carros, dispositivos IoT, aplicativos móveis, etc. O uso generalizado do Apache APISIX em indústrias relacionadas à automotiva também está impulsionando projetos de código aberto a iterar para atender às necessidades de mais usuários empresariais.

Forneceremos soluções acumuladas do setor por meio do API7 Enterprise e API7 Cloud. Entre em contato conosco: https://api7.ai/contact.

A seguir, vamos descobrir como o API Gateway e o Apache APISIX ajudam os usuários empresariais a resolver problemas práticos por meio de alguns casos de uso típicos.

Plataforma de Fábrica Europeia Usa APISIX como Seu Gateway de Segurança

A EFPF (Plataforma de Fábrica Europeia) é uma federação de plataformas de manufatura digital (DMPs) financiada pelo programa Horizon 2020 da Comissão Europeia. A união contém 30 empresas e organizações de 10 países europeus, incluindo Siemens, Airbus SE, institutos de pesquisa e universidades, etc. Ela fornece soluções inovadoras da Indústria 4.0, IoT, inteligência artificial, big data e manufatura digital.

A EFPF fornece uma variedade de ferramentas e serviços, muitos dos quais fornecem uma ou mais APIs que outras ferramentas e serviços podem usar. A plataforma EFPF pode monitorar, controlar e analisar o uso de APIs usando o API Gateway. Além disso, o API Gateway permite que políticas definam como os usuários interagem com as APIs expostas por diferentes empresas na plataforma.

A Ferramenta de Gerenciamento de API ou Gateway de Segurança de API (ASG) usada na plataforma EFPF é um componente na Data Spine. O ASG é o gateway de borda para todas as chamadas de API e fornece serviços expostos externamente disponíveis no ecossistema EFPF. Enquanto atua como um serviço de proxy, ele também aplica políticas de segurança em chamadas de serviço em andamento. Na EFPF, o ASG é implementado usando Apache APISIX.

Aqui estão várias razões para escolher o Apache APISIX:

• Velocidade: Como o ASG irá intermediar chamadas da Data Spine para outras plataformas no ecossistema, a latência para as chamadas é minimizada.
• Plugins Personalizados: O ASG deve depender de código/configuração mínima para desenvolver plugins de segurança personalizados.
• Licença: Uma licença permissiva (Apache / MIT) é preferida para a implementação do ASG.
• Suporte para MQTT.

Além disso, as seguintes questões de gerenciamento de API também são abordadas:

• Configuração de API, gerenciamento do ciclo de vida e descoberta de serviços
• Uniformidade e completude das especificações de API
• Gerenciamento de contratos de interface entre provedores e consumidores de serviços

Através do gateway de API fornecido pela EFPF, as 30 empresas da aliança podem fornecer, obter e trocar vários tipos de dados por meio de API e, com base nisso, realizar gerenciamento de direitos e controle de segurança de API.

XPeng Motors Usa APISIX para Construir o Cockpit Inteligente

A XPeng Motors é uma empresa automotiva de referência entre as novas forças de fabricação de carros da China. Desde sua fundação, ela insiste em pesquisa e desenvolvimento independente em "carros inteligentes", investindo 20% em P&D, a maior proporção em comparação com a Li Auto Inc. e a Nio Inc.

Tem sido controverso se o software e hardware dos carros precisam ser desenvolvidos de forma independente pelas montadoras. Muitos acreditam que as montadoras só precisam se concentrar na integração, pois não é rentável investir muito dinheiro e tempo em autodesenvolvimento. No entanto, de outro ponto de vista, o autodesenvolvimento de software e hardware pode realizar uma experiência de usuário unificada e perfeita dos produtos e manter uma posição vantajosa nas iterações posteriores após o acúmulo de experiência.

Tomando o "cockpit inteligente" da XPeng Motors como exemplo, vamos apresentar o papel do Apache APISIX nele.

No controlador central com tela sensível ao toque da XPeng Motors, os usuários precisam estar conectados à Internet para operar e usar todas as funções, incluindo reconhecimento e controle de voz, mapas e navegação, música, filmes, etc., cujas APIs são processadas através do Apache APISIX.

Para as aplicações e serviços da IoV, não haverá alta concorrência e tráfego pesado, como Weibo, WeChat e outros produtos da Internet, com maior ênfase na estabilidade e baixa latência. Quando serviços críticos como reconhecimento de voz e navegação estão fora do ar e atrasados, os usuários atribuiriam isso a um problema da XPeng Motors, reduzindo significativamente a satisfação e a experiência do usuário.

Além disso, a XPeng Motors também precisa desenvolver mais transmissão e análise de dados, conectando o "cérebro" da nuvem com o do carro:

1. Tornar a condução mais segura: Os dados subjacentes do carro, como hábitos de direção, velocidade, vida útil da bateria, carga da bateria, pressão dos pneus, etc., juntamente com dados em tempo real, como temperatura, clima e congestionamento das estradas, podem ser combinados para melhorar a segurança da condução do carro;

2. Tornar a condução mais confortável: As funções de assistência à condução, OTA, estacionamento automático, etc., são inseparáveis do processamento de dados em tempo real e da análise de big data acumulados em segundo plano.

Para tornar a apresentação das funções acima mais perfeita, é necessário garantir a disponibilidade e a baixa latência do serviço no nível técnico, no qual os carros inteligentes estão atualmente trabalhando.

Antes de usar o Apache APISIX, sob a função de cockpit inteligente da XPeng Motors, a sequência de execução de uma API emitida a partir do carro era: API do Cliente -> SLB (Server Load Balancer) da Alibaba Cloud (camada 4) -> NGINX (camada 7) -> Zuul -> Serviço.

O lado esquerdo da imagem acima representa o lado do cliente da XPeng Motors. Existem três fontes principais de solicitações do cliente: clientes comuns de carros, páginas da web ou navegadores da Internet e aplicativos oficiais da XPeng ou outros aplicativos e mini-programas.

Em seguida, o tráfego coletado passará pelo módulo do operador e será enviado para o SLB da sala de computadores interna para encaminhamento padrão do protocolo de camada 4. Podemos considerar isso como uma porta de recebimento de dados de tráfego, transformando o tráfego para o primeiro NGINX, o segundo NGINX e, finalmente, para o Zuul para processamento.

Essa arquitetura rapidamente encontrou problemas:

1. As solicitações de API passam por dois gateways de API, NGINX e Zuul, aumentando um tempo de salto no processo de transmissão da API. No entanto, cada ajuste afeta a disponibilidade do serviço e o desempenho de latência.

2. Quando essa função é usada para desenvolvimento secundário para integração com o sistema interno da empresa, o NGINX precisa ser desenvolvido usando módulos C, enquanto o Zuul é em Java. A diferença de linguagem aumentará o ciclo de desenvolvimento e os custos incrementais para manutenção posterior.

3. Após a atualização da rota e do certificado SSL, o NGINX precisa ser reiniciado. Além disso, haverá um período de indisponibilidade para os serviços, afetando a apresentação dos serviços até certo ponto.

Além disso, como um componente fundamental, o API Gateway também é um dos componentes que precisam ser mantidos pela equipe de infraestrutura da XPeng Motors. Levando em consideração alguns dos pontos de dor atuais no nível funcional, a XPeng Motors espera encontrar um projeto com uma comunidade ativa, iteração de longo prazo e desenvolvimento saudável, a fim de reduzir os custos de uso e manutenção de seus próprios negócios no nível arquitetônico.

Após usar o APISIX, sua arquitetura foi ajustada, conforme mostrado abaixo.

Pode-se ver que o fluxo de processamento da cena mudou após o uso do APISIX. A sequência de execução de uma API emitida a partir do carro foi alterada para: API do Cliente -> SLB da Alibaba Cloud (camada 4) -> APISIX (camada 7) -> Serviço.

Como visto na mudança da ordem de execução, o segundo NGINX e o Zuul no fluxo de processamento anterior foram substituídos pelo APISIX, então o link só precisa passar por 4 componentes para processamento.

O APISIX-DP desempenha dois papéis na nova arquitetura. O primeiro papel é atuar como um Ingress do K8s, funcionando como a entrada e saída de tráfego; o segundo é atuar como um gateway de microsserviços. Então você pode se perguntar: por que mantemos um NGINX no novo processo? Ele é usado principalmente para distribuir o tráfego relacionado, identificar o gateway de API de microsserviço correspondente e, em seguida, enviá-lo para o Serviço.

No nível prático da XPeng Motors, o novo processo ajuda a XPeng Motors a abrir vários componentes por meio do APISIX. A vantagem de fazer isso é que ele coloca requisitos mais altos para produtos de gateway, que exigem não apenas forte estabilidade, mas também suporte para todos os sistemas de microsserviços internamente. Além disso, do nível do usuário, essa conexão torna o gerenciamento de tráfego mais unificado dentro do serviço, encurtando o link de comunicação geral enquanto reduz a latência.

Portanto, a adoção do APISIX traz mais possibilidades para a infraestrutura da XPeng Motors no nível técnico:

1. O Apache APISIX pode se conectar a mais componentes de registro e descoberta de serviços, permitindo ajustes mais flexíveis na migração e arquitetura de vários sistemas internos.
2. O APISIX tem um plug-in MQTT que pode lidar com solicitações de terminais IoT.
3. A arquitetura e o ecossistema do APISIX são mais nativos da nuvem, o que é mais amigável para arquiteturas multi-nuvem e híbridas no futuro, e está alinhado com o plano de longo prazo da empresa para evolução tecnológica.

No futuro, o Apache APISIX pode não apenas ajudar a XPeng Motors a lidar com o tráfego de API norte-sul, mas também com mais tráfego, como dispositivos IoT, Ingress do K8s e malhas de serviço, para reduzir a complexidade e os custos de manutenção da infraestrutura.

Geely Auto Coordena o Gerenciamento de Tráfego Global com Base no Apache APISIX

A Geely Auto é uma fabricante de automóveis de propriedade privada estabelecida em 1996, cujo principal negócio é a fabricação e distribuição de automóveis e peças automotivas. A Geely Auto começou a usar o APISIX no ambiente de produção cerca de um ano após o Apache APISIX ser aberto ao público.

Nos cenários de uso da Geely, o APISIX é usado principalmente para implementar alguns negócios no cenário de gateway de microsserviços. Como mostrado na figura abaixo, algumas funções relacionadas são desenvolvidas e usadas internamente pela Geely.

A aplicação atual do APISIX pela Geely é principalmente para o gerenciamento de tráfego interno dentro da empresa, com foco em gateways de API para microsserviços.

Ao usar o APISIX, a Geely comercializou suas APIs internas para realizar a desacoplamento e a assinatura mútua de serviços entre produtores e consumidores, cujo monitoramento ou gerenciamento unificado precisa ser realizado.

Com o aumento gradual do tipo e escala de negócios, a distribuição global da Geely se tornou mais ampla. Assim, alguns processamentos de tráfego global ou algumas solicitações entre salas de computadores de DC começaram a aparecer.

Nesse caso, qual é o papel do APISIX?

Externamente, a solicitação do usuário primeiro chega à rede pública para acessar o nó mais próximo, como o Cluster A. No entanto, por exemplo, quando o nó está indisponível ou ocorrem alguns problemas relacionados à soberania de dados, descobre-se que o Cluster A pode não ser capaz de processar a solicitação atual do usuário. Com base nas duas situações acima, a Geely implementou internamente uma rede de várias camadas, como mostrado na figura acima.

Essa arquitetura de rede de várias camadas é usada para alcançar a governança de tráfego global e realizar o agendamento entre clusters, realizando assim a liberação canário e a alta disponibilidade de cenários de soberania de dados de vários países ou entre salas de máquinas.

Horizon Robotics Implementa Invocação e Autenticação de Serviços Multi-Nuvem com Base no APISIX

A Beijing Horizon Robotics Technology R&D Co., Ltd. está principalmente envolvida na pesquisa e desenvolvimento de chips de IA de borda e possui capacidades líderes em algoritmos de inteligência artificial e design de chips.

Como a única que alcançou a produção em massa de chips de inteligência artificial de grau automotivo, a Horizon Robotics está comprometida em promover a inovação e o desenvolvimento da indústria automotiva por meio do empoderamento de tecnologias subjacentes.

Para uma empresa de IA em rápido crescimento, é crucial garantir a amizade com a gestão de negócios e a operação estável, onde o gateway atua como o primeiro ponto de verificação.

Devido a alguns problemas insolúveis no gateway anterior, a Horizon re-selecionou o gateway e finalmente escolheu o Apache APISIX Ingress Controller como o gateway de tráfego da empresa para fornecer serviços de forma uniforme.

A seleção do APISIX Ingress é baseada principalmente nos seguintes pontos:

• Plugins abundantes: O Apache APISIX possui um grande ecossistema de plugins. Todos os plugins suportados pelo APISIX podem usar apisix-ingress-controller para configuração declarativa e podem personalizar plugins para um único backend sob ApisixRoute.

• Configuração visual: Você pode ver cada apisix route com o APISIX Dashboard. Se o mesmo domínio for configurado em vários namespace ou vários arquivos yaml, você pode pesquisar pelo prefixo path no APISIX Dashboard para localizá-lo rapidamente quando ocorrer um conflito.

• Verificação granular: O APISIX Ingress Controller verificará os recursos declarados pelo CRD que ele gerencia. Se um Serviço inexistente for declarado no CRD, a mensagem de erro será armazenada no event de ApisixRoute. A operação errada não terá efeito, reduzindo alguns problemas causados por erros de operação até certo ponto.

• Funções ricas: O APISIX suporta recarregamento a quente e plugins a quente, reescrita de solicitações de proxy, autenticação multifator, desenvolvimento de plugins em várias linguagens e muito mais. Para mais funções, consulte Funções do APISIX.

• Comunidade ativa: Comparado com outras comunidades, o APISIX tem muitos desenvolvedores ativos e uma resposta rápida a Issues no GitHub.

• Alto desempenho: A partir da figura abaixo, pode-se ver que, no teste de estresse comparado com o Envoy, o desempenho do APISIX é cerca de 120% do do Envoy. Quanto mais núcleos houver, mais significativa será a diferença em QPS.

Aplicação da Arquitetura

Como visto no diagrama de arquitetura abaixo, o APISIX Ingress atua como uma entrada de tráfego total.

Em outras palavras, seja um sistema de gerenciamento de dados, sistema de análise de problemas, ferramenta de linha de comando, Web, plataforma SaaS ou OpenAPI, todo o tráfego de acesso entra no upstream (Serviços de Negócios) através do APISIX Ingress.

Como a empresa possui um serviço de autenticação especial, ela usa diretamente o plugin forward-auth do Apache APISIX para realizar autenticação externa.

Na camada do gateway, todo o tráfego entra através do domínio de acesso. Nesse momento, o tráfego passará primeiro pelo LVS (Linux Virtual Server), e então o LVS o encaminhará para os nós APISIX de backend. Finalmente, o APISIX distribuirá o tráfego de acordo com as regras de roteamento e o entregará ao Pod correspondente.

Para permitir que o LVS aponte diretamente para o APISIX Ingress, a porta padrão do APISIX Ingress foi alterada de 9180 para 80, o que pode encaminhar e processar o tráfego mais facilmente.

Aplicação Prática

Em uma chamada de serviço em um ambiente multi-nuvem, algum tráfego de negócios chegará primeiro ao IDC (Internet Data Center) local e, em seguida, ao Pod através do APISIX Ingress. Além disso, alguns serviços acessarão os serviços da Alibaba Cloud através de domínios, e em alguns cenários, haverá serviços relacionados a chamadas entre serviços.

Isso envolve principalmente treinamento multi-nuvem. Os usuários usarão o IDC como a entrada e poderão enviar tarefas para o cluster de nuvem correspondente após selecionar o cluster.

Quando a Horizon Robotics começou a usar o Apache APISIX Ingress, o Apache APISIX não suportava o plugin forward-auth, então a Horizon personalizou um plugin baseado em apisix-go-plugin-runner.

No entanto, isso adicionou uma camada de chamadas gRPC, o que tornou a depuração mais difícil, pois muitos logs não podiam ser vistos. No início deste ano, o Apache APISIX passou a suportar o plugin forward-auth. Então, a Horizon Robotics substituiu o plugin personalizado pelo oficial, o que reduziu uma camada de chamadas gRPC, contribuindo para um monitoramento mais conveniente.

Resumo

No contexto de "carros definidos por software", a API7.ai ajuda empresas automotivas, como a XPeng Motors, Geely Auto e Horizon Robotics, a gerenciar melhor a conexão e os dados da Internet dos Veículos, fornecendo aos clientes serviços mais estáveis e produtos de iteração mais rápida.

Se você tiver necessidades semelhantes, visite nosso site https://api7.ai/contact.