1. 了解网关

概念

• 访问数据、业务逻辑或功能的 “前门”
• 负责处理接受和处理调用过程中的所有任务

类型

• RESTful APl 使用HTTP API构建
• WebSocket APl 通过WebSocket API构建

优势

• 简化客户端的工作
• 降低函数间的耦合度
• 解放开发人员把精力专注于业务逻辑开发

劣势

• 在微服务这种去中心化架构中，成为瓶颈点
• 服务如果不是异步或者同步非阻塞，耦合度高

解决问题

• 路由转发
• 协议转换
• 服务监控统计
• 熔断限流
• 日志
• 优雅下线

网关横向对比

1. Nginx + OpenResty
   • 同时作为流量网关和业务网关
   • C语言开发，性能非常好
   • 基于 lua 语言扩展功能
2. Kong / APISIX
   • 基于Openresty
   • 提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能
   • 支持gRPC，Dubbo，Http等协议转换
3. Netflix Zuul1.0
   • 中小厂落地案例丰富
   • 基于同步阻塞O，性能差
4. SpringCloud Gateway
   • 与SpringCloud生态完美兼容
   • 异步非阻塞IO，性能好
5. Netflix Zuul2.0
   • 性能接近SpringCloud Gateway
   • Netflixi进入维护期，前景不明

为什么自研网关

开源网关缺点：

1. 开源网关的组件以及附加功能太多，使用起来就越麻烦，我们希望网关足够的薄，只满足我们的业务即可。
2. 技术栈不符合团队，如果我们使用的是Go语言，那么以上的开源网关都不符合
3. 开源网关性能参差不齐

自研网关优点：

1. 因需制宜。例如：可以定义某个接口走同步还是异步，比如要求一致性高的接口走同步，不要求一致性的走异步。
2. 研发需求以及进度可控。例如：如果开源网关出现漏洞，则需要等开源社区完善。

2. 架构设计

技术栈

基础框架

• 原生Java

网络通信框架

• Netty

注册中心

• Nacos

配置中心

• Nacos

技术要点

异步化设计

需要异步化的地方

1. 请求转发异步化
2. 请求响应异步化
3. 插件过滤异步化

插件过滤使用单异步模式，单异步模式：发送和接收请求使用的是同一个线程，但是可以多线程同时发送和接收
请求响应使用双异步模式，双异步模式：发送和接收请求可以使用不同的线程。

如果下游服务器性能不是很高，响应时间在 500 - 2000 毫秒，则可以使用 双异步模式，如果性能高，则使用 单异步模式

异步神器CompletableFuture

1. Future局限性
2. CompletableFuture简介

使用缓存缓冲

尽量使用内存作为缓存(Map、Queue）

合理使用串行化

串行化使用场景：

• 耗时较小，性能较高的场景。（避免线程频繁的切换）

并行化使用场景：

• 耗时较久，任务之间没有依赖关系，比如远程RPC调用场景

吞吐量为王

流量高峰使用本地缓冲(Disruptor、MPMC)

合适的工作线程

CPU密集型

• CPU核数 + 1

IO密集型

• 公式1：CPU核数 * 2
• 公式2：CPU核数 / （1 - 阻塞系数）。阻塞系数：0.8 - 0.9 之间

架构图