开源一夏 |Aeraki --- 管理 Istio 服务网格中任何 7 层协议
导语：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 沙箱》点击学习链接
让我们一起期待下一篇的云原生系列作品，不要忘记给叶秋学长点点关注哦~~
版权声明: 本文为 InfoQ 作者【叶秋学长】的原创文章。
原文链接:【http://xie.infoq.cn/article/89d9f351bacb918438735d355】。文章转载请联系作者。
还未添加个人签名 2022.07.01 加入
全栈JAVA领域创作者
评论