Unsurprisingly, 2.15 will be the last minor version before Apache APISIX 3.0 is released. Since the first version 2.0 was released two years ago, APISIX has released 15 minor versions and many patch versions. As the last minor version of the 2.x series, version 2.15 can be said to be a linking version.
"Continuing" is because this version continues to introduce more functions, making the plug-in configuration more flexible; "Continuing" is because this version will be the last LTS version of the 2.x version, and the subsequent APISIX will be 3.0. The version is in progress. See below for more details!
Custom plugin priority
The new version supports user-defined plugin priorities instead of directly applying the plugin's default priority properties.
With this function, we can adjust the execution order of certain plugins on a specific route, thus breaking the shackles of the previous plugin priority properties.
For example, by default, the serverless-post-function
plugin is executed after the serverless-pre-function
plugin. But through this function, the serverless-post-function
plugin can be executed first. The configuration example is as follows:
{
"serverless-post-function": {
"_meta": {
"priority": 10000
},
"phase": "rewrite",
"functions" : ["return function(conf, ctx)
ngx.say(\"serverless-post-function\");
end"]
},
"serverless-pre-function": {
"_meta": {
"priority": -2000
},
"phase": "rewrite",
"functions": ["return function(conf, ctx)
ngx.say(\"serverless-pre-function\");
end"]
}
}
If no priority is specified in a plugin configuration, it will be sorted according to the value of the priority property in the plugin code.
If you specify the priority of the plugin in the plugin configuration of the Service or Plugin Config, it will still take effect after it is merged into the route.
Whether the custom plugin is executed
In addition to being able to adjust the execution order, it is also possible to dynamically decide whether a plugin needs to be executed. In version 2.15, the plugin configuration level filter was introduced, and the execution result of the filter controls whether the plugin is executed or not.
In the configuration below, only when the variable $status
is greater than or equal to 400, the http-logger
plugin will be executed. This way, only 4xx and 5xx requests will be reported to the remote HTTP log server.
{
"http-logger": {
"_meta": {
"filter": {
{"status", "!", "<", "400"}
}
},
...
}
}
At the same time, with the help of another function of APISIX to customize variables , you can play more tricks. For example, if the client address is an intranet address, a scenario such as a Logger will be skipped.
custom error response
This function is also a new function configured at the specific plug-in level, which belongs to the error information at the plug-in configuration level.
This feature can come in handy if the demand side has requirements for error responses on specific routes. No matter what the plugin is, this configuration can set a fixed response result to avoid troubles caused by the error response message built into the plugin.
As shown in the following configuration, no matter what error message jwt-auth
the plugin returns, it will be rewritten as "Missing credential in request" and returned to the client.
{
"jwt-auth": {
"_meta": {
"error_response": {
"message": "Missing credential in request"
}
}
}
}
Allows to collect metrics on Stream Route
A major change has also been made in this version, which is to allow metrics to be collected on Stream Route and exposed through the Prometheus interface.
This feature is disabled by default. If you need to enable it, please build APISIX on the APISIX-Base version and enable the config.yaml
36927620a35efcda3a440579342f75b1--- plugin in the prometheus
plugin, the example is as follows:
stream_plugins:
- ...
- prometheus
After enabling this plug-in, even if only APISIX is used to proxy TCP traffic on Layer 4, it will specifically monitor port 9091 to respond to HTTP requests sent by Prometheus.
Like the prometheus
plugin in the HTTP proxy subsystem, the next step is to configure the plugin on the Stream Route that needs to collect metrics:
curl http://127.0.0.1:9080/apisix/admin/stream_routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
"plugins": {
"prometheus":{}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:80": 1
}
}
}'
After connecting to the Stream Route, visit http://127.0.0.1:9091/apisix/prometheus/metrics and you will see the following TCP proxy statistics:
...
# HELP apisix_node_info Info of APISIX node
# TYPE apisix_node_info gauge
apisix_node_info{hostname="desktop-2022q8f-wsl"} 1
# HELP apisix_stream_connection_total Total number of connections handled per stream route in APISIX
# TYPE apisix_stream_connection_total counter
apisix_stream_connection_total{route="1"} 1
At present, this function only implements the statistical connection number, and more statistical indicators will be added as needed in the future.
In addition to the normal Stream Route, this version also provides statistical indicators for the Redis proxy function under xRPC. Such as command count indicators broken down by route and Command apisix_redis_commands_total
and delay time indicators apisix_redis_commands_latency_seconds_bucket
.
More features
In terms of new features, in addition to the functions mentioned above, this version also includes many detailed changes:
- Support Upstream objects referencing certificates from SSL objects
-
prometheus
provided in the indicatorngx.shared.dict
statistics -
openid-connect
plugin supports PKCE extension...
For more specific release details, please refer to 2.15 Changelog: https://github.com/apache/apisix/blob/release/2.15/docs/zh/latest/CHANGELOG.md#2150
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。