微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

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_proxy

typed_config:

'@type': type.googleapis.com/aeraki.Meta_protocol_proxy.v1alpha.MetaProtocolProxy

protocol:

name: dubbo

codec:

name: aeraki.Meta_protocol.codec.dubbo

multiplexing: true

Gateway 支持 MetaProtocol

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

---

apiVersion: Metaprotocol.aeraki.io/v1alpha1

kind: MetaRouter

Metadata:

name: test-Metaprotocol-thrift-route

namespace: Meta-thrift

spec:

gateways:

- istio-system/istio-ingressgateway

hosts:

- thrift-sample-server.Meta-thrift.svc.cluster.local

routes:

- route:

- destination:

host: thrift-sample-server.Meta-thrift.svc.cluster.local

port:

number: 9090

subset: 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]

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

原文地址:OSCHINA

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐