跳转至

第六节 微服务网关（Kong）：网关在微服务架构中的作用

1、API Gateway

实际上 API Gateway 可以等同于微服务网关。

在微服务架构中，随着微服务的拆分，这些微服务不可能同时提供对外服务，这样就需要一个网关系统，承接外网的流量。

有了API 网关，各个 API 服务提供团队可以专注自己的业务逻辑处理，而 API 网关则更专注于安全、流量、路由等问题。

1-1 微服务网关主要提供哪些功能

  • 统一流量接入：提供统一的流量入口，这样就可以由统一的入口管理流量，设置各种策略，比如统一的 Token 认证等。
  • 业务聚合：在具体的业务中，经常需要聚合多个服务的结果集，返回给客户端，这个时候可以由 API 网关聚合数据然后返回给客户端。
  • 协议转换：一般入口层，多使用 HTTP 协议的 RESTful 接口，而后端服务的协议可能有多种，比如 gRPC、Thrift 等。
  • 中间件策略：设置统一的中间件策略层，可以在这一层做一些限流熔断、南北向流量的服务治理功能。
  • 安全认证：一些 Token 认证功能，比如数据是否被篡改的认证，可以在 API 网关中做，这也是经常用到的功能。
  • 证书管理：随着对外网安全性能要求的增高，现在基本上都要对外提供 HTTPS 的服务，以保证数据不会被劫持、篡改等问题，在这一层做证书对内网的拆卸非常合适。由一个统一的入口管理接口，降低了证书更换时的复杂度。

1-2 常用微服务网关介绍

  • Kong：几乎是目前最流行的微服务网关，内置了多种网关所需要的功能，后面我们将详细介绍。

Alt Image Text

  • Spring Cloud Zuul：作为 Spring Cloud 的一部分，提供了微服务所需要的网关的大部分功能，最大的优势是对 Java 系统友好。严格来说Zuul 更像是一个微服务网关的框架，而不是独立的产品。

Alt Image Text

  • Traefik：基于 Go 语言实现的微服务网关，代码结构清晰简单，适合做二次开发，也可以作为独立的产品使用，对云原生支持友好。如果技术栈是 Go 语言，值得一试。

Alt Image Text

1-3、双重网关（系统网关和业务网关）

单一的网关系统已经不能满足组织架构和业务的发展了，所以在实际生产中，多采用双重网关结构。

这种结构由多个系统网关和多个业务聚合网关组成

这样配合是因为系统网关多由常见的 Nginx 系网关构成，使用 Nginx 系的网关对运维友好，方便运维做一些监控、日志、安全策略；但往往对研发人员不太友好，不方便扩展。所以后来增加了业务网关，用于服务的聚合，这层网关因为需要做一些业务的聚合策略，平时改动会比较多。

如下图所示，两个网关相互配合，既方便了运维维护，也方便了研发人员扩展，达到某种平衡。

这些网关会根据业务维度拆分，比如分为用户系统网关和内容系统网关。这样拆分的目的，是防止由单一网关的故障带来全站的不可用，从而达到降低故障影响面的效果。

Alt Image Text

2、微服务网关 Kong

https://codechina.csdn.net/mirrors/Kong/kong?utm_source=csdn_github_accelerator

开源网关 Kong是一个轻量级的 API 网关，基于 OpenResty + Lua 开发，提供了丰富的功能以及高度灵活的扩展性，可以通过插件的方式扩展 Kong 的功能。

Alt Image Text

Kong 作为微服务网关，最大的优势就是抽象出了微服务网关的一套模型，而不需要像 OpenResty 那样手动配置。

2-1 微服务网关的一套模型

  • service：服务对应的后端的微服务和 API。一般情况下把一组 API 集合成为一个服务，也就是我们后端的微服务。
  • router：路由指的是流量到达 API 网关后，如何找到后端对应的服务。
  • Admin API：Kong 中的 RESTful 的内部 API 接口。 API 接口可以在集群的任意节点运行，最终同步到所有集群的节点。用于管理 Kong 的各种行为，比如添加 service、router 等。
  • Plugins：Kong 的插件系统。利用插件系统，我们添加新功能就不需要改动 Kong 的核心代码。插件系统自带足够多的功能，比如认证、限流、日志、Metrics 等。
  • Load Balancing：Kong提供了两种负载均衡方式，DNS 和内置的负载均衡器。利用 DNS 模式，可以和 Consul 结合，实现服务发现。内置的负载均衡，则需要自己手动维护后端节点。

2-2 Konga

Kong 官方并没有为开源版本提供图形界面，https://github.com/PGBI/kong-dashboard

Alt Image Text

DB Mode（0.x-1.0）→ DB-less Mode(1.1-1.5)→ Hybird Mode(2.0+)

  • DB Mode：最早的 Kong 版本就是使用这种方式，每个 Kong 都连接了后端 DB，这个 DB 可选为 PostgreSQL 或者 Cassandra。但是这个模式之前有个很严重的 Bug，就是在流量大的时候更新路由配置，会导致 Kong 产生剧烈的抖动。
  • DB-less Mode：无数据库模式，也就是通过声明式的配置方式来运行 Kong。这种方式从某种意义来说是一种倒退，因为它让 Kong 无法通过 API 控制，也就是回到了原始的 Nginx 配置模式，相当于 Service Mesh 失去了控制面。但也因为回归了原始的方式，不会出现 DB Mode 更新配置时导致的一些抖动问题。
  • Hybird Mode：其实也就是引入了 Service Mesh 中的控制面和数据面的模式。相对于上面两种模式有巨大的架构优势，Hybird Mode 通过控制面收敛了数据库的操作行为，Kong 的数据节点不需要再直接连接到 DB 层。这种模式有以下两种优势。
    • 仅控制面节点需要连接到 DB，而不是所有数据节点连接到 DB，对 DB 的压力大大减少，也就降低了数据面出现抖动的概率。
    • 易于管理，不用像之前的 API 调用 Kong 的数据节点时再操作 Admin API 变更，只需与控制面交互即可。

Alt Image Text

2-3 图形化聚合层

统网关和业务网关的架构，实际上这样做增加了一条请求链路。我们这样做是因为业务网关频繁更新，那么有没有办法减少这种更新频率呢？

实际上 Uber 已经在某方面做出了动作，那就是通过图形化界面的方式，聚合后端 API。

Alt Image Text

2-4 长连网关

这里的长连网关，指的是通过私有协议或者 gRPC、HTTP/2 等协议代替 HTTP 协议。

通过长连接通道，减少客户端和网关的建连次数，同时通过压缩 header 等方式，减少通信中产生的流量，以达到提高客户端响应速度的目的，让用户在 App 的使用体验上更上一个台阶。

2-5 Service Mesh 化

其实在 Service Mesh 时代，微服务网关中的某些功能，比如限流、认证、鉴权等通用功能，完全可以让本地的 Sidecar 完成，这样就可以减少微服务链路中的一环，提高服务的吞吐及整体架构的可维护性。