Aeraki [Air-rah-ki] 是希腊语中“微风”的意思。虽然 Istio 在服务网格中连接微服务，但 Aeraki 提供了一个框架，允许 Istio 支持更多的第 7 层协议，而不仅仅是 HTTP 和 gRPC。我们希望这股"微风"可以帮助 Istio 更进一步。

Service Mesh 缺乏协议支持

我们现在面临着服务网格的一些挑战：

• Istio 和其他流行的服务网格实现对除 HTTP 和 gRPC 之外的第 7 层协议的支持非常有限。
• Envoy RDS（Route Discovery Service）专为 HTTP 设计。其他协议如 Dubbo 和 Thrift 只能使用监听器内联路由进行流量管理，当路由发生变化时会中断现有连接。
• 将专有协议引入服务网格需要付出很多努力。您需要编写一个 Envoy 过滤器来处理数据平面中的流量，以及一个控制平面来管理这些 Envoy。

这些障碍使用户很难（如果不是不可能的话）管理微服务中其他广泛使用的第 7 层协议的流量。例如，在微服务应用程序中，我们可能有以下协议：

• RPC：HTTP、gRPC、Thrift、Dubbo、专有 RPC 协议……
• 消息传递：Kafka、RabbitMQ …
• 缓存：Redis、Memcached……
• 数据库：MySQL、PostgreSQL、MongoDB……

微服务中常用的第 7 层协议

如果您已经在迁移到服务网格方面投入了大量精力，那么您当然希望充分利用它——管理微服务中所有协议的流量。

Aeraki 的方法

为了解决这些问题，我们创建了一个开源项目Aeraki Mesh，以提供一种非侵入式、可扩展的方式来管理 Istio 服务网格中的任何第 7 层流量。

艾拉基建筑

如图所示，Aeraki 框架由以下组件组成：

• Aeraki：Aeraki为操作提供高级、用户友好的流量管理规则，将规则转换为 envoy 过滤器配置，并利用 Istio 的EnvoyFilterAPI 将配置推送到 sidecar 代理。Aeraki 还充当数据平面中 MetaProtocol 代理的 RDS 服务器。与专注于 HTTP 的 Envoy RDS 不同，Aeraki RDS 旨在为所有第 7 层协议提供通用的动态路由能力。
• MetaProtocol Proxy：MetaProtocol Proxy为第 7 层协议提供常用功能，例如负载均衡、断路器、负载均衡、路由、速率限制、故障注入和身份验证。第 7 层协议可以构建在 MetaProtocol 之上。要将新协议添加到服务网格中，您唯一需要做的就是实现编解码器接口和几行配置。如果您有内置能力无法满足的特殊需求，MetaProtocol Proxy 还具有应用级过滤器链机制，允许用户编写自己的第 7 层过滤器，将自定义逻辑添加到 MetaProtocol Proxy 中。

Dubbo和Thrift已经基于 MetaProtocol 实现。更多协议正在开发中。如果您使用的是闭源专有协议，您还可以通过为其编写 MetaProtocol 编解码器在您的服务网格中对其进行管理。

大多数请求/响应风格的无状态协议都可以构建在 MetaProtocol 代理之上。但是，有些协议的路由策略过于“特殊”，无法在 MetaProtocol 中进行规范化。例如，Redis 代理使用槽号将客户端查询映射到特定的 Redis 服务器节点，槽号由请求中的 key 计算得出。只要 Envoy 代理端有可用的 Envoy 过滤器，Aeraki 仍然可以管理这些协议。目前，对于该类别的协议，Aeraki 支持Redis和 Kafka。

元协议代理

深入研究元协议

让我们看看 MetaProtocol 是如何工作的。在引入 MetaProtocol 之前，如果我们想为特定协议代理流量，我们需要编写一个理解该协议的 Envoy 过滤器并添加代码来操作流量，包括路由、头部修改、故障注入、流量镜像等。

对于大多数请求/响应风格的协议，流量操作的代码非常相似。因此，为了避免在不同的 Envoy 过滤器中重复这些功能，Aeraki 框架在一个地方（MetaProtocol 代理过滤器）实现了第 7 层协议代理的大部分常见功能。

这种方法显着降低了编写新的 Envoy 过滤器的障碍：现在您只需要实现编解码器接口，而不是编写功能齐全的过滤器。除此之外，控制平面已经到位——Aeraki 在控制平面上工作，为基于 MetaProtocol 构建的所有协议提供 MetaProtocol 配置和动态路由。

在 MetProtocol 之前和之后编写 Envoy 过滤器

MetaProtocol Proxy 中有两个重要的数据结构：Metadata 和 Mutation。元数据用于路由，而 Mutation 用于标头操作。

在请求路径上，解码器（编解码器实现的解码方法）使用从请求中解析的键值对填充元数据数据结构，然后将元数据传递给元协议路由器。路由器在匹配它通过 RDS 和元数据从 Aeraki 接收到的路由配置后，选择适当的上游集群。

如果需要修改请求，自定义过滤器可以使用任意键值对填充 Mutation 数据结构：添加标头或更改标头的值。然后将 Mutation 数据结构传递给编码器（编解码器实现的 encode 方法）。编码器负责将键值对写入有线协议。

请求路径

响应路径与请求路径类似，只是方向不同。

响应路径

一个例子

如果需要实现基于 MetaProtocol 的应用协议，可以按照以下步骤进行（以 Thrift 为例）：

数据平面

• 实现编解码器接口对协议包进行编码和解码。您可以参考Dubbo 编解码器和Thrift 编解码器编写自己的实现。
• 使用 Aeraki ApplicationProtocolCRD 定义协议，如下 YAML 片段所示：

控制平面

您不需要实现控制平面。Aeraki 监视服务和流量规则，为 Sidecar 代理生成配置，并通过EnvoyFilterMetaProtocol RDS 将配置发送到数据平面。

协议选择

与 Istio 类似，协议由服务端口前缀标识。请使用以下模式命名服务端口：tcp-metaprotocol-{应用程序协议}-xxx。例如，Thrift 服务端口应命名为 tcp-metaprotocol-thrift。

交通管理

MetaRouter您可以通过CRD更改路线。例如：将 20% 的请求发送到 v1，将 80% 的请求发送到 v2：

参考

• Aeraki Mesh 网站
• GitHub 上的 Aeraki 网格
• 现场演示：Kiali 仪表板
• 现场演示：服务指标：Grafana
• 现场演示：服务指标：Prometheus
• Istio meetup China（中文）：全栈服务网格 - 使用 Aeraki 管理 Istio 服务网格中的任何第 7 层流量
• IstioCon 2021：如何管理 Istio 服务网格中的任何第 7 层流量？

原文作者：赵华冰 - 腾讯

-----------------------------------------------------------

行云创新

• 全国领先的一站式厂商，国家高新技术企业
• 上汽、格力、华为、中信银行等各行业头部企业信赖
• 阿里云战略投资企业

行云创新是云原生领域的佼佼者，其产品在广西贵港智慧城市、长三角产学研一体化创新平台、海尔工业互联网、中信银行核心系统建设等项目中起到关键的支撑作用。同时，作为信创工委会成员，行云打造业界领先的“信创与非信创统管、一键向信创迁移”的方案，并在某大型国有银行取得了良好的实践效果。

SolarMesh，高效可视化平台

基于 Istio 及容器技术，提供流量监控和管理，提供完善的非侵入式服务治理解决方案。帮助企业在纷繁复杂的微服务调度中快速定位问题，增强研发效率。

SolarMesh，让服务网格不再难学难用，让服务网格在企业落地更加平滑、安全、稳定。

SolarMesh在线体验地址>