【自研网关系列】网关的技术选型以及架构设计

🌈Yu-Gateway：基于 Netty 与原生 Java 实现，使用 Nacos 作为注册与配置中心。项目实现多种过滤器，包含路由、负载均衡、鉴权、灰度发布等过滤器。

🌈项目代码地址：GitHub - YYYUUU42/YuGateway-master

如果该项目对你有帮助，可以在 github 上点个 ⭐ 喔 🥰🥰

🌈自研网关系列：可以点开专栏，参看完整的文档

1、市场调研

2、技术选型

性能与可伸缩性

安全性

可观测性

路由能力/高可用

多协议支持

总结

3、技术架构

4、网关处理流程

1、市场调研

在设计一个项目之前，进行全面的市场调研与竞品分析是不可或缺的环节。这一步骤旨在深入了解当前市场上已有的同类产品，明确它们的优势与不足，然后提炼出设计这个项目的一个设计方向。

所以调查了市面上已有的且比较知名的网关项目，列举出了如下这张优缺点以及侧重点的表格。

Gateway名称	优点	缺点	设计侧重点
Spring Cloud Gateway	基于 Spring 框架，拥有庞大的 Spring 生态系统，可以轻松集成其他组件	相对于其他选择，性能较慢。其生态和社区支持较弱	集成多种协议和插件，扩展性
Nginx	高性能，配置灵活，轻量级，高稳定性	模块化程度低，扩展性差，异步处理能力受限	高性能HTTP服务器和反向代理
Apache HTTP Server	模块丰富，社区活跃，跨平台，文档齐全	性能较差，配置复杂，更重量级	多功能Web服务器，重视模块化
HAProxy	高性能，支持TCP和HTTP代理，稳定且成熟	配置不如Nginx直观，缺乏现代Web界面	专注于高并发连接的负载均衡
Traefik	自动化服务发现和配置，容器和微服务友好，易于部署	社区较新，历史较短	云原生环境中的动态配置
Kong	基于Nginx和OpenResty，提供丰富的插件，管理界面友好	高性能场景可能需优化配置，插件生态不如Apache/Nginx	扩展性和插件生态系统

基于上面这些比较成熟且知名度较高的网关，提炼出了设计一个网关的侧重点：

1、性能与可伸缩性:

关注高吞吐量和低延迟处理，以便能够处理大量并发连接和数据流。
设计可在多个服务器、数据中心或地理区域之间伸缩的解决方案。

2、安全性:

实现高级安全特性，如SSL/TLS终止、OAuth、JWT、API密钥验证和防止DDoS攻击等。
确保所有通过网关的流量都符合最新的安全标准和法规要求。

3、可观测性:

提供详细的监控和日志记录功能，使运维团队能够观测和诊断问题。
集成与现有监控工具和警报系统的能力。

4、路由能力:

开发动态路由和负载均衡策略，以支持微服务架构中服务发现的需求。
支持基于URL、路径或头部的路由决策。

5、扩展性:

构建插件架构，使新功能能够以模块化的方式添加。
保持核心轻量级，允许通过插件或服务集成额外功能。

6、多协议支持:

考虑支持多种网络协议，不仅限于HTTP/HTTPS，也包括WebSocket、RPC等。

7、高可用性:

确保网关设计能够容忍单点故障和网络分区，提供故障转移和灾难恢复机制。

基于上面列举出来的这些点之后，就可以开始分析，应该如何从这些点入手将一个具体的问题拆解为几个细粒度的解决方法。

接下来一点一点的对上面的七个点进行分析，分析其具体的解决方法和思路。

于是就有了如下的答案：

1、性能与可伸缩性:

使用 Netty 进行异步网络编程，Netty 是一个高性能的网络应用程序框架，可以处理大量的并发连接。
缓存如 Caffeine 或 Redis 来减少数据库访问频率，提升性能。

2、安全性:

集成 JWT 用于安全的API访问。
利用 TLS/SSL 加密传输数据。

3、可观测性:

集成 Micrometer 或 Dropwizard Metrics 来收集和导出性能指标。
使用 ELK Stack（Elasticsearch, Logstash, Kibana）来收集和分析日志数据。
利用 Prometheus 和 Grafana 进行监控和警报。

4、路由能力:

利用 Zuul 或自定义的 Servlet Filters 进行动态路由。
结合 Consul 或 Eureka 或 Nacos 进行服务发现和注册。

5、扩展性:

设计插件架构，使得可以通过 Java SPI (Service Provider Interface) 加载新模块。

6、多协议支持:

使用 gRPC/Dubbo 来支持RPC调用。
支持 WebSocket 用于双向通信，使用Java的 JSR 356 或 Spring Framework 的WebSocket API。

7、高可用性:

使用 Nacos / ZooKeeper / etcd 来管理网关的配置信息和服务元数据，以支持高可用部署。

好的，那么其实基于上面的分析，就已经可以大致的得到设计一个网关所需要的一些技术上的方向了，接下来的就是确定这些技术，并且确定自己设计该网关时的一个架构图了。

2、技术选型

性能与可伸缩性

参考目前主流的网关的设计，有 SpringCloud Gateway 以及 Zuul，他们的底层都大量使用了异步编程的思想，并且也都有非常重要的网络通信上的设计。

由于我们的网关是自研的，也就是他自己本身就是一个单独的服务，因此我们并不需要使用到SpringBoot这种框架，我们可以直接使用原生Java框架来编写各种重要代码。且 Spring Cloud Gateway 底层也是大量使用到 Netty，所以网络通信上也还是使用 Netty 即可。

缓存以及高性能这方面，分布式缓存我们使用 Redis，本地缓存选择 Caffeine，因为 Redis 是市面上使用最广泛的缓存中间件，而 Caffeine 更是有着本地缓存之王的称号，所以选择这两个主要是看中了其成熟的特点。

然后为了提高其缓存区的性能，这里考虑使用 Disruptor 这个无锁队列，因为其无界队列的特性，可以将其作为缓存区队列提高性能。

安全性

使用JWT，其优点在于简单的Token格式，便于跨语言和服务传递，适合于微服务和分布式系统的安全性设计。

当然缺点也在于我们需要精细的管理和保护我们的密钥。

这里我并不打算支持TLS/SSL，首先是我作为个人开发者，想要去支持TLS/SSL是比较复杂的，并且我还需要管理证书的生命周期，会影响项目开发的进度，因此我并不打算在我的网关中支持TLS/SSL。

可观测性

Micrometer 和 Dropwizard Metrics:

优点: 两者都是成熟的度量收集框架，提供了丰富的度量集合和报告功能。
缺点: 可能需要适配特定的监控系统或标准。

ELK Stack:

优点: 提供了一个完整的日志分析解决方案，适用于大规模日志数据的收集、搜索和可视化。
缺点: 组件较多，搭建和维护相对复杂。

Prometheus 和 Grafana:

优点: 高度适合于时序数据监控，Grafana 提供强大的数据可视化。
缺点: 需要配置和维护 Prometheus 数据抓取和存储。

这里我选择使用最后一种，因为目前市面上这种用的比较多，并且Prometheus相对于其他的更加简单易用。

路由能力/高可用

同时，在上文也提到了，网关是需要用到注册中心的，因为我们的请求具体最后要转发到那个路由，是需要从注册中心中拉取服务信息的，目前注册中心有：Zookeeper，Eureka，Nacos，Apollo，etcd，Consul

他们各有优劣势，比如Zk保证的是CP而不是AP，我们知道，网关是应用的第一道门户，我们使用 Dubbo 的时候会使用 Zk ，但是对于网关，可用性大于一致性，因此 Zk 我们不选。

而 Eureka 都和 Spring Cloud 生态有比较紧密的联系，因此如果我们使用它，就会增加我们的网关和 Spring Cloud 的耦合，不太符合我们自研的初衷，所以也不选。

Etcd 虽然是通用的键值对分布式存储系统，可以很好的应用于分布式系统，但是依旧没有很好的优势，当然，他很轻量级。所以这里暂不考虑。

Consul 和 Etcd 差不多，所以这里也不考虑 Consul。

这里我选用 Nacos 作为注册中心，Nacos 首先支持 CP 和 AP 协议，并且提供了很好的控制台方便我对服务进行管理。同时，Nacos 的社区相对来说非常活跃，网络上的资料也更加的多，同时，我也看过 Nacos 的源码，编写优雅且相对易懂。同时我相信会使用 Nacos 的人肯定更多，因此在这里选择 Nacos 作为注册中心。

当然，上面的几种注册中心都可以使用，没有特别明显的优劣势，他们也都有各自合适的场合，具体场合具体分析，主要是要分析自己的团队更加了解或者适合哪一种注册中心。

而配置中心方面，有SpringCloud Config，Apollo，Nacos。

这里很明显，依旧选择 Nacos，因为 Nacos 不仅仅是注册中心也是配置中心。因此选用 Nacos 我们可以减少引入不必要的第三方组件。