API Gateway Solutions for Automotive Industry
Under the wave of digitalization and intelligentization, the manufacturing and automotive industries are facing unprecedented opportunities and challenges. Cars are no longer a mechatronic product for transportation but a third space besides home and company. Cars have evolved to be more intelligent with deep software and hardware integration.
From consumers’ perspective, maneuverability and safety have become the standard configuration of automobiles. Everyone has higher requirements for cars, an industrial product that has existed for more than 100 years: intelligent automobiles. This is reflected in driver assistance but also in OTA (Over-the-air) programming, voice control, touch screen central controller, etc., which requires higher demands for real-time data processing, computing power, and product iteration of automotive software.
From the business applications perspective, IoV (the Internet of Vehicles) and upstream and downstream data are becoming increasingly complex. As a result, breaking the information silo, opening up data from different systems, and accelerating business innovation have become pain points for manufacturing and auto companies.
From the technological change perspective, cloud-native and open-source software bring technical support to manufacturing and car companies to accelerate digital transformation. These companies can seize the opportunity in the conversion by making good use of cloud-native technologies.
Today, more than 5,000 chips are in an electric car with the driver assistance function, running hundreds of millions of lines of code. The new era of “Software Defined Vehicles (SDV)” is gradually around the corner.
Through analysis of the statistics and research of the Apache APISIX open-source community, we found that Apache APISIX is widely used in the Fourth Industrial Revolution, covering digital factory, smart vehicles, AI chips, autonomous driving, microservices governance on automotive enterprises, auto finance, automotive B2B sales, used car for B2C sales, and other fields.
Below are some examples:
- Digital Factory: European Factory Platform
- Car Companies: Geely Auto, XPeng Motors, BeyonCa Autos
- AI & Autonomous Driving: Horizon Robotics, Momenta
- Auto Finance: BMW Financial Services
- Speech Recognition: AiSpeech
- Car Transactions: Dasouche, Yiche, Youxinpai
- Driver Training: Jiakaobaodian
- Getting Around: Dida Chuxing, Yunmanman
As a cloud-native API gateway, Apache APISIX is a fundamental component that can process API requests from various terminals like cars, IoT devices, mobile apps, etc. The widespread use of Apache APISIX in automotive-related industries is also driving open-source projects to iterate forward to meet the needs of more enterprise users.
We will provide accumulated industry solutions through API7 Enterprise and API7 Cloud. Welcome to contact us: https://api7.ai/contact.
Following, let’s figure out how API Gateway and Apache APISIX help enterprise users solve practical problems through a few typical use cases.
European Factory Platform Uses APISIX as Its Security Gateway
EFPF (European Factory Platform) is a federation of digital manufacturing platforms (DMPs) funded by the European Commission’s Horizon 2020 program. The union contains 30 companies and organizations from 10 European countries, including Siemens, Airbus SE, research institutes and universities, etc. It provides innovative solutions from Industry 4.0, IoT, artificial intelligence, big data, and digital manufacturing.
EFPF provides a range of tools and services, many of which provide one or more APIs that other tools and services can use. The EFPF platform can monitor, control, and analyze API usage using API Gateway. Additionally, API Gateway allows policies to define how users interact with APIs exposed by different companies in the platform.
The API Management Tool or API Security Gateway (ASG) used in the EFPF platform is a component in Data Spine. ASG is the border gateway for all API calls and provides externally exposed services available in the EFPF ecosystem. While acting as a proxy service, it also enforces security policies on ongoing service calls. In EFPF, ASG is implemented using Apache APISIX.
Here are several reasons to choose Apache APISIX:
- Speed: As the ASG will proxy calls from the Data Spine to other platforms in the ecosystem, the latency for the calls is minimized.
- Custom Plugins: The ASG should depend on minimal code/configuration to develop custom security plugins.
- License: A permissive license (Apache / MIT) is preferred for the implementation of the ASG.
- Support for MQTT.
In addition to this, the following issues of API management are also addressed:
- API configuration, lifecycle management, and service discovery
- Uniformity and completeness of API specifications
- Interface contract management between service providers and consumers
Through the API gateway provided by EFPF, the 30 companies in the alliance can provide, obtain and exchange various types of data through API and, on this basis, conduct API rights management and security control.
XPeng Motors Uses APISIX to Build Smart Cockpit
XPeng Motors is a benchmark car company among China’s new car manufacturing forces. Since its establishment, it has insisted on independent research and development in “smart cars”, investing 20% in research and development, the highest proportion compared with Li Auto Inc. and Nio Inc.
It has been controversial whether the software and hardware of cars need to be independently developed by car companies. Many believe those car companies only need to focus on integration because it is not a cost-effective way to invest a lot of money and time in self-development. However, from another point of view, the self-development of software and hardware can realize a unified and perfect user experience of the products and maintain an advantageous position in the later iterations after experience accumulation.
Taking the “smart cockpit” featured by XPeng Motors as an example, let’s introduce the role of Apache APISIX in it.
On XPeng Motors’ touch screen central controller, users need to be connected to the Internet to operate and use all functions, including speech recognition and control, maps and navigation, music, movies, etc., the APIs behind which are processed through Apache APISIX.
For the applications and services of the IoV, there will not be high concurrency and heavy traffic, such as Weibo, WeChat, and other Internet products, laying more emphasis on stability and low latency. When critical services such as speech recognition and navigation are out of order and delayed, users would attribute it to XPeng Motors’ problem, significantly reducing user satisfaction and experience.
Moreover, XPeng Motors also needs to develop more data transmission and analysis, connecting the “brain” of the cloud with that of the car:
Make driving safer: The underlying car data, such as driving habits, speed, battery life, battery power, tire pressure, etc., together with real-time data such as temperature, weather, and road congestion, can be combined to improve the safety of car driving;
Make driving more comfortable: The functions of assisted driving, OTA, automatic parking, etc., are inseparable from the processing of real-time data and the analysis of big data accumulated in the background.
In order to make the presentation of the above functions more perfect, it is necessary to ensure the availability and low latency of the service at the technical level, which smart cars are currently working on.
Before using Apache APISIX, under the smart cockpit function of XPeng Motors, the execution sequence of an API issued from the car machine is Client API -> Alibaba Cloud SLB (Server Load Balancer) (layer 4) -> NGINX (layer 7) -> Zuul -> Service.
The far left of the above picture represents the client side of XPeng Motors. There are three primary sources of client requests: ordinary car clients, web pages or browsers from the Internet, and XPeng official apps or other apps and mini-programs.
Then the collected traffic will eventually pass through the operator module and then be sent to the SLB of the internal self-built computer room for standard four-layer protocol forwarding. We can take this as a receiving port for traffic data, transforming traffic to the first NGINX, the second NGINX, and finally to Zuul for processing.
This architecture quickly ran into problems:
API requests go through two API gateways, NGINX and Zuul, increasing one jump time in the API transmission process. However, each adjustment affects the service availability and latency performance.
When this function is used for secondary development to dock with the company’s internal system, NGINX needs to be developed using C modules, while Zuul is in Java. The language difference will increase the development cycle and incremental costs for post-maintenance.
After updating the route and SSL certificate, NGINX needs to be restarted. Besides, there will be an unavailable gap period for services, affecting the presentation of services to a certain extent.
In addition, as a fundamental component, API Gateway is also one of the components that need to be maintained by the XPeng Motors infrastructure team. Taking into account some of the current pain points at the functional level, XPeng Motors hopes to find a project with an active community, long-term iteration, and healthy development so as to reduce the use and maintenance costs of its own business at the architectural level.
After using APISIX, their architecture was adjusted, as shown below.
It can be seen that the processing flow of the scene has changed after using APISIX. The execution sequence of an API issued from the car is changed to the following: Client API -> Alibaba Cloud SLB (layer 4) -> APISIX (layer 7) -> Service.
As seen from the change of execution order, the second NGINX and Zuul on the previous processing flow were replaced by APISIX, so the link only needs to go through 4 components for processing.
APISIX-DP plays two roles in the new architecture. The first role is to act as a K8s Ingress working as the traffic entry and exit; the second is to act as a microservice gateway. Then you may wonder: why do we keep an NGINX in the new process? It is mainly used to distribute related traffic, identify the corresponding microservice API gateway, and then send it to the Service.
At the practical level of XPeng Motors, the new process helps XPeng Motors to open up various components by APISIX. The advantage of doing this is that it puts forward higher requirements for gateway products, which require not only strong stability but also support for all the microservice systems internally. Furthermore, from the user level, this connection makes more unified traffic management within the service, shortening the overall communication link while reducing the latency.
Therefore, adopting APISIX brings more possibilities to the infrastructure of XPeng Motors at the technical level:
- Apache APISIX can connect to more registration and service discovery components, allowing more flexible adjustments of multiple internal systems’ migration and architecture.
- APISIX has an MQTT plug-in that can handle requests from IoT terminals.
- The architecture and ecosystem of APISIX are more cloud-native, which is more friendly to multi-cloud and hybrid-cloud architecture in the future, and keeps in line with the company’s long-term plan for technological evolution.
In the future, Apache APISIX can not only help XPeng Motors handle north-south API traffic but also handle more traffic, such as IoT devices, K8s Ingress, and service meshes, to reduce infrastructure complexity and maintenance costs.
Geely Auto Coordinates Global Traffic Management Based on Apache APISIX
Geely Auto is a privately-owned automobile manufacturer established in 1996, whose primary business is manufacturing and distributing automobiles and auto parts. Geely Auto started to use APISIX in the production environment about a year after Apache APISIX was open-sourced.
In Geely’s usage scenarios, APISIX is mainly used to implement some businesses in the microservice gateway scenario. As shown in the following figure, some related functions are developed and used internally by Geely.
Geely’s current application of APISIX is mainly for internal traffic management within the company, focusing on API gateways for microservices.
By using APISIX, Geely marketized its internal APIs to realize the decoupling and mutual subscription of services between producers and consumers, the unified monitoring or management of which needs to be carried out.
With the gradually increased business type and scale, Geely’s global distribution became wider. Thus, some global traffic processing or some requests across DC computer rooms began to appear.
In this case, what role does APISIX play?
Externally, the user’s request first comes to the public network to access the nearest node, such as Cluster A. Nevertheless, for example, when the node is unavailable, or some problems related to data sovereignty occur, it is found that Cluster A may not be able to process the user’s current request. Based on the above two situations, Geely has internally implemented a multi-layer network, as shown in the figure above.
This multi-layer network architecture is used to achieve global traffic governance and perform cross-cluster scheduling, thus realizing canary release and high availability of multi-country data sovereignty or cross-machine room scenarios.
Horizon Robotics Implements Multi-Cloud Service Invocation and Authentication based on APISIX
Beijing Horizon Robotics Technology R&D Co., Ltd. is mainly engaged in the research and development of edge AI chips and has leading artificial intelligence algorithms and chip design capabilities.
As the only one that has achieved mass production of automotive-grade artificial intelligence chips, Horizon Robotics is committed to promoting the innovation and development of the automotive industry through the empowerment of underlying technologies.
For a fast-growing AI company, it is crucial to ensure friendliness to business management and stable operation where the gateway stands as the first checkpoint.
Due to some unsolvable problems in the previous gateway, Horizon re-selected the gateway and finally chose Apache APISIX Ingress Controller as the company’s traffic gateway to provide services uniformly.
The selection of APISIX Ingress is mainly based on the following points:
Abundant plugins: Apache APISIX has a great plugin ecosystem. All plugins supported by APISIX can use
apisix-ingress-controllerfor declarative configuration and can customize plugins for a single
Visual configuration: You can see each
apisix routewith APISIX Dashboard. If the same domain name is configured in multiple
yamlfiles, you can search for the prefix
pathin the APISIX Dashboard to locate it quickly when a conflict occurs.
Fine-grained verification: APISIX Ingress Controller will verify the resources declared by the CRD it manages. If a non-existent Service is declared in the CRD, the error message will be stored in the
ApisixRoute. The wrong operation won’t take effect, reducing some problems caused by misoperation to a certain extent.
Rich functions: APISIX supports hot reloading and hot plugins, proxy request rewriting, multi-factor authentication, multi-language plugin development, and so on. For more functions, please refer to APISIX functions.
Active community: Compared with other communities, APISIX has many active developers and a quick response to GitHub Issues.
High performance: From the figure below, it can be seen that in the stress testing compared with Envoy, the performance of APISIX is about 120% of that of Envoy. The more cores there are, the more significant the difference in QPS.
As seen from the architecture diagram below, APISIX Ingress acts as a full-traffic entrance.
In other words, whether it is a data management system, problem analysis system, command-line tool, Web, SaaS platform, or OpenAPI, all access traffic enters the upstream (Business Services) through APISIX Ingress.
As the company has a special authentication service, it directly uses Apache APISIX’s
forward-auth plugin to realize external authentication.
At the gateway layer, all traffic enters through the access domain name. At this time, the traffic will first pass through the LVS (Linux Virtual Server), and then the LVS will forward it to the backend APISIX nodes. Finally, APISIX will distribute the traffic according to the routing rules and deliver it to the corresponding Pod.
In order to allow LVS to point to APISIX Ingress directly, the default port of APISIX Ingress was changed from 9180 to 80, which can more easily forward and process traffic.
In a service call in a multi-cloud environment, some business traffic will first reach the local IDC (Internet Data Center) and then reach the Pod through the APISIX Ingress. Additionally, some services will access Alibaba Cloud services through domain names, and in some scenarios, there will be services related to calls between services.
It mainly involves multi-cloud training. Users will use the IDC as the entry, and they can submit tasks to the corresponding cloud cluster after selecting the cluster.
When Horizon Robotics first started to use Apache APISIX Ingress, Apache APISIX did not support the
forward-auth plugin, so Horizon customized a plugin based on
However, this added a layer of gRPC calls, which made debugging more difficult as many logs could not be seen. At the beginning of this year, Apache APISIX supported the
forward-auth plugin. Then Horizon Robotics replaced the customized plugin with the official one, which reduced one layer of gRPC calls, contributing to more convenient monitoring.
In the context of “software-defined cars”, API7.ai helps automotive companies, like XPeng Motors, Geely Auto, and Horizon Robotics, better manage the connection and data of the Internet of Vehicles, providing customers with more stable services and faster iterative products.
If you have similar needs, please visit our website https://api7.ai/contact.