It has been more than two months since the last release of APISIX v2.13 LTS. In the past, every minor version release of APISIX will bring you new functions. However, the functions released by APISIX v2.14.1 will keep up with the cutting-edge technology, bringing you many exploratory new functions, and asking for directions for the release of APISIX v3. Welcome to explore these new functions.
Next, let's take a look at what exploratory new features APISIX supports.
WebSocket-based pubsub proxy framework
Before APISIX v2.14.1, whether it was proxying gRPC requests or ordinary HTTP requests, the upstream of APISIX was a docking application server, which could not meet the needs of diversified scenarios. For example, if the user needs to use other upstream types (such as Kafka), it can only be achieved by other means. But in APISIX v2.14.1, APISIX has added a Websocket-based message subscription broker framework, which allows clients to subscribe to messages in the specified message queue (upstream) through APISIX. Now you can use APISIX to subscribe to messages in Kafka.
Taking Kafka as an example, we need the following configuration:
curl -X PUT 'http://127.0.0.1:9080/apisix/admin/routes/kafka' \
-H 'X-API-KEY: ${api-key}' \
-H 'Content-Type: application/json' \
-d '{
"uri": "/kafka",
"upstream": {
"nodes": {
"kafka-server1:9092": 1,
"kafka-server2:9092": 1,
"kafka-server3:9092": 1
},
"type": "none",
"scheme": "kafka"
}
}'
复制代码The above example adds a Kafka-type upstream to the route and includes multiple brokers.
You can subscribe to this upstream by referring to the following steps:
- First please establish a connection via WebSocket.
- Get the current offset of a Partition in the topic. The following example uses Protobuf to encode the associated request and response:
message PubSubReq {
int64 sequence = 1;
oneof req {
CmdEmpty cmd_empty = 31;
CmdPing cmd_ping = 32;
CmdKafkaFetch cmd_kafka_fetch = 33;
CmdKafkaListOffset cmd_kafka_list_offset = 34;
};
}
message PubSubResp {
int64 sequence = 1;
oneof resp {
ErrorResp error_resp = 31;
PongResp pong_resp = 32;
KafkaFetchResp kafka_fetch_resp = 33;
KafkaListOffsetResp kafka_list_offset_resp = 34;
};
}
复制代码For example, the request to get the offset is:
message CmdKafkaListOffset {
string topic = 1;
int32 partition = 2;
int64 timestamp = 3;
}
复制代码Please refer to pubsub.proto for the specific meaning of each field .
- After each subscription operation, the latest news can be obtained according to the current offset.
Note: After the message is successfully obtained, the current offset needs to be updated. The updated offset is the previously returned offset + 1.
For specific operations, please refer to the source code and test cases:
虽然当前的 Pubsub 框架仅提供了底层的接口，但是它已经实现了两个最基本的需求：
- 通过常用的
80/443端口暴露 Kafka 服务能力，无需应用服务器再封装多一层。 - 允许添加鉴权插件，像使用一般的 Websocket 框架那样给 Kafka 的服务增加安全保护。
如果你在实际使用过程中遇到问题，可以通过提交 issue 的方式反馈给 Apache APISIX 社区，社区将根据使用者的反馈，继续完善和增强这一功能。
基于 xRPC 框架管理非 HTTP 的 7 层协议
APISIX 在早期版本就支持代理 TCP 协议，但是部分场景中，纯粹的 TCP 协议代理无法满足用户需求。因为有些功能必须在对应用协议进行编解码之后才能实现，因此用户就需要特定应用协议的代理，比如 Redis Proxy、Kafka Proxy 等。
从 APISIX v2.14.1 版本开始，APISIX 提供了 xRPC 框架，允许开发者在该框架上自定义特定的应用协议。基于 xRPC 框架，APISIX 可以提供对若干主流应用协议的代理支持。同时用户也可以基于该框架来支持自己私有的基于 TCP 的应用协议，使其具备类似 HTTP 协议代理的精准颗粒度和更高阶的 7 层控制。
目前，APISIX 已经在 xRPC 框架上实现了 Redis 的代理功能，支持了根据命令注入延迟和有选择性地记录日志内容。尽管 APISIX 需要对 Redis 协议进行编解码，但是在简单的 SET/GET 性能测试中，使用双 Worker 进程的 APISIX 进行代理，其性能可以达到直连 Redis 的 80%。
你可以参考以下命令创建一个代理 Redis 协议的流路由：
curl http://127.0.0.1:9080/apisix/admin/stream_routes/1 \
-H 'X-API-KEY: ${api-key}' -X PUT -d '
{
"upstream": {
"type": "none",
"nodes": {
"127.0.0.1:6379": 1
}
},
"protocol": {
"name": "redis",
"conf": {
"faults": [{
"commands": ["get", "ping"],
"delay": 5
}]
},
logger = {
[
"name": "syslog",
"filter": [
["rpc_time", ">=", 1],
],
"conf": {
"host": "127.0.0.1",
"port": 8125,
"sock_type": "udp",
"batch_max_size": 1,
"flush_limit": 1
}
]
}
}
}'
复制代码以上配置释义如下：
当命令是 GET 或 ping 时，将会有 5 秒延迟。同时每个命令执行之后，会判断其花费的时间是否超过 1 秒，如果是，则触发对应的 logger 对象，并发送 syslog UDP 日志到 127.0.0.1 的 8125 端口。
控制面支持服务发现
在 v2.14.1 版本之前，APISIX 仅在数据面支持了服务发现。这种情况下，每个 APISIX 实例都需要获取服务发现的数据，但是用户在实际应用过程中，反馈了以下问题：
- 每个 APISIX 实例都需要从服务发现系统里拉取数据，这让网络拓扑变得复杂。
- 服务发现配置需要在每个 APISIX 实例都配置一遍。如需修改密码，就必须修改配置文件，然后发布到每个 APISIX 实例上。
- 当前许多服务发现都没有提供 Lua SDK，如果要使用这些服务发现系统，就需要自己直接对接该服务器提供的 HTTP API （假如存在）。
因此从 v2.14.1 版本开始，APISIX 将在控制面支持服务发现功能。服务发现将通过 APISIX-Seed 实现。
该功能实现原理是通过 apisix-seed 同时监听 etcd 中 Upstream 相关的资源和服务发现组件中对应的上游服务资源，当服务发现组件中的上游服务资源发生变化时更新 etcd 中相关的 Upstream 信息。
具体实现流程如下图：
目前来看，控制面服务发现的方案也有不足之处，比如对 etcd 的压力较大。因此 APISIX 会同时保留两种服务发现方案，并通过更多实际应用来证明哪个方案会更优。
初步支持 Istio
为了适应更广泛的应用场景，从 v2.14.1 版本开始，APISIX 将尝试兼容 Istio，以 Istio 为控制面、APISIX 为数据面的形式，开始在服务网格领域中探索。
Since the configuration of Istio is issued through the xDS protocol, the Amesh project was developed to convert the xDS issued by Istio into the configuration of APISIX. At present, APISIX has been able to run through the official Istio Simple Bookstore App demo. In subsequent releases, APISIX will continue to expand its support for xDS, bringing the capabilities of Istio and APISIX closer together.
More plugins and features
In addition to the exploratory features mentioned above, this release also provides users with some more traditional features:
- Add a
casdoorplugin to improve the interaction experience with Casdoor. response-rewriteThe plugin adds a replacement filter for Body.
For more feature updates and bug fixes details, please check the official Releases CHANGELOG .