32.网关异步分发讨论

## 1.背景
![](/media/202411/2024-11-05_092604_854018.png)
如上图所示，业务场景是：ERP系统向GTMS系统发送一批数据，接收到下游系统的响应后，接着发送下一批数据。但是实际的场景是：ERP系统向GTMS系统发送请求，GTMS系统处理数据时间过长，超过了网关(与ingress)的超时时间，导致ERP系统接收到错误的响应，不得不再次重发，依次循环。
## 2.常规方案
当下游系统消费数据的能力跟不上上游系统时，通常有三种解决方案
1>上游系统控制数据量，满足下游系统在正常时间内处理完数据，返回成功。这样做的弊端是：数据积压在上游系统，同时存在数据的及时性问题，如上真实场景中：ERP系统每天大约有7w条数据发往GTMS系统，平均每120s发送100条数据，则每小时发送3000条数据，则一天(12小时)只能发送3.6w条，很明显7w条数据一天都发不完。
2>下游系统改造，先保存数据，后处理数据，即接收到数据后不做任何逻辑处理，直接保存数据，保存成功后马上响应成功。接着启动多个线程来消费数据。本业务场景中，不限制下游系统的业务处理时间，即下游系统及时处理数据慢一些，也不影响。
3>添加中间件，接收上游系统发送的数据，削峰，发送给下游系统。
## 3.讨论方案
如上的业务场景中，下游系统无法改造，只能同步接收数据，自行处理，然后返回响应结果。而上游系统改造的话，则会造成数据的积压，永远发不完数据，因此我们讨论了添加中间件的方案，刚好如上两个系统之间的交互走了网关，则网关承担了中间件的作用。方案如下
![](/media/202411/2024-11-05_094316_213873.png)
上游系统将数据发送给网关，网关马上响应成功；接着网关自行将数据发送给下游系统，重点是网关不需要关注下游系统的响应结果。
## 4.具体执行
![](/media/202411/2024-11-05_094523_109432.png)
1>ERP系统发送请求，经过sign插件、request插件、divide插件。
2>divide插件的rule中拦截这次请求路径，判断这个路径的请求是同步还是异步。
3>同步的话，走HttpClient插件执行具体请求，同步响应业务结果。
4>异步的话，将请求信息发送到中间件中，这里的中间件选择RocketMQ，同步返回请求结果(注意这里不是业务结果)
4.1>启动中间件的消费器，实时消费本次请求，然后重新请求网关，只是插件的拦截信息改变了(插件的拦截信息来源于源系统请求时带过来)
4.2>在经过sign插件、request插件、divide插件，这里就执行同步请求，执行HttpClient插件了。
## 5.总结
自此就完成了网关的异步分发。

## 6.主数据分发
![](/media/202411/2024-11-05_101231_356853.png)

## 7.各个流程参数定义
### 7.1 单次异步请求
源系统：

## 8.修改记录
日期|修改人|修改内容|
---|---|---
2024年11月05号|李贤利|新建文档