As an open source cloud-native API gateway, Apache APISIX is committed to bringing better and better performance to developers and users in terms of performance and user experience, helping enterprises solve some new problems encountered in cloud-native and microservice technologies .

At the end of September, Apache APISIX released the 3.0.0-beta preview version, bringing some new functional experiences to users in advance.Today, APISIX officially released version 3.0.0, bringing the product to a new round of progress from the perspective of experience and functions. Compared with the iterative 3.0.0 official version and the previous 3.0.0-beta preview version:

• Added Consumer Group, which can manage consumers more conveniently;
• Support configuring the sequence of DNS resolution domain name types;
• Added an AI plane to analyze and present configuration and traffic more intelligently;
• More detailed optimization of multiple existing ecological plug-ins.

In addition to the detailed changes at the technical level above, there are many new functional features and ecological expansion details that will be presented below.It can be said that this iteration of the version has truly achieved “Stronger and smarter performance, wider and more diverse ecology.”

If you want to experience the official version of APISIX 3.0 immediately, you can go to the official website to download and use it immediately.

Summary of New Highlights of APISIX 3.0

1. Full support for ARM64

At present, ARM64 has become a very mainstream server architecture selection for cloud vendors. From AWS Graviton, GCP Tau T2A to Huawei Kunpeng and other products, it can be seen that various cloud vendors have begun to launch servers based on the ARM architecture.

At present, from the data point of view, the performance of Arm-based servers is slightly better than that of X86 in terms of cost performance. In order to conform to the technological trend of the times, APISIX also made a comprehensive CI regression on ARM64. To ensure that users can still run various functions smoothly when running APISIX on the ARM architecture.

2. Add gRPC client

In version 3.0, a new core.grpc module will be added. If you are familiar with NGINX and OpenResty, you know that their support for gRPC is quite limited, and they only stay on basic functions such as performing reverse proxy or load balancing. APISIX has already implemented the conversion between gRPC and HTTP protocols in the current 2.x version. In version 3.0, the new gRPC client will be added to allow developers to directly call third-party gRPC services without introducing additional components or requiring the service provider to use an additional HTTP interface, which greatly simplifies the use process change.

3. Redesign Admin API

When using APISIX at present, you may find that the response body of APISIX is mixed with a lot of meaningless data, such as some return values ​​of etcd, which are directly sent to the client without any pruning. At the same time, the current architecture design of the entire response body is not perfect, and there are some redundant fields.

In version 3.0 of APISIX, the structure of the response body has been redesigned. The new format can make the entire request format and return body more Restful, making it easier for users to use the new version of the Admin API. Of course, this process also allows parameters to be used to control which version of the Admin API is used, so there is no need to be afraid that it will not be compatible with the previous version after the upgrade.

4. DP and CP Separation

APISIX has experienced multiple security-related vulnerabilities in the past one or two years. The root cause of most of the vulnerabilities is that APISIX deploys the data plane and the control plane together in the default deployment mode. Once there is a security hole on the data plane, the attacker can directly invade the control plane through the data plane, thus affecting all other data planes.

Therefore, in version 3.0, the deployment mode configuration deployment is added, and the default attribute is traditional, that is, the data plane and the control plane are deployed together. Of course, the new configuration mode still recommends that you set the attribute to data_plane or control_plane, so as to realize the complete separation of the data plane and the control plane.

After complete separation, it can not only solve the above security risks, but also better perform functional iterations on the data plane and the control plane without affecting each other.

5. Add AI plane

In addition to the data plane and control plane, Apache APISIX has added an AI plane. Through the study and analysis of API traffic and configuration, developers and maintainers are relieved of the pressure of use and operation and maintenance. For example, the following two scenarios can be automatically optimized through the AI ​​plane:

• APIs without identity authentication are found, and risk warnings are given;
• For APIs that are only configured with plug-ins in the Access stage such as identity authentication, unnecessary stages such as logs are automatically skipped to speed up processing.

The AI ​​plane brings new possibilities to traffic processing. In the subsequent use process, things like automatic warm-up of upstream services and security threat discovery can be processed through the AI ​​plane.

6. Better service discovery support

In the current version, APISIX has supported the integration of many service discovery components, such as Zookeeper, Consul, Nacos, etc. But currently these integrations are all done on the data plane. Once you have a lot of nodes on the data plane, this will put a lot of pressure on the subsequent service discovery components.

Especially components that provide strong consistency like ETCD and ZooKeeper usually cannot bear too many connections; in addition, users also need to configure the authentication of the service discovery component for the Apache APISIX data plane. If you are using a virtual machine to deploy Apache APISIX, then you need to synchronize the authentication configuration to each instance.

At the same time, in the actual production environment of users, what they want is not only a simple integration like Consul KV or DNS integration, but also an integration with more complete functions like health check.

Therefore, in APISIX 3.0, we implemented a layer of abstraction by adding a new sub-project APISIX-SEED to realize service discovery support at the control level and reduce the pressure on service discovery components. The nodes of the backend service will be updated by the APISIX-SEED component and then synchronized to ETCD, and finally used by Apache APISIX.

7. Added xRPC framework

APISIX supports proxy TCP protocol in the current version, but sometimes, pure TCP protocol proxy is not enough. What users need is a proxy for a specific application protocol, such as Redis Proxy, Kafka Proxy, etc. Because some functions can only be realized after encoding and decoding the protocol.

Therefore, APISIX implemented a four-layer protocol extension framework called xRPC in version 3.0, allowing developers to customize specific application protocols on it. Based on xRPC, developers can encode and decode requests and responses through Lua code, and then complete fault injection, log reporting, dynamic routing and other functions on the basis of understanding the protocol content.

Based on the xRPC framework, APISIX can provide proxy implementations for several mainstream application protocols.At the same time, users can also support their own private TCP-based application protocol based on this framework, so that it has a proxy-like HTTP protocol Precise Granularity and Higher Level Seven Layers of Control . On the basis of different protocols, some common factors can be abstracted, and related plug-in capabilities can be realized, so that different protocols can share these capabilities.

8. Support more four-layer observability

APISIX has been investing a lot in observability function support, supporting almost all observability components, such as Zipkin, Apache SkyWalking, Datadog and so on. At the same time, various log components are supported, but most of these are carried out at the seventh layer (application layer).

More observability support based on layer 4 (transport layer) will be added in APISIX 3.0 version. For example, the support for Prometheus and various logs on the fourth layer is added, which not only allows users to easily observe where there is a problem in the seven-layer traffic, but also discover the operation status of the fourth-layer traffic.

9. Integrate OpenAPI specification

API is actually an element that involves development, testing, launch and the entire life cycle. In APISIX 3.0 version, the standard OpenAPI 3.0 specification will be supported.

Therefore, if you are managing the API on some API design and testing software, you can easily export and import data and place it in APISIX for management and maintenance. At the same time, various APIs in APISIX can also be exported through the OpenAPI 3.0 specification, and then imported into other systems for use.

In addition, APISIX also supports Postman-related custom formats (Postman Collection Format v2) in version 3.0 to realize data transmission between the two, making integration easier.

10. Full support for Gateway API and service mesh

In the version iteration of APISIX Ingress, the Gateway API has been supported, and the latest version 1.5 basically supports all Gateway API configurations.

Due to the limitations of the Kubernetes Ingress resource itself, many traffic management capabilities in north-south scenarios cannot be well expressed. Therefore, a large number of Ingress Controller solutions on the market provide custom CRDs, although this can help users well Manage traffic, but indirectly increase the cost of migration, almost causing users to be locked in by a certain Ingress Controller selection. Therefore, the Kubernetes community began to develop the Gateway API standard in the first two years.

Gateway API is a role-oriented layered protocol. Usually, cloud vendors like AWS and GCP will act as infrastructure providers, and they will provide several different optional gateway types (GatewayClass); and gateway administrators, usually Create different gateway instances (Gateway); upper-level developers only focus on how to create routes to expose their own APIs, and do not care about the underlying gateway details.

In this case, you can use the Gateway API to perform various configurations through APISIX Ingress, which means that you can switch between different data planes. At the end of this year, APISIX Ingress will more fully support Gateway API and support more capabilities at Layer 4 and Layer 7.

Unlike most service grid solutions, APISIX’s service grid solution has more advantages in the data plane (thanks to the high performance of APISIX itself), so in the selection of the control plane, it is more hoped to be compatible with some communities. Some mainstream programs. Finally, the method of interacting with Istio by using the xDS protocol and writing the obtained configuration to the xDS configuration center of APISIX is adopted to cooperate with APISIX to generate specific routing rules and complete the routing of corresponding requests.

This solution not only makes the entire service grid more lightweight, but also allows for more convenient secondary development and migration with the help of APISIX’s high scalability.

11. Integrate more ecology

In addition to the OpenAPI standard mentioned above, a lot of ecological plug-ins will be added in version 3.0, such as OpenFunction, ClickHouse, Elasticsearch, SAML and CAS, etc., to integrate more about authentication, security or observability Wait.

One of the interesting plug-ins workflow is about traffic scheduling. Through this plug-in, some more fine-grained processing can be performed at the flow control level.

For example, execute a certain behavior when condition A is true, execute another behavior when condition B is true, and so on. Through this clearer method, users can more conveniently schedule various business traffic.

Summarize

Whether APISIX has developed from scratch to the present, or the official version 3.0 has been launched, you will find that APISIX has not actually made too many adjustments and changes at the architectural level, but more about ecology, compatibility and product application. Change.

The judging criteria for an open source project may not only be performance and functions, but need to stand more from the perspective of users, developers and enterprises, and consider whether they can quickly and effectively solve the current pain points by using this product.

The highlights or new features mentioned in this article are actually created through the environment of the open source community and after receiving feedback from different developers or enterprise users. It is they who make open source products more practical and vibrant.

Finally, everyone is welcome to experience and give feedback on the official version of APISIX 3.0.0, and look forward to the technical charm of the technology and community.