Aeraki Mesh 发布 1.3.0 版本，代号：Dragonboat_热讯

Aeraki Mesh 于 2023 年 6 月 24 日发布 1.3.0 版本（版本代号：Dragonboat），该版本包含了对 Istio 1.16.x 系列版本的支持，以及支持多路复用，gateway 支持 MetaProtocol 等一系列重大的新增特性。

Aeraki Mesh 采用新 Logo

由于原来的 logo 存在版权问题，Aeraki Mesh 启用 CNCF 设计的新 logo，如下图所示。该 logo 已经全面应用于 Aeraki Mesh 的 Github repo 和官网。如果大家在相关网站或者文档上发现还有旧 logo，欢迎提交 issue 和 PR。

支持 Istio 1.16.x 版本

从 1.3.0 版本开始，Aeraki Mesh 对应的 Isito 版本升级为 1.16.x 版本。

(资料图片仅供参考)

1.2.x 版本进入维护期，只修复重要故障。

支持多路复用

如下图左半部分所示，在之前的版本中，MetaProtocolProxy 在处理请求时会从 upstream 连接池中 获取连接，每个请求占用一个 upstream 连接，请求完成后将连接释放到连接池重供后续请求使用。在该机制下，如果并发请求数量较大，会产生较多 upstream 连接（连接数量理论上同并发请求数量）。

在 1.3.0 版本中，MetaProtocolProxy 中引入了多路复用机制。其实现原理如下图右半部分所示，通过在 Connection Manager 中缓存 upstream conn_data 来实现多路复用。

备注：目前多路复用属于 alpha 特性，控制面尚不支持。在数据面可以通过设置 meta_protocol_proxy 的 multiplexing 属性为true打开进行测试，如下所示：

name: aeraki.meta_protocol_proxytyped_config:"@type": type.googleapis.com/aeraki.meta_protocol_proxy.v1alpha.MetaProtocolProxyprotocol:name: dubbocodec:name: aeraki.meta_protocol.codec.dubbomultiplexing: true

Gateway 支持 MetaProtocol

本版本开始支持在 Gateway 上提供 MetaProtocol 七层路由能力。在 MetaRouter 上增加了 gateways 属性，可以通过该属性在 Gateway 上设置路由规则。下面的 yaml 片段展示了在 gateway 上对 Thrift 请求进行七层路由的例子。

---apiVersion: metaprotocol.aeraki.io/v1alpha1kind: MetaRoutermetadata:name: test-metaprotocol-thrift-routenamespace: meta-thriftspec:gateways:    - istio-system/istio-ingressgatewayhosts:    - thrift-sample-server.meta-thrift.svc.cluster.localroutes:    - route:        - destination:host: thrift-sample-server.meta-thrift.svc.cluster.localport:number: 9090subset: v1

Dubbo 服务 支持应用级服务治理

从本版本开始，支持按照应用（进程）和接口（Interface）两种粒度对 Dubbo 服务进行治理。

在 Dubbo 中，有一个 Interface 的概念，一个进程中通常会有多个I nterface。当将 Dubbo 应用加入到服务网格进行服务治理时，有两个选择：

按应用（进程）粒度进行服务治理，即以应用作为 Mesh 中的一个 Service。

优点：Mesh 中的 Service 数量相对于接口级服务治理方案更少，控制面需要下发的xds配置少，控制面和 Sidecar 的资源占用相对小。

缺点：无法按照Interface进行流量治理，包括灰度发布、限流、流量镜像等，只能按照应用级别进行流量治理。

按接口（Interface）粒度进行服务治理，即以 Dubbo Interface 作为 Mesh 中的一个 Service。

优点：可以按接口进行流量治理，包括灰度发布、限流、流量镜像等。

缺点：Mesh 中的 Service 数量相对于应用级服务治理方案更多，控制面需要下发的xds配置多，控制面和 Sidecar 的资源占用相对大。

可以看出，这两种治理方式各有优缺点。一般来说，当 Dubbo 应用规模较大、Interface 较多时，建议选择按照应用粒度进行服务治理，以减轻控制面负荷和 Sidecar 的资源消耗；当 Dubbo 应用规模较小、Interfac 数量较少时，建议选择按照 Interface 粒度进行服务治理，以提供最精细的流量治理能力。

Aeraki Mesh同时支持应用级和接口级服务治理。除了流量治理的粒度不同之外，这两种模式的路由、Metrics、Access log、Tracing 等能力是一致的。您可以根据自己的需求进行选择。

Dubbo 服务治理的更多内容请参见官网文档：https://www.aeraki.net/zh/docs/v1.x/tutorials/dubbo

Redis 流量管理

Redis 是一种高性能的键值数据库，通常被用作缓存、会话存储和消息代理等用途。Aeraki Mesh 提供了对 Redis 的流量管理能力，可以实现客户端无感知的 Redis Cluster 数据分片，按 key 将客户端请求路由到不同的 Redis 服务，读写分离，流量镜像，故障注入等高级流量管理功能。

Redis 流量管理的更多内容请参见官网文档：https://www.aeraki.net/zh/docs/v1.x/tutorials/redis

官方镜像库切换为 Github Packages

官方镜像库从 Docker Hub 切换到 Github Packages。

镜像下载地址：

控制面：

ghcr.io/aeraki-mesh/aeraki[:TAG]

数据面：

ghcr.io/aeraki-mesh/meta-protocol-proxy[:TAG]

ghcr.io/aeraki-mesh/meta-protocol-proxy-debug[:TAG]

ghcr.io/aeraki-mesh/meta-protocol-proxy-distroless[:TAG]

更多详情可查看发布公告。