导语：Aeraki Mesh 是 CNCF 的沙箱项目，它可以帮助你在服务网格中管理任何七层协议。
今天由叶秋学长来介绍如何通过 Aeraki 来在服务网格中为 Dubbo、Thrift 等协议的服务提供七层流量路由、本地限流、全局限流，以及如何基于 Aeraki Protocol快速开发一个自定义协议，并在 Istio 服务网格中对采用自定义协议的服务进行管理。
本篇文章作为系列教程的先导篇，叶秋学长将从全局视角带您了解 Aeraki Mesh。
编辑
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……
编辑
如果您已经在迁移到服务网格方面投入了大量精力，那么您当然希望充分利用它——管理微服务中所有协议的流量。
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 Mesh 在一个地方实现了第 7 层协议代理的大部分常见功能——MetaProtocol 代理过滤器。
编辑这种方法显着降低了编写新的 Envoy 过滤器的障碍：现在您只需要实现编解码器接口，而不是编写功能齐全的过滤器。除此之外，控制平面已经到位——Aeraki 在控制平面上工作，为基于 MetaProtocol 构建的所有协议提供 MetaProtocol 配置和动态路由。
编辑
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正式进入CNCF沙箱》点击学习链接
让我们一起期待下一篇的云原生系列作品，不要忘记给叶秋学长点点关注哦~~
