Rain9

https://juejin.cn/editor/drafts/7291238548099661839

网关系统学习整理

起源

网关系统的起源可以追溯到计算机网络的早期阶段。在那个时候，不同类型的网络使用完全不同的协议，这使得它们之间无法直接通信。例如，一个使用 TCP/IP 协议的网络无法与一个使用 Novell IPX/SPX 协议的网络进行通信。

注释1：TCP/IP（Transmission Control Protocol/Internet Protocol）协议是互联网最基本的协议，也是网络通信的基础。它定义了电子设备（如计算机）如何在网络上进行数据交换。

TCP/IP 不仅指定了电脑如何连接到互联网，还规定了数据应该如何在网络中传输。这个协议由两部分组成：

  1. TCP (Transmission Control Protocol)：负责将数据切割成小块以便于传输，并且确保所有的数据包都能够按照正确的顺序到达目标地址。
  2. IP (Internet Protocol)：负责将每一个数据包发送到正确的目标地址。每一台连接至互联网的设备都有一个唯一的IP地址，就像我们现实生活中每一栋房子都有一个唯一的邮寄地址。

除此之外，TCP/IP 协议族其实包含了很多其他重要协议，比如用于路由选择的ICMP、用于域名解析服务DNS、用于邮件传送SMTP等等。这些不同层次和功能上各异但又相互关联配合工作使得整个网络系统能够正常运行。

注释2：Novell的IPX/SPX（Internetwork Packet Exchange/Sequenced Packet Exchange）协议是一种网络通信协议，类似于TCP/IP，主要用于局域网（LAN）通信。它由Novell公司为其NetWare操作系统开发。

  1. IPX (Internetwork Packet Exchange)：这是一个用于数据包交换的网络层协议，类似于TCP/IP中的IP。它负责在网络中路由和传送数据包，并不保证数据包的有序到达或者防止数据丢失。
  2. SPX (Sequenced Packet Exchange)：这是一个端到端的传输层协议，提供了可靠性和顺序性保证，类似于TCP/IP中的TCP。SPX确保所有发送出去的数据包都能按照正确顺序到达目标地址，并确认接收。

值得注意的是，随着Internet及其标准化协议TCP/IP在全球范围内广泛应用, IPX/SPX 协议已经逐渐被淘汰并替代。

为了解决这个问题，研究人员开始开发一种设备——网关，能够在不同类型的网络之间进行转换和路由数据包。因此，网关成为了连接并使各种不同类型和规模计算机网络互相通信的重要组件。

随着技术发展和互联网普及, 网络环境变得越来越复杂且多样化, 同时对数据传输安全性、效率、稳定性等需求也更高, 这使得网关系统也需要具备更多功能以满足需求. 现代化网关设备如路由器、防火墙等除了基本转换和路由功能外, 还常常集成有诸如流量控制、安全防护、负载均衡****等高级功能.

其实一句话概括就是：网关系统起源于早期计算机网络中解决不同协议之间通讯问题而产生，并随着技术进步及应用场景变化而逐渐演变为现今复杂且功能强大的形态.

应用场景

对于现在主流的后端架构来说，微服务的普及范围还是比较广的，毕竟巨石项目的维护与开发都不太灵活。

最主要的问题是所有功能都放在一个系统里面开发部署，其中任意一个模块出现了问题都可能会导致整个系统雪崩。

对于一个应用的稳定性来说，如果没办法对单一的模块做熔断、升级、回滚等操作，线上不可控的概率极大，这也是目前主流采用微服务架构最大的原因之一。

但是，当一个系统的微服务模块数量非常多的情况下，也经常会出现以下问题：

1. 通用性的认证、鉴权、限流等功能会导致每个微服务都存在造轮子的行为；
2. 业务复杂度上升之后，存在域名分配的问题，没办法对每个服务都分配一个新的域名，同时每一个新的服务上线，运维重复配置的工作量多了不少；
3. 太多的域名服务对客户端并不友好，特别是请求层没有做 BFF 的话，每一次拆分新的微服务出来都可能会引起前端的改造；
4. 并非每个服务都是同一种语言或者框架所开发，前面提到的公共的插件并不能满足所有的服务，这个情况可能在 DevOps 系统中比较常见。

为了解决上述的问题，网关系统随之诞生。我们可以通过网关的统一入口来调度各个微服务功能模块，使得每个微服务可以关注于自身的业务功能开发。

注释1： BFF 即 Backends For Frontends (服务于前端的后端)，由于微服务众多，需要一个统一入口根据不同的业务场景作为前端集成使用。 面向后端：BFF 隔离了因不同渠道前端 UI 展示对后端 API 的需求，企业可以在后端构建核心业务领域能力 面向前端：BFF 可以根据已有的后端 API，快速满足不同渠道的前端在 UI 展示上的需求，来不断提升用户体验

注释2： DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

什么是网关系统（Gateway）

网关在用户访问一个域名的过程中扮演了重要的角色。以下是网关可能执行的一些功能：

  1. 路由：网关通常用于将网络流量从一个子网路由到另一个子网。当你在浏览器输入域名并试图连接到服务器时，你的请求可能需要通过多个网络和子网。在这个过程中，每个子网之间都可能有一个或多个网络设备（如路由器或者更具体来说，是作为默认网关的设备）负责将数据包转发到它们应该去的地方。

  2. 协议转换：有些情况下，两个不同类型或使用不同协议（例如TCP/IP和非TCP/IP）的网络需要进行通信，在这种情况下，就需要使用称为“协议转换器”的特殊类型的网关。

  3. 安全性：在某些配置中，例如企业环境中，可以设置安全性较高、功能更强大的“应用层”或“代理”类型的网络门户来增加对进出流量进行检查和控制以提供安全防护。

  4. 负载均衡：对于大型 Web 服务而言, 网关也可以作为负载均衡服务器, 将请求分发至后端多台处理服务器上, 以保证系统能够平稳、高效地运行。

  5. API管理: 在微服务架构下, API Gateway 是一种特殊类型门户, 它会处理所有 API 调用，并执行必要功能如流量管理、身份验证等。

网关作为系统的唯一流量入口，封装内部系统的架构，所有请求都先经过网关，由网关将请求路由到合适的微服务。

网关系统根据请求类型可以分为：

  1. 静态资源网关：处理前端资源数据包括 CSR、SSR 等；
  2. API 网关：随着微服务架构（MSA）的普及，通过统一的 API 网关可以聚合所有零散的微服务资源，保持统一的出入口，降低多项目的接入成本以及其他项目的使用成本。

从功能属性上可以分为：

  1. 流量网关：无关业务属性，单纯做安全（黑白名单）、分流（负载均衡）等；
  2. 业务网关：用户（认证、鉴权）、服务稳定性（降级、容灾）、业务属性灰度、代理（资源代理、缓存）、统一前置（日志、数据校验）等。

所以，市面上常见的网关系统除了提供请求聚合功能之外基本都包含所有通用功能：

  • 认证（验证登录态，一般不做鉴权）
  • 分流
  • 代理（静态资源、API 等）
  • AB test （流量灰度，一般根据 IP 或者用户信息灰度）
  • 缓存（成本不低，看看就行）
  • 等等

Gateway 功能拆解

Nginx

Nginx 作为专业的 WEB 代理服务器，在代理方面能够提供负载均衡、流量切换等功能，脚本语言也有 lua 支持。

那么 Nginx 做不到什么呢？

  1. Nginx 作为专业的转发服务器，对 Session 以及 Cookie 的处理比较弱。
  2. Nginx 仅仅支持 HTTP 协议**（**Email 不算常用功能）。
  3. 虽然可以通过 Lua 脚本来处理一些拓展的功能，但是 Lua 脚本的变更以及修改 Nginx 的配置都需要重新启动无法做到热更新，比较麻烦。
  4. 没有可视化管理界面也是一个比较大的硬伤（开源的有一些可视化配置项目，但跟可视化管理有一定的区别与差距）。

Gateway

业务性的 Gateway 需要做点啥：

  1. 统一鉴权收口，通过统一配置给接口资源添加权限；
  2. 支持 RPC 微服务调用，减少资源消耗；
  3. 系统易于监控，同时可以采集收口进来的信息。

注释3：RPC (远程过程调用) 是一种网络通信协议，它允许运行于一台计算机的程序调用另一台计算机（包括通过网络）上的子程序，就像这个过程在本地运行一样。微服务是一种架构模式，其中每个功能元素都作为一个独立的服务运行，并通过 HTTP/REST、RPC 等进行通信。 以下是支持 RPC 的微服务框架：

  1. gRPC: Google 开发并维护的开源 RPC 框架。gRPC 支持多种语言，并提供了很好的跨平台支持。
  2. Thrift: 由 Facebook 开发并开源的高效 RPC 框架。Thrift 提供了跨语言服务开发能力，并且有一个完整和强大的堆栈用于创建服务。
  3. Dubbo: 是阿里巴巴开源的基于 Java 的高性能、透明化 RPC 框架。Dubbo 支持多种负载均衡策略和多种集群容错方式。
  4. Finagle: Twitter 开源的基于 Netty 的高并发 RPC 框架，支持 HTTP, Thrift, Memcached, MySQL 等协议，并提供丰富管理功能。

使用这些框架可以帮助您更轻松地实现微服务之间以及客户端与服务器之间使用 RPC 进行通信。

通过两者的对比可以看出，Nginx 更关注负载均衡以及反向代理，对业务部分的侵入很低，而 Gateway 作为后端应用，可以携带业务属性，两者可以很好的互补。

业内成熟方案

针对网关系统，以下都是业内比较成熟的框架以及方案：

  • Nginx+Lua：Open Resty、Abtesting Gateway、apisix。
  • Java：Spring Cloud Gateway。
  • Go：Janus、Grpc-Gateway。
  • Node.js：Express Gateway、MicroGateway。

网关系统设计

在系统架构设计上，可以使用 Nginx 作为上文所说的流量网关，由 Nginx 做一层流量代理，通过负载均衡到 Gateway 做业务层的转发处理，这样可以减少自建网关系统的工作量。

网关系统架构

网关基础服务

网关系统拆解

因为流量入口已经有 Nginx 作负载均衡，我们网关的基础服务就可以专注于代理模块的开发：

  1. 专注于前后端资源分发以及不同类型的项目 API 分发；
  2. 常用资源缓存模块；
  3. AB Test 模块；
  4. 通用日志模块。
Last Updated:
Contributors: rain9