Aeraki [Air-rah-ki] 是希腊语 ” 微风 “ 的意思。 该命名的寓意是希望 Aeraki Mesh 这股 “微风” 能帮助 Istio 和 Kubernetes 在云原生的旅程中行得更快更远。Aeraki Mesh 的定位非常明确：只处理服务网格的非 HTTP 七层流量，将 HTTP 流量留给 Istio 。(我们认为现有的项目已经足够优秀，不必重新造轮子)。
由腾讯云主导，联合百度、灵雀云、腾讯音乐、滴滴、政采网等多家合作伙伴发起的服务网格开源项目 Aeraki Mesh 通过了全球顶级开源基金会云原生计算基金会（CNCF）技术监督委员会评定，正式成为 CNCF 沙箱项目。
Aeraki Mesh 架构
正如该图所示，Aeraki Mesh 由以下两部分组成。
Aeraki: Aeraki 工作在控制面，为运维提供了高层次的、用户友好的流量管理规则，将规则转化为 envoy 代理配置，并利用 Istio 提供的标准接口将配置推送给数据面的 sidecar 代理。 Aeraki 还在控制面中充当了 MetaProtocol Proxy 的 RDS（路由发现服务）服务器。不同于专注于 HTTP 的 Envoy RDS，Aeraki RDS 旨在为所有七层协议提供通用的动态路由能力。
MetaProtocol Proxy: MetaProtocol Proxy 工作在数据面，是一个七层代理框架，为七层协议提供了常用的流量管理能力，如负载均衡、熔断、路由、本地 / 全局限流、故障注入、指标收集、调用跟踪等等。我们可以基于 MetaProtocol Proxy 提供的通用能力创建自己专有协议的七层代理。要在服务网格中加入一个新的协议，唯一需要做的就是实现 编解码器接口 （通常只需数百行代码）和几行 yaml 配置。如果有特殊的要求，而内置的功能又不能满足，MetaProtocol Proxy 还提供了一个扩展机制，允许用户编写自己的七层过滤器，将自定义的逻辑加入 MetaProtocol Proxy 中。
MetaProtocol Proxy 中已经支持了 Dubbo， Thrift ，bRPC 和一系列私有协议。如果你正在使用一个闭源的专有协议，也可以在服务网格中管理它，只需为它编写一个 MetaProtocol 编解码器即可。
MetaProtocol Proxy 架构
MetaProtcolProxy 对七层协议进行了高度抽象，提取了 Metadata 这个非常灵活的扩展机制，应用协议在解码过程中将协议中的关键属性填充到 Metadata 中，这些属性可以用于请求路由、限流等后续的七层 filter 处理。框架层将 Meatdata 作为透明的 key/value 值串进行处理，不需要理解协议的业务细节。该设计可以确保任何基于 MetaProtocol 开发的应用协议都能使用同一套控制面 API 进行管理，是 Aeraki 实现对 Dubbo、Thrift、bRPC 以及其他协议进行统一管理的基础。同时，MetaProtocolProxy 还提供了 Mutation 数据结构，用于在编码时对数据包进行修改，例如增加 / 修改请求头的内容。
下图是 MetaProtocolProxy 处理一个请求处理的过程：
MetaProtocol Proxy 请求处理流程
Aeraki Mesh 的主要特点：
- 和 Istio 无缝集成，是 Istio Ecosystem 集成推荐项目。您可以采用 Istio + Aeraki Mesh 来构建一个可以同时管理 HTTP 和其他七层协议的全栈服务网格。
- 支持在 Istio 中管理 Dubbo、Thrift、Redis 等开源协议的流量。
- 支持在 Istio 中管理私有协议的流量，只需数百行代码，对 Istio 无任何改动。
- 支持请求级负载均衡，支持任意匹配条件的动态路由，全局和本地限流，流量镜像等强大的七层流量管理能力。
- 提供丰富的请求级性能指标，包括请求时延、错误、数量等，支持分布式调用跟踪。
- 对 Istio，Envoy 等上游开源项目完全无侵入，可以跟随上游项目进行快速迭代，充分利用上游项目新版本提供的新增能力。
-
引言 越来越多的公司开始研究Service Mesh，线上大批量应用案例的依旧很少，已经上线的很多问题解决的并不完美，为后面迭代和稳定性埋下隐患。目前来看整体开源生态成熟度还有需要完善，本文为笔者试水service mesh过程中发现的问题归纳整理。 一、目标与价值 业务侧只需要引入轻量级SDK，其他基础能力下沉到网格SideCar代理中，一个美好的愿望 “接管所有非业务关心的能力”。 1.业务赋
-
用于展示Isito服务网格的流量路由特性的任务。 配置请求路由。这个任务展示如何基于权重和HTTP header配置动态请求路由。 故障注入。这个任务展示如何注入延迟并测试应用的弹性。 流量转移。这个任务展示如何将服务的流量从旧版本转移到新版本。 设置请求超时。这个任务展示如何使用Istio在Envoy中设置请求超时。 Istio Ingress控制器。描述如何在Kubernetes上配置Isti
-
Vistio GitHub地址：https://github.com/nmnellis/vistio Vizceral是Netflix发布的一个开源项目，用于近乎实时地监控应用程序和集群之间的网络流量。Vistio是使用Vizceral对Istio和网格监控的改进。它利用Istio Mixer生成的指标，然后将其输入Prometheus。Vistio查询Prometheus并将数据存储在本地以允许
-
这一任务演示istio对流量进行镜像复制的能力。流量镜像是一个有力的工具，在业务团队对生产系统进行变更的过程中，这一能力能够有效的降低风险。流量镜像功能可以对实时流量进行复制，将这一副本发送给镜像服务，并把主服务的关键请求路径放到带外。 Mirroring brings a copy of live traffic to a mirrored service and happens out of
-
本任务将演示如何将应用流量逐渐从旧版本的服务迁移到新版本。通过Istio，可以使用一系列不同权重的规则（10%，20%，··· 100%）将流量平缓地从旧版本服务迁移到新版本服务。为简单起见，本任务将采用两步将流量从reviews:v1 迁移到 reviews:v3，权重分别为50%，100%。 开始之前 参照文档安装指南中的步骤安装Istio。 部署BookInfo示例应用程序。 请注意：本文档
-
Pilot负责部署在Istio服务网格中的Envoy实例的生命周期管理。 Pilot架构 如上图所示，Pilot维护了网格中的服务的规范表示，这个表示是独立于底层平台的。Pilot中的平台特定适配器负责适当填充此规范模型。例如，Pilot中的Kubernetes适配器实现必要的控制器来watch Kubernetes API server中pod注册信息、ingress资源以及用于存储流量管理规则
-
缺省情况下，启用了Istio的服务是无法访问外部URL的，这是因为Pod中的iptables把所有外发传输都转向到了Sidecar代理，而这一代理只处理集群内的访问目标。 本节内容会描述如何把外部服务提供给启用了Istio的客户端服务使用，你会学到如何使用Egress规则访问外部服务，或者如何简单的让特定IP范围穿透Istio代理。 开始之前 遵循安装指南设置Istio 启动sleep示例，用于测
-
YOG2 中，使用 node-ral 进行后端服务管理，我们引入后端服务管理层主要是解决以下几个问题 后端服务配置统一管理 封装异常处理、超时重试，提升系统稳定性 封装日志，便于线上问题追查 抽象请求协议、数据格式与数据编码，统一用户接口 在后端服务配置统一管理方面，我们的准则是配置优于硬编码，虽然使用类似 request 一类的库也可以很好的实现 HTTP 请求服务，但是它并没有明确的控制诸如服
-
更改启动服务 在运行级别对应的文件夹中，您可以看到许多文件名以 S## 和 K## 起始的启动脚本链接。例如： /etc/rcS.d/S35mountall.sh 挂载文件系统 /etc/rcS.d/S40networking 启用网络支持 /etc/rc2.d/S13gdm 启动登录管理器 /etc/rc2.d/S20makedev 创建设备文件 /etc/rc2.d/S23xin