探索性版本—— Apache APISIX 2.14.1 正式发布。该版本不仅支持了在控制面实现服务发现，还支持了 Istio、基于 WebSocket 的 pubsub 代理框架和基于 xRPC 框架管理非 HTTP 的 7 层协议。
距离上次 APISIX v2.13 LTS 版本发布已经有两个多月的时间，以往每次 APISIX 的小版本发布，都会为大家带来新功能。然而 APISIX v2.14.1 版本发布的功能，将紧跟技术前沿，为大家带来了诸多探索性的新功能，并为 APISIX v3 版本的发布投石问路，欢迎大家探索这些新功能。
接下来我们先看下 APISIX 支持了哪些探索性的新功能。
基于 WebSocket 的 pubsub 代理框架
在 APISIX v2.14.1 版本之前，无论是代理 gRPC 请求还是普通的 HTTP 请求，APISIX 的上游都是对接的应用服务器，无法满足多元化场景需求。例如用户需要使用其他上游类型（比如 Kafka），就只能通过其他方式实现。但是在 APISIX v2.14.1 版本中，APISIX 新增了一个基于 Websocket 的消息订阅代理框架，该框架允许客户端通过 APISIX 来订阅指定消息队列（上游）中的消息。现在你可以使用 APISIX 来订阅 Kafka 中的消息。
以 Kafka 为例，我们需要如下配置：
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"
}
}'
上述示例是在路由中添加了一个 Kafka 类型的上游，并包含了多个 Broker。
你可以参考以下步骤订阅该上游：
首先请通过 WebSocket 建立连接。
获取 Topic 中的某个 Partition 当前的 offset。以下示例使用了 Protobuf 来编码相关的请求和响应：
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;
};
}获取 offset 的请求如下：
message CmdKafkaListOffset {
string topic = 1;
int32 partition = 2;
int64 timestamp = 3;
}各个字段具体含义请参考 pubsub.proto。
之后每次订阅操作都可以根据当前的 offset 来获取最新的消息。
tip
成功获取消息之后，需要更新当前的 offset，更新后的 offset 是之前返回的 offset + 1。
具体操作可参考源码和测试用例：
https://github.com/apache/apisix/blob/master/t/pubsub/kafka.t
https://github.com/apache/apisix/blob/master/t/lib/pubsub.lua
虽然当前的 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 为数据面的形式，开始在服务网格领域中探索。
由于 Istio 的配置是通过 xDS 协议下发的，所以开发了 Amesh 项目，把 Istio 下发的 xDS 转换成 APISIX 的配置。目前，APISIX 已经能够跑通 Istio 官方的 Simple Bookstore App demo。在后续版本中，APISIX 也会继续拓宽对 xDS 的支持，把 Istio 和 APISIX 的能力越来越紧密地结合在一起。
更多插件和功能
除了上面提到的几个探索性功能外，本次版本发布也为用户提供了一些较为传统的功能：
- 新增
casdoor插件，提高与 Casdoor 的交互体验。 response-rewrite插件增加了针对 Body 的替换过滤器。
更多功能更新和 Bug 修复细节，请查看官方 Releases CHANGELOG。