共计 3464 个字符，预计需要花费 9 分钟才能阅读完成。
间隔上次 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 来获取最新的音讯。
留神：胜利获取音讯之后，须要更新以后的 offset，更新后的 offset 是之前返回的 offset + 1。
具体操作可参考源码和测试用例：
- https://github.com/apache/api…
- https://github.com/apache/api…
尽管以后的 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。
