自上次APISIX v2.13 LTS版本发布以来，已经过去了两个多月。过去，每个小版本的Apisix都会为所有人带来新功能。Apisix V3版本的发行版。欢迎大家探索这些新功能。
接下来，让我们看看哪些新功能APISIX支持。
在APISIX v2.14.1版本之前，无论是代理GRPC请求还是普通的HTTP请求，Apisix的上游是docking应用程序服务器，无法满足多元化方案的需求。例如，如果用户需要使用其他上游类型（例如kafka），只能以其他方式实现。但是在Apisix v2.14.1版本中，Apisix添加了一个基于WebSocket的消息订阅代理框架，该框架允许客户端在指定的消息队列中订阅该消息（上游））通过Apisix。现在您可以使用Apisix订阅Kafka中的新闻。
以Kafka为例，我们需要配置以下内容：
上面的示例是kafka类型的上游到路由上，并包含多个经纪人。
您可以参考以下步骤以订阅上游：
例如，获得偏移的请求是：
有关每个字段的具体含义，请参阅pubsub.proto。
注意：成功获取消息后，您需要更新当前偏移量。更新的办公室是先前的偏移 + 1。
有关特定操作，请参阅源代码和测试案例：
尽管当前的PubSub框架仅提供基础接口，但它已达到了两个最基本的要求：
如果您在实际使用过程中遇到问题，则可以通过提交问题方法来反馈Apache Apisix社区。社区将根据用户反馈继续改善和增强此功能。
APISIX支持早期版本中的代理TCP协议，但是在某些情况下，纯TCP协议代理无法满足用户需求。由于应用程序协议可以实现应用程序，因此必须对某些功能进行编码，并且用户需要特定应用程序协议的代理，例如REDIS代理，Kafka代理等
从APISIX v2.14.1开始，APISIX提供了一个XRPC框架，该框架允许开发人员在框架上自定义特定的应用程序协议。基于XRPC框架上，APISIX可以在同一时间为几个主流应用程序协议提供代理支持。他们基于此框架的基于私有TCP的私有应用程序协议，因此它们具有准确的粒度和较高的级别7 -layer控件，类似于HTTP协议代理。
目前，APISIX已在XRPC框架上实现了Redis的代理函数，根据命令支持注入延迟并选择性记录日志内容。尽管APISIX需要在简单的设置/获取性能测试中编码REDIS协议，双重工作过程用于代理，其性能可以达到直接食谱的80％。
您可以参考以下命令为REDIS协议创建流程路由：
上述配置解释如下：
当命令获得或ping时，将有5秒的延迟。在同一时间，在执行每个命令后，它将确定其成本是否超过1秒的时间。如果是这样，则触发相应的对象，并发送到UDP日志的端口。
在v2.14.1之前，APISIX仅支持数据表面的服务发现。在这种情况下，每个APISIX实例需要获取服务发现的数据，但是在实际申请过程中，以下问题是反馈：
因此，从v2.14.1开始，APISIX将发现控制表面支持服务的功能。服务发现将通过Apisix-seed实现。
该功能实现的原则是在上游相关的资源和服务发现组件中，监视上游服务资源中的相应上游服务资源。当服务发现组件中的上游服务资源更改时，请更新ETCD中的相关上游信息。
特定的实施过程如下：
目前，控制地面服务发现的计划也很不足，例如在ETCD上的压力。
为了适应更广泛的应用程序方案，从v2.14.1版本开始，Apisix将尝试与Istio兼容，将ISTIO作为控制表面和APISIX作为数据表面，并开始在服务网格领域进行探索。
因为ISTIO的配置是由XDS协议发出的，因此开发了AMESH项目，并且ISTIO发出的XDS已转换为Apisix配置。目前，APISIX能够通过官方的简单书店App Demo.in apisix，apisix在官方的简单书店app demo.in将继续扩大对XD的支持，并将ISTIO和APISIX的能力越来越紧密。
除了上述探索性功能外，此版本的发布还为用户提供了一些更传统的功能：
有关更多功能更新和错误维修详细信息，请检查官方发布ChangElog。
原始：https：//juejin.cn/post/710381024703837060