Решения API Gateway для автомобильной промышленности

В условиях волны цифровизации и интеллектуализации, производственная и автомобильная отрасли сталкиваются с беспрецедентными возможностями и вызовами. Автомобили больше не являются просто мехатронным продуктом для транспортировки, а становятся третьим пространством после дома и работы. Автомобили эволюционируют, становясь более интеллектуальными с глубокой интеграцией программного и аппаратного обеспечения.

С точки зрения потребителей, управляемость и безопасность стали стандартной конфигурацией автомобилей. Каждый предъявляет более высокие требования к автомобилям — промышленному продукту, существующему уже более 100 лет: интеллектуальным автомобилям. Это проявляется не только в помощи водителю, но и в OTA (Over-the-air) программировании, голосовом управлении, сенсорном центральном контроллере и т.д., что требует более высоких требований к обработке данных в реальном времени, вычислительной мощности и итерации программного обеспечения автомобилей.

С точки зрения бизнес-приложений, IoV (Интернет автомобилей) и данные из верхнего и нижнего уровней становятся все более сложными. В результате, устранение информационных барьеров, открытие данных из различных систем и ускорение бизнес-инноваций стали болевыми точками для производственных и автомобильных компаний.

С точки зрения технологических изменений, облачные и открытые исходные коды программного обеспечения предоставляют техническую поддержку для производственных и автомобильных компаний, чтобы ускорить цифровую трансформацию. Эти компании могут воспользоваться возможностями в процессе преобразования, эффективно используя облачные технологии.

Сегодня в электромобиле с функцией помощи водителю используется более 5000 чипов, выполняющих сотни миллионов строк кода. Новая эра "Программно-определяемых автомобилей (SDV)" постепенно приближается.

Анализируя статистику и исследования сообщества Apache APISIX с открытым исходным кодом, мы обнаружили, что Apache APISIX широко используется в Четвертой промышленной революции, охватывая цифровые фабрики, умные автомобили, AI-чипы, автономное вождение, управление микросервисами в автомобильных предприятиях, автомобильные финансы, B2B-продажи автомобилей, продажи подержанных автомобилей B2C и другие области.

Ниже приведены некоторые примеры:

1. Цифровая фабрика: European Factory Platform
2. Автомобильные компании: Geely Auto, XPeng Motors, Lotus Cars, Li Auto, BeyonCa Autos
3. AI и автономное вождение: Horizon Robotics, Momenta
4. Автомобильные финансы: BMW Financial Services
5. Распознавание речи: AiSpeech

Как облачный API-шлюз, Apache APISIX является фундаментальным компонентом, который может обрабатывать API-запросы от различных терминалов, таких как автомобили, IoT-устройства, мобильные приложения и т.д. Широкое использование Apache APISIX в автомобильных отраслях также способствует итерации открытых проектов для удовлетворения потребностей большего числа корпоративных пользователей.

Мы предоставим накопленные отраслевые решения через API7 Enterprise и API7 Cloud. Добро пожаловать связаться с нами: https://api7.ai/contact.

Далее рассмотрим, как API Gateway и Apache APISIX помогают корпоративным пользователям решать практические задачи через несколько типичных примеров использования.

European Factory Platform использует APISIX в качестве шлюза безопасности

EFPF (European Factory Platform) — это федерация цифровых производственных платформ (DMP), финансируемая программой Horizon 2020 Европейской комиссии. Союз включает 30 компаний и организаций из 10 европейских стран, включая Siemens, Airbus SE, исследовательские институты и университеты и т.д. Он предоставляет инновационные решения в области Industry 4.0, IoT, искусственного интеллекта, больших данных и цифрового производства.

EFPF предоставляет ряд инструментов и услуг, многие из которых предоставляют один или несколько API, которые могут использовать другие инструменты и услуги. Платформа EFPF может отслеживать, контролировать и анализировать использование API с помощью API Gateway. Кроме того, API Gateway позволяет определять политики, как пользователи взаимодействуют с API, предоставляемыми различными компаниями на платформе.

Инструмент управления API или шлюз безопасности API (ASG), используемый на платформе EFPF, является компонентом в Data Spine. ASG является пограничным шлюзом для всех вызовов API и предоставляет внешние услуги, доступные в экосистеме EFPF. Выступая в качестве прокси-сервиса, он также обеспечивает соблюдение политик безопасности при вызовах сервисов. В EFPF ASG реализован с использованием Apache APISIX.

Вот несколько причин для выбора Apache APISIX:

• Скорость: Поскольку ASG будет проксировать вызовы из Data Spine на другие платформы в экосистеме, задержка для вызовов минимизирована.
• Пользовательские плагины: ASG должен зависеть от минимального кода/конфигурации для разработки пользовательских плагинов безопасности.
• Лицензия: Предпочтительна разрешительная лицензия (Apache / MIT) для реализации ASG.
• Поддержка MQTT.

Кроме того, также решаются следующие вопросы управления API:

• Конфигурация API, управление жизненным циклом и обнаружение сервисов
• Единообразие и полнота спецификаций API
• Управление интерфейсными контрактами между поставщиками и потребителями сервисов

Через API-шлюз, предоставляемый EFPF, 30 компаний в альянсе могут предоставлять, получать и обмениваться различными типами данных через API и, на этой основе, осуществлять управление правами и контроль безопасности API.

XPeng Motors использует APISIX для создания умного салона

XPeng Motors является эталонной автомобильной компанией среди новых производителей автомобилей в Китае. С момента своего основания она настаивает на независимых исследованиях и разработках в области "умных автомобилей", инвестируя 20% в исследования и разработки, что является самым высоким показателем по сравнению с Li Auto Inc. и Nio Inc.

Было спорным вопросом, нужно ли автомобильным компаниям самостоятельно разрабатывать программное и аппаратное обеспечение автомобилей. Многие считают, что автомобильным компаниям нужно сосредоточиться только на интеграции, так как инвестировать много денег и времени в самостоятельную разработку неэффективно. Однако, с другой точки зрения, самостоятельная разработка программного и аппаратного обеспечения позволяет реализовать единый и совершенный пользовательский опыт продуктов и сохранить преимущественное положение в последующих итерациях после накопления опыта.

Рассмотрим роль Apache APISIX в "умном салоне", представленном XPeng Motors.

На сенсорном центральном контроллере XPeng Motors пользователям необходимо подключение к Интернету для управления и использования всех функций, включая распознавание и управление голосом, карты и навигацию, музыку, фильмы и т.д., API которых обрабатываются через Apache APISIX.

Для приложений и сервисов IoV не будет высокой нагрузки и большого трафика, как у Weibo, WeChat и других интернет-продуктов, больше внимания уделяется стабильности и низкой задержке. Когда критически важные сервисы, такие как распознавание речи и навигация, выходят из строя или задерживаются, пользователи связывают это с проблемами XPeng Motors, что значительно снижает удовлетворенность и опыт пользователей.

Кроме того, XPeng Motors также необходимо разрабатывать больше передач и анализа данных, соединяя "мозг" облака с "мозгом" автомобиля:

1. Сделать вождение безопаснее: Основные данные автомобиля, такие как привычки вождения, скорость, заряд батареи, давление в шинах и т.д., вместе с реальными данными, такими как температура, погода и загруженность дорог, могут быть объединены для повышения безопасности вождения;

2. Сделать вождение комфортнее: Функции помощи водителю, OTA, автоматической парковки и т.д. неотделимы от обработки данных в реальном времени и анализа больших данных, накопленных в фоновом режиме.

Для того чтобы представление вышеуказанных функций было более совершенным, необходимо обеспечить доступность и низкую задержку сервиса на техническом уровне, над чем в настоящее время работают умные автомобили.

До использования Apache APISIX, под функцией умного салона XPeng Motors, последовательность выполнения API, выданного из автомобиля, была следующей: Client API -> Alibaba Cloud SLB (Server Load Balancer) (уровень 4) -> NGINX (уровень 7) -> Zuul -> Service.

Слева на изображении выше представлена клиентская сторона XPeng Motors. Существует три основных источника клиентских запросов: обычные клиенты автомобилей, веб-страницы или браузеры из Интернета, а также официальные приложения XPeng или другие приложения и мини-программы.

Затем собранный трафик в конечном итоге проходит через модуль оператора и отправляется на SLB внутреннего серверного помещения для стандартной пересылки на уровне 4. Мы можем рассматривать это как порт приема данных трафика, преобразуя трафик в первый NGINX, второй NGINX и, наконец, в Zuul для обработки.

Эта архитектура быстро столкнулась с проблемами:

1. API-запросы проходят через два API-шлюза, NGINX и Zuul, что увеличивает время одного перехода в процессе передачи API. Однако каждое изменение влияет на доступность сервиса и производительность задержки.

2. Когда эта функция используется для вторичной разработки для интеграции с внутренней системой компании, NGINX необходимо разрабатывать с использованием C-модулей, а Zuul — на Java. Разница в языках увеличивает цикл разработки и дополнительные затраты на последующее обслуживание.

3. После обновления маршрута и SSL-сертификата NGINX необходимо перезапустить. Кроме того, будет период недоступности сервисов, что в определенной степени влияет на представление сервисов.

Кроме того, как фундаментальный компонент, API Gateway также является одним из компонентов, которые необходимо поддерживать инфраструктурной команде XPeng Motors. Учитывая некоторые текущие болевые точки на функциональном уровне, XPeng Motors надеется найти проект с активным сообществом, долгосрочной итерацией и здоровым развитием, чтобы снизить затраты на использование и обслуживание собственного бизнеса на архитектурном уровне.

После использования APISIX их архитектура была изменена, как показано ниже.

Видно, что процесс обработки сцены изменился после использования APISIX. Последовательность выполнения API, выданного из автомобиля, изменилась на следующую: Client API -> Alibaba Cloud SLB (уровень 4) -> APISIX (уровень 7) -> Service.

Как видно из изменения порядка выполнения, второй NGINX и Zuul на предыдущем процессе обработки были заменены на APISIX, поэтому ссылка теперь проходит только через 4 компонента для обработки.

APISIX-DP играет две роли в новой архитектуре. Первая роль — это K8s Ingress, работающий как вход и выход трафика; вторая — это микросервисный шлюз. Тогда может возникнуть вопрос: почему мы оставляем NGINX в новом процессе? Он в основном используется для распределения связанного трафика, идентификации соответствующего микросервисного API-шлюза и затем отправки его в Service.

На практическом уровне XPeng Motors новый процесс помогает XPeng Motors открыть различные компоненты через APISIX. Преимущество этого заключается в том, что он предъявляет более высокие требования к продуктам шлюза, которые требуют не только высокой стабильности, но и поддержки всех микросервисных систем внутри. Кроме того, на уровне пользователя это соединение делает управление трафиком внутри сервиса более единым, сокращая общую связь и уменьшая задержку.

Таким образом, внедрение APISIX приносит больше возможностей для инфраструктуры XPeng Motors на техническом уровне:

1. Apache APISIX может подключаться к большему количеству компонентов регистрации и обнаружения сервисов, позволяя более гибко настраивать миграцию и архитектуру нескольких внутренних систем.
2. APISIX имеет плагин MQTT, который может обрабатывать запросы от IoT-терминалов.
3. Архитектура и экосистема APISIX более облачные, что более дружелюбно к мультиоблачной и гибридной архитектуре в будущем и соответствует долгосрочному плану компании по технологической эволюции.

В будущем Apache APISIX сможет не только помочь XPeng Motors обрабатывать северо-южный трафик API, но и обрабатывать больше трафика, таких как IoT-устройства, K8s Ingress и сервисные сетки, чтобы снизить сложность инфраструктуры и затраты на обслуживание.

Geely Auto координирует глобальное управление трафиком на основе Apache APISIX

Geely Auto — это частный производитель автомобилей, основанный в 1996 году, основным бизнесом которого является производство и распределение автомобилей и автозапчастей. Geely Auto начала использовать APISIX в производственной среде примерно через год после открытия исходного кода Apache APISIX.

В сценариях использования Geely, APISIX в основном используется для реализации некоторых бизнесов в сценарии микросервисного шлюза. Как показано на следующем рисунке, некоторые связанные функции разрабатываются и используются внутри Geely.

Текущее применение APISIX в Geely в основном сосредоточено на внутреннем управлении трафиком внутри компании, уделяя внимание API-шлюзам для микросервисов.

Используя APISIX, Geely коммерциализировала свои внутренние API, чтобы реализовать развязку и взаимную подписку сервисов между производителями и потребителями, что требует единого мониторинга или управления.

С постепенным увеличением типа и масштаба бизнеса, глобальное распределение Geely стало шире. Таким образом, начали появляться некоторые глобальные обработки трафика или запросы через дата-центры.

В этом случае, какую роль играет APISIX?

Внешне, запрос пользователя сначала поступает в публичную сеть для доступа к ближайшему узлу, например, Cluster A. Однако, например, когда узел недоступен или возникают проблемы, связанные с суверенитетом данных, обнаруживается, что Cluster A может не обработать текущий запрос пользователя. На основе вышеуказанных двух ситуаций, Geely реализовала многоуровневую сеть, как показано на рисунке выше.

Эта многоуровневая сетевая архитектура используется для достижения глобального управления трафиком и выполнения кросс-кластерного планирования, тем самым реализуя канареечные выпуски и высокую доступность в сценариях многостранового суверенитета данных или кросс-машинных комнат.

Horizon Robotics реализует вызов и аутентификацию мультиоблачных сервисов на основе APISIX

Beijing Horizon Robotics Technology R&D Co., Ltd. в основном занимается исследованиями и разработками AI-чипов для периферийных устройств и обладает передовыми алгоритмами искусственного интеллекта и возможностями проектирования чипов.

Как единственная компания, которая достигла массового производства автомобильных AI-чипов, Horizon Robotics стремится способствовать инновациям и развитию автомобильной промышленности через усиление базовых технологий.

Для быстрорастущей AI-компании крайне важно обеспечить дружелюбие к управлению бизнесом и стабильную работу, где шлюз стоит на первом этапе проверки.

Из-за некоторых нерешаемых проблем в предыдущем шлюзе, Horizon повторно выбрала шлюз и в итоге выбрала Apache APISIX Ingress Controller в качестве шлюза трафика компании для предоставления услуг единообразно.

Выбор APISIX Ingress в основном основан на следующих моментах:

• Богатые плагины: Apache APISIX имеет отличную экосистему плагинов. Все плагины, поддерживаемые APISIX, могут использовать apisix-ingress-controller для декларативной конфигурации и могут настраивать плагины для одного backend под ApisixRoute.

• Визуальная конфигурация: Вы можете видеть каждый apisix route с помощью APISIX Dashboard. Если один и тот же домен настроен в нескольких namespace или нескольких yaml файлах, вы можете искать префикс path в APISIX Dashboard, чтобы быстро найти его при возникновении конфликта.

• Тонкая проверка: APISIX Ingress Controller будет проверять ресурсы, объявленные CRD, которыми он управляет. Если в CRD объявлен несуществующий Service, сообщение об ошибке будет сохранено в event ApisixRoute. Неправильная операция не вступит в силу, что в определенной степени снижает некоторые проблемы, вызванные ошибками.

• Богатые функции: APISIX поддерживает горячую перезагрузку и горячие плагины, перезапись прокси-запросов, многофакторную аутентификацию, разработку плагинов на нескольких языках и т.д. Для получения дополнительных функций, пожалуйста, обратитесь к функциям APISIX.

• Активное сообщество: По сравнению с другими сообществами, APISIX имеет много активных разработчиков и быстрый ответ на GitHub Issues.

• Высокая производительность: Из рисунка ниже видно, что в стресс-тестах по сравнению с Envoy, производительность APISIX составляет около 120% от Envoy. Чем больше ядер, тем больше разница в QPS.

Архитектурное применение

Как видно из архитектурной диаграммы ниже, APISIX Ingress выступает в качестве полного входа трафика.

Другими словами, будь то система управления данными, система анализа проблем, инструмент командной строки, Web, SaaS-платформа или OpenAPI, весь трафик доступа проходит через APISIX Ingress в вышестоящие (Business Services).

Поскольку у компании есть специальная служба аутентификации, она напрямую использует плагин forward-auth Apache APISIX для реализации внешней аутентификации.

На уровне шлюза весь трафик поступает через домен доступа. В этот момент трафик сначала проходит через LVS (Linux Virtual Server), а затем LVS перенаправляет его на узлы APISIX. Наконец, APISIX распределяет трафик в соответствии с правилами маршрутизации и доставляет его в соответствующий Pod.

Для того чтобы LVS мог напрямую указывать на APISIX Ingress, порт по умолчанию APISIX Ingress был изменен с 9180 на 80, что позволяет более легко перенаправлять и обрабатывать трафик.

Практическое применение

В вызове сервиса в мультиоблачной среде, некоторый бизнес-трафик сначала достигает локального IDC (Internet Data Center), а затем достигает Pod через APISIX Ingress. Кроме того, некоторые сервисы будут обращаться к сервисам Alibaba Cloud через доменные имена, а в некоторых сценариях будут сервисы, связанные с вызовами между сервисами.

В основном это связано с мультиоблачным обучением. Пользователи будут использовать IDC как вход, и они могут отправлять задачи в соответствующий облачный кластер после выбора кластера.

Когда Horizon Robotics впервые начала использовать Apache APISIX Ingress, Apache APISIX не поддерживал плагин forward-auth, поэтому Horizon разработала собственный плагин на основе apisix-go-plugin-runner.

Однако это добавило уровень gRPC-вызовов, что сделало отладку более сложной, так как многие логи не могли быть видны. В начале этого года Apache APISIX начал поддерживать плагин forward-auth. Затем Horizon Robotics заменила собственный плагин на официальный, что уменьшило один уровень gRPC-вызовов, способствуя более удобному мониторингу.

Итог

В контексте "программно-определяемых автомобилей", API7.ai помогает автомобильным компаниям, таким как XPeng Motors, Geely Auto и Horizon Robotics, лучше управлять соединением и данными Интернета автомобилей, предоставляя клиентам более стабильные сервисы и более быстрые итерации продуктов.

Если у вас есть похожие потребности, пожалуйста, посетите наш сайт https://api7.ai/contact.