体验全新一代的服务网格，Airan极致性能优化，给你想不到的惊喜！

当服务的边界消失，Mesh的性能瓶颈何在

Aeraki 服务网格支持多注册中心、多协议接入，极大简化了服务发现的复杂度。但随着集群中服务规模不断壮大，例如 1 个集群中有几十万的服务，这些服务的元数据构成的路由表对于 sidecar 容器来说将异常庞大，这无疑是服务网格在性能方面无法逾越的障碍。

上图为某客户集群的现状，其中服务数量高达 50 万，在测试过程中，发现单台机器上的 Envoy sidecar 容器的启动时间约为 10 分钟。

服务规模的扩展性上，Aeraki提出两条重要原则：

• 服务网格应该尽可能的瘦。
• 服务发现是无处不在的。

Aeraki xDS 按需加载的核心思想:

• 容器启动时无需加载所有服务元数据信息，仅加载少量必须信息即可完成启动。
• 在运行时，服务网格组件如 Envoy sidecar，可以通过 xDS API 动态加载和更新服务信息，根据实际流量动态调整服务加载策略。

接下来我们详细了解下 Aeraki xDS 按需加载的实现原理。

让服务发现无处不在

Aeraki 通过在 kube-apiserver 中注册自定义资源的方式，将服务实例信息存储在 etcd 集群中，这是 Kubernetes 的事实存储层，这样所有 Kubernetes 的组件都可以直接访问到这些信息。

为了兼容传统的服务发现方式，Aeraki 在 kubelet 中实现了服务发现的插件，当 Pod 启动的时候，可以通过插件的方式直接从 etcd 中获取服务实例列表，并将这些信息通过环境变量的方式注入到 Envoy 容器中。这部分信息主要用于 sidecar 容器启动时加载静态路由表。

Service Mesh 的本质是将服务发现的信息通过 xDS API 下发到 Envoy 等数据平面组件，所以 Aeraki 引入了一个新的组件 Mesh Endpoint Discovery Service (MEDS)，它主要负责在运行时将服务发现的信息同步到 xDS 服务器。

按需加载服务信息

当 sidecar 容器启动时，只会加载少量的信息，这些信息包括：

• 本地服务的名称和端口
• 本地服务依赖的服务列表
• 本地服务依赖的服务的端口列表

这部分信息主要是通过环境变量的方式注入到 Envoy 容器中。

在 sidecar 容器启动之后，MEDS 会将服务发现的信息同步到 xDS 服务器，xDS 服务器再将这些信息下发到 sidecar 容器。sidecar 容器收到这些信息之后，会根据实际流量动态调整服务加载策略。

优化效果

经过测试，在集群中部署了 50 万个服务的客户，使用 Aeraki xDS 按需加载功能后，Envoy sidecar 容器的启动时间从 10 分钟缩短到 1 分钟，性能提升了 10 倍。

结语

Aeraki xDS 按需加载功能可以显著提高服务网格的性能，同时降低延迟和增加吞吐量。如果您正在寻找一种方法来优化您的服务网格的性能，那么 Aeraki xDS 按需加载功能是您不可错过的选择。