跳至内容
实战课程
云原生课程
网关

网关

相关概念：

API网关、微服务网关、流量网关、安全网关

后端架构演进史

后端架构演进史

API网关介绍

API网关 简单来说是一种主要工作在七层、专门用于 API 的管理和流量转发的基础设施，并拥有强大的扩展性。

网关的角色是作为一个API架构，用来保护、增强和控制对于API服务的访问。它是一个处于应用程序或服务（提供RESTful API接口服务）之前的系统，用来管理授权、访问控制和流量限制等。这样RESTful API接口服务就被网关保护起来，对所有的调用者透明。因此，隐藏在API网关后面的业务系统就可以专注于创建和管理服务，无需关心这些策略性的请求。

API Gateway是一种服务，他是外部世界进入应用程序的入口点。它负责请求路由、API组合和身份验证等各项功能。

API Gateway 还可以作为客户端应用程序和后端微服务架构之间的反向代理。

BFF

BFF模式是一种架构模式，是API网关模式的变体，它包括多个后端，旨在满足特定前端应用程序的需求，如桌面、浏览器和本地移动应用程序、物联网设备等。

image-20240121223534561

常用API网关

Kong

Kong 基于OpenResty（Nginx + Lua模块）编写的高可用、易扩展的，性能高效且稳定，支持多个可用插件（限流、鉴权）等，开箱即用。

相对于纯Nginx ，Kong具有以下优点：

（1）高性能：亚毫秒级处理延迟，可支持关键任务用例和高吞吐量。

（2）可扩展性：可插拔的体系结构，可通过Kong的Plugin SDK扩展 Kong。

（3）可移植性：Kong 可以部署在任何平台、或者云。

为什么要使用Kong

Why Kong

Kong组件

Kong组件

Kong overview

Kong 路由和服务

其中：

Nginx和OpenResty层，是Kong的基础，因为Kong是一款基于OpenResty (Nginx + Lua) 编写的高可用、易扩展的API Gateway。

DataStore层：Kong的配置文件可以支持化的存储在NoSQL中，可选：Cassandra、PostgreSQL。

Plugin层：如果想拓展Kong的功能，只需要提供对应的插件就行。可以直接使用现成的插件，也可以编写自定义插件。

RESTful层：它支持通过RESTful API的方式来操作操作和配置Kong（管理Nginx的配置文件）。而且Kong也支持在可视化的界面下配置。

Kong overview

Kong 路由和服务

APISIX

Apache APISIX 是 Apache 软件基金会下的顶级项目，由 API7.ai 开发并捐赠。它是一个具有动态、实时、高性能等特点的云原生 API 网关。

你可以使用 APISIX 网关作为所有业务的流量入口，它提供了动态路由、动态上游、动态证书、A/B 测试、灰度发布（金丝雀发布）、蓝绿部署、限速、防攻击、收集指标、监控报警、可观测、服务治理等功能。

它构建于 NGINX + ngx_lua 的技术基础之上，充分利用了 LuaJIT 所提供的强大性能。

apisix 软件架构

APISIX 主要分为两个部分：

  1. APISIX 核心：包括 Lua 插件、多语言插件运行时（Plugin Runner）、Wasm 插件运行时等；
  2. 功能丰富的各种内置插件：包括可观测性、安全、流量控制等。

APISIX的优势

https://apisix.apache.org/zh/blog/2022/07/30/why-we-need-apache-apisix/

在单体服务时代，使用 Nginx 可以应对大多数的场景，而到了云原生时代，Nginx 因为其自身架构的原因则会出现两个问题：

  • 首先是 Nginx 不支持集群管理。几乎每家互联网厂商都有自己的 Nginx 配置管理系统，系统虽然大同小异但是一直没有统一的方案。
  • 其次是 Nginx 不支持配置的热加载。很多公司一旦修改了配置，重新加载 Nginx 的时间可能需要半个小时以上。并且在 Kubernetes 体系下，上游会经常发生变化，如果使用 Nginx 来处理就需要频繁重启服务，这对于企业是不可接受的。

而 Kong 的出现则解决了 Nginx 的痛点，但是又带来了新的问题：

  • Kong 需要依赖于 PostgreSQL 或 Cassandra 数据库，这使 Kong 的整个架构非常臃肿，并且会给企业带来高可用的问题。如果数据库故障了，那么整个 API 网关都会出现故障。
  • Kong 的路由使用的是遍历查找，当网关内有超过上千个路由时，它的性能就会出现比较急剧的下降。

APISIX

如上图所示，左右分别是 APISIX 的数据面（Data Plane）和控制面（Control Plane）：

  • 数据面：以 Nginx 的网络库为基础（未使用 Nginx 的路由匹配、静态配置和 C 模块），使用Lua 和 Nginx 动态控制请求流量；
  • 控制面：使用 etcd 来存储和同步网关的配置数据，管理员通过 Admin API 或者 Dashboard 可以在毫秒级别内通知到所有数据面节点。

在更新数据上，Kong 采用轮询数据库的方式，但是可能需要 5-10 秒才能获取到最新的配置；而 APISIX 则采用监听 etcd 的配置变更的方式，可以将时间控制在毫秒级，达到实时生效的效果。 而且由于 APISIX 和 etcd 均支持多点部署，因此在 APISIX 当前架构中，任何一个服务出现异常宕机等事故，都不会影响 APISIX 正常对外提供服务的能力。

Traefik

Traefik 是一个使用Go语言开发的云原生的新型的 HTTP 反向代理、负载均衡软件。它负责接收系统的请求，然后使用合适的组件来对这些请求进行处理。它支持多种后台 (Docker, Swarm, Kubernetes, Marathon, Mesos, Consul, Etcd, Zookeeper, BoltDB, Rest API, file…) 来自动化、动态的应用它的配置文件设置。

traefik架构

Kubernetes和Service Mesh

Kubernetes-vs-ServiceMesh

从图中我们可以看到 kube-proxy 的设置是全局的，无法对每个服务进行细粒度的控制，Kubernetes 可以做的只有拓扑感知路由、将流量就近路由，为 Pod 设置进出站的网络策略。

而服务网格通过 sidecar proxy 的方式将 Kubernetes 中的流量控制从服务层中抽离出来，为每个 Pod 中注入代理，并通过一个控制平面来操控这些分布式代理。这样可以实现更大的弹性。

目前国内最流行的服务网格开源实现是 Istio， Istio 是在 Envoy 的基础上开发的，它默认使用了 Envoy 作为它的分布式代理。Envoy 开创性的创造了 xDS 协议，用于分布式网关配置，大大简化了大规模分布式网络的配置。

在列举过以上 Kubernetes 和服务网格的对比后，我们可以看出服务网格在云原生应用架构中的地位。那就是构建一个云原生网络基础设施，具体来说就是：

  • 流量管理：控制服务间的流量和 API 调用流，使调用更可靠，增强不同环境下的网络鲁棒性。
  • 可观测性：了解服务之间的依赖关系和它们之间的性质和流量，提供快速识别定位问题的能力。
  • 策略实施：通过配置网格而不是以改变代码的方式来控制服务之间的访问策略。
  • 服务识别与安全：提供在网格里的服务可识别性和安全性保护。

在启用了Istio服务网格的Kubernetes集群中，缺省情况下只能在集群内部访问网格中的服务，要如何才能从外部网络访问这些服务呢？

https://www.zhaohuabing.com/post/2019-03-29-how-to-choose-ingress-for-service-mesh/

Kubernetes Ingress

Kubernetes 起初只有 NodePort 和 LoadBalancer 类型的 Service 对象可以将集群内的服务公开给外部。

nodeport-loadbalancer

随着容器和Kubernetes技术的兴起，集群入口流量管理方式逐渐通用化、标准化。Kubernetes通过定义Ingress资源用来管理外部访问集群内部服务的HTTP/HTTPS流量。为了保持其可移植性和轻量级设计，Ingress API 比其他 Kubernetes API 成熟得更慢；直到 Kubernetes 1.19才升级到 GA。

ingress

Ingress 的主要目标是使用简单的声明性语法公开 HTTP 应用程序。当在 Kubernetes 创建一个入口或者设置一个默认的入口类时，你可以部署几个入口控制器，并通过入口类定义网关使用的控制器。Kubernetes 目前默认情况下只支持 AWS、 GCE 和 Nginx Inress 控制器; 还支持许多第三方入口控制器。

Kubernetes Ingress workflow

k8s ingress

尽管 IngresClass 将入口网关与后端实现分离开来，但是它仍然有很大的局限性。

  • Ingress对于大多数现实世界的使用来说太简单了，它只支持HTTP/HTTPS协议路由。
  • 它只支持主机和路径匹配，对于高级路由功能没有标准的配置，这只能通过注解来实现，比如使用 Nginx 插入控制器的 URL 重定向，这需要配置 Nginx.Ingress.kubernetes.io/rewrite-target 注解，不再适应可编程代理的需要。
  • 不同名称空间中的服务必须绑定到同一网关，而实际情况是入口网关通常不能在多个名称空间之间共享。
  • 没有描述创建和管理入口网关的职责，导致开发人员不仅必须配置网关路由，而且还必须自己创建和管理网关。

Kubernetes Gateway

Gateway API是API资源的集合：GatewayClass、Gateway、HTTPRoute、TCPRoute、ReferenceGrant等。Gateway API公开了一个更通用的代理API，它可以用于比HTTP更多的协议，并为更多的基础设施组件建模，为集群操作提供更好的部署和管理选项。

Gateway API workflow

image-20240128115516044

IngressAPI –> Gateway API

不同于 Ingress API，将集群运维和业务运维的职责进行了划分，这样业务开发人员不再需要关心网站证书等集群级的细节，只专注于业务本身的 DevOps，集群运维任务可以交给 SRE 人员进行统一处理。

image.png

参考资料

最后更新于 • Q1mi