网关项目
- 1. 了解网关
- 网关横向对比
- 为什么自研网关
- 2. 架构设计
- 技术栈
- 技术要点
- 异步化设计
- 使用缓存缓冲
- 合理使用串行化
- 吞吐量为王
- 合适的工作线程
- 架构图
1. 了解网关
概念
- 访问数据、业务逻辑或功能的 “
前门” - 负责处理接受和处理调用过程中的所有任务
类型
- RESTful APl 使用
HTTP API构建 - WebSocket APl 通过
WebSocket API构建
优势
- 简化客户端的工作
- 降低函数间的耦合度
- 解放开发人员把精力专注于业务逻辑开发
劣势
- 在微服务这种去中心化架构中，成为瓶颈点
- 服务如果不是异步或者同步非阻塞，耦合度高
解决问题
- 路由转发
- 协议转换
- 服务监控统计
- 熔断限流
- 日志
- 优雅下线
网关横向对比
- Nginx + OpenResty
- 同时作为流量网关和业务网关
- C语言开发，性能非常好
- 基于 lua 语言扩展功能
- Kong / APISIX
- 基于Openresty
- 提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能
- 支持gRPC，Dubbo，Http等协议转换
- Netflix Zuul1.0
- 中小厂落地案例丰富
- 基于同步阻塞O，性能差
- SpringCloud Gateway
- 与SpringCloud生态完美兼容
- 异步非阻塞IO，性能好
- Netflix Zuul2.0
- 性能接近SpringCloud Gateway
- Netflixi进入维护期，前景不明
为什么自研网关
开源网关缺点：
- 开源网关的组件以及附加功能太多，使用起来就越麻烦，我们希望网关足够的薄，只满足我们的业务即可。
- 技术栈不符合团队，如果我们使用的是Go语言，那么以上的开源网关都不符合
- 开源网关性能参差不齐
自研网关优点：
- 因需制宜。例如：可以定义某个接口走同步还是异步，比如要求一致性高的接口走同步，不要求一致性的走异步。
- 研发需求以及进度可控。例如：如果开源网关出现漏洞，则需要等开源社区完善。
2. 架构设计
技术栈
基础框架
- 原生Java
网络通信框架
- Netty
注册中心
- Nacos
配置中心
- Nacos
技术要点
异步化设计
需要异步化的地方
- 请求转发异步化
- 请求响应异步化
- 插件过滤异步化
插件过滤使用单异步模式，单异步模式：发送和接收请求使用的是同一个线程，但是可以多线程同时发送和接收
请求响应使用双异步模式，双异步模式：发送和接收请求可以使用不同的线程。
如果下游服务器性能不是很高，响应时间在 500 - 2000 毫秒，则可以使用 双异步模式，如果性能高，则使用 单异步模式
异步神器CompletableFuture
- Future局限性
- CompletableFuture简介
使用缓存缓冲
尽量使用内存作为缓存(Map、Queue）
合理使用串行化
串行化使用场景：
- 耗时较小，性能较高的场景。（避免线程频繁的切换）
并行化使用场景：
- 耗时较久，任务之间没有依赖关系，比如远程RPC调用场景
吞吐量为王
流量高峰使用本地缓冲(Disruptor、MPMC)
合适的工作线程
CPU密集型
- CPU核数 + 1
IO密集型
- 公式1：CPU核数 * 2
- 公式2：CPU核数 / （1 - 阻塞系数）。阻塞系数：0.8 - 0.9 之间
架构图
