阿里云洛神云网络集中式网关丨技术解读与产品实践

2022-11-30
浙江
本文字数：3576 字
阅读完需：约 12 分钟

随着云原生在生产领域的大规模使用，服务网格这一方案也越来越受到开发、运维人员的重视，其中最受关注的就是 Istio。Istio 原生的方案是使用 SideCar Per-Pod 的转发方式，而在 9 月初的时候 Istio 社区又提出了 Ambient Mesh 方案，简单来说，Ambient Mesh 为了解决 SideCar 的一些缺陷，更倾向于使用共享代理的方式对 4/7 流量进行转发。而我们做的一些工作主要是摒弃掉了 SideCar，对转发、控制平面进行了一些改造工作，通过使用一个集群内共享的转发节点来接管整个集群的东西向流量，这个共享的转发节点就是 Alibaba 集中式网关。

什么是服务网格？

提到服务网格(Service Mesh)，就必须先介绍一下微服务，根据维基百科的定义：微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的 API 集相互通信。

简单来说，服务网格(Service Mesh)是微服务架构中一种解决方案、一种实现方法，而服务网格这种解决方案可能又有不同的代码实现。在微服务架构中的解决方案大致可以分为两种 Smart Client 和 Local Proxy，其中 Local Proxy 就是我们所说的服务网格，其中比较有代表性的实现有 Istio、Linkerd、NginxMesh 等；而 Smart Client 比较有代表性的实现有 Dubbo、Spring Cloud、Thrift、Proxygen 等。

下面先介绍微服务领域中涉及到比较经典的两种方案，再来详细探讨我们本文的主题。

Smart Client 方案介绍

Smart Client 通过抽象分布式系统中的各种语义，例如服务发现、负载均衡、服务熔断等，实现各种通用功能，避免了每个服务都自己去实现一套分布式系统的语义，使研发人员可以专注于业务逻辑开发，但是也是需要了解部分框架代码，没有百分百解耦。

Smart Client 一般是与业务代码强耦合的，以 SDK 的方式嵌入到了应用程序中，并且 Smart Client 的方案是与开发语言绑定的，如果换一种开发语言，那原本的 Smart Client 架构也就不能用了。微服务框架本身与业务程序完全揉到了一起，导致大大提高了业务维护的运维难度。

Smart Client 架构图

Local Proxy 方案介绍

Local Proxy 方案采用进程级别进行服务治理，利用进程隔离代理的方式，规避了 Smart Client 的语言相关以及应用耦合的问题，这一类方案就是服务网格(Service Mesh)，服务网格也是将分布式服务的通信部分抽象出来，和业务进程部署在一起，通过本地独立进程的方式，将业务应用的流量全部劫持到这个本地的独立进程上，接管服务的流量，而在这个进程中实现负载均衡、服务发现、认证授权、服务熔断等功能，William Morgan(Service Mesh)的发明者对服务网格的定义如下：

“服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。”

Local Proxy 架构图

ISTIO 介绍

上面我们有简单提到，Service Mesh 中有众多的实现方案，其中最重要、最闪耀的无疑是 Istio 方案，下面我们介绍一下 Istio 以及 Istio 有哪些优缺点。Istio 在架构上可分为“控制面”和“数据面”，其中数据面是由一组 Sidecar 组成，这些 Sidecar 是基于 Envoy 建立的，与业务进程同属于一个网络平面，接管所有业务进程的出入流量；而控制面负责管理和配置服务网格中的路由信息，将用户的配置下发到数据面，达到用户想要的效果，其中控制面分为 Pilot、Citadel、Galley。Pilot 负责流量管理、路由配置以及服务发现等；Citadel 通过管理用户身份验证、证书和凭证管理来提供服务之间的安全通信；Galley 负责配置管理、验证配置信息的格式以及内容的正确性。

ISTIO 架构图

Istio 的优点在于功能齐全，与 Kubernetes 可以做到完美结合，在流量管理、请求路由、负载均衡、可观测性、安全校验等功能上都提供了完善的支持。但是在 Sidecar 下，每个 pod 都需要有一个 Sidecar，可能造成代理数量过多和资源浪费，尤其在业务高峰期，会出现业务进程与 Sidecar 资源争抢的情况，服务之间互访至少需要经过两个 Sidecar，也引入了额外的时延开销，流量劫持依赖 iptables 等手段，即使通过 ebpf 进行了优化，但是在减少应用层时延或者跨 Node 流量场景中也是爱莫能助的。

另外 Istio 的上手成本高，Sidecar、istiod 等组件还是与业务进程共存在一个平面中，每次的业务升级都会伴随着 Sidecar 的销毁以及重建，这要求业务研发人员想要使用到 Istio 服务，就必须去运维 Kubernetes、Istio 这一整个体系，而大多数业务场景中使用到的服务治理框架例如 spring cloud、dubbo 等也可以满足需求，缺乏足够的驱动力迁移 Istio，门槛又相对较高，这就导致 Istio 在实际应用中落地还是比较少的。

阿里云集中式网关

针对上面 Istio 的 Sidecar Per Pod 方案的一些痛点，例如研发人员运维成本高、Sidecar 带来的资源消耗和时延消耗等问题；业界也有一些方案进行优化，例如 Sidecar Per Node 方案，将 Sidecar 从 Pod 提取到 Node 上，同 Node 的网络访问直接通过协议栈 Socket 层进行转换，从而可以降低时延消耗。

而我们基于 Istio 提出了一种集中式网关的处理方案(alibaba-centralized-mesh-gateway)，在集群中引入一个 InternalGateway 来承载东西向流量，Pod 和 Node 上都卸载掉了 Sidecar，避免了流量劫持这一步的损耗，Pod 资源完全由业务应用独占，而 InternalGateway 可以独立部署以及集中式管理，与集群中所有的业务组件完全解耦，在升级运维的过程中，可将业务与网关集群完全剥离开，而 InternalGateway 通过多副本、多可用区部署等方式来保证高可用。

Sidecar 模式与 Internal Gateway 模式

同样的，集中式网关也分为数据面和控制面，控制面的配置下发是基于 Istio 的 pilot 等组件，数据面是基于 envoy、独立部署的一个网关集群。在集中式网关架构中，共有三个角色：Istiod、InternalGateway、InternalGateway Controller，其中 Istiod 的作用与在 Istio 中的一致，主要是负责 watch 用户配置，向转发平面(envoy)进行配置下发、安全验证、路由管理等操作，InternalGateway，用来做整个集群的东西向流量转发；InternalGateway Controller 的作用是劫持集群内的 Service 服务，将流量 Rewrite 到 InternalGateway 上。

集中式网关架构图

当用户使用 virtual service、destination 等对象创建路由规则时，Istiod 和 InternalGateway Controller 会将 watch 到的对象分别进行分析，生成对应的配置，然后分别下发到 envoy 集中式网关和 CoreDNS，当 client pod 发起对 server pod 的访问时，server 的 dns 记录已经被 rewrite 到了集中式网关，因此流量无需经过 pod 上 iptables、sidecar 等路径，直接会将流量从协议栈发送到 internalGateway，而 internalGateway 根据用户配置的路由规则、访问策略，对访问流量进行处理，然后发送到 server pod 上。

流量路径图

集中式网关使用指南

我们以计算机领域中经典的 helloworld 服务为例，介绍如何在 Kubernetes 集群中使用阿里巴巴集中式网关：首先我们在 Kubernetes 安装部署好集中式网关服务，集群中显示如下内容表示部署成功：

部署 HelloWorld 服务

HelloWorld Service Yaml

创建 Gateway，此 Gateway 绑定到 internalGateway

Gateway Yaml

为 Helloworld Service 创建 Virtual Service

HelloWorld Virtual Service Yaml

发起对 HelloWorld Service 的访问，可以看到，流量是经过 internalGateway 到达的 HelloWorld Service。

通过上面简单的例子，我们可以看到，在一键部署集中式网关之后，用户只需要像之前一样创建 Kubernetes 或者 Istio 中的 CRD 等资源，就可以将服务应用部署起来。而且集中式网关的流量劫持不依赖 iptables，不依赖 Sidecar，因此不会出现数据报文多次经过内核协议栈，造成访问时延增大的情况。

我们同样支持 Istio 的 Sidecar 模式无损迁移到 InternalGateway，这里限于篇幅就不介绍了。