共计 3074 个字符，预计需要花费 8 分钟才能阅读完成。
网关技术实现如图：
网关初始化时，从 redis 获取配置，包含路由信息，机构的密钥（用于业务数据加解密），平台对机构的公私钥（用于签名验签），机构可拜访 api 的权限，机构黑白名单。并将这些配置信息保留至内存。这些信息在治理端配置。
通过 redis 对配置变动进行监听，如果有变动则更新内存或重建路由
路由信息包含后端对接形式，后端地址，依照 api 名称和版本进行断言
与后端对接形式目前有三种：
- http：惯例的 gateway 转发性能
- lb：gatewa 转发到注册至 eureka 的服务，利用场景为适配器，如果网关输入的参数格局和后端须要的不相符，须要裁剪参数
- mq：异步调用
http 的反对：
- 增加 path 断言，裸露同一对外入口
- 增加 apiName 和 apiVersion 断言，找到须要转发的后盾路由，进入对应过滤器
- 重写 path，改为自定义的后盾服务地址。如果通过一系列过滤器，则转发至相应服务
lb 的反对：
- 增加 path 断言，裸露同一对外入口
- 增加 apiName 和 apiVersion 断言，找到须要转发的后盾路由，进入对应过滤器
- 后盾地址命名规定为 /service-name/url，解析后盾地址，设置 route 的 uri 为 service-name 即注册至 eureka 的服务名称，rewritepath 为 url，即理论调用的后盾地址。
- addRequestHeader 增加申请头，设置明码，标记为 gateway 转发来的申请。Lb 的后盾服务对 header 进行校验。
mq 的反对：
- 增加 path 断言，裸露同一对外入口
- 增加 apiName 和 apiVersion 断言，找到须要转发的后盾路由，进入对应过滤器
- 配置后端 scheme 为 mq
定义全局过滤器：如果 scheme 为 mq，则为 mq 类的路由。
- 新建 uuid，将 (uuid, rsp) 放入 map 中，而后将蕴含 uuid 的申请发送至 mq。网关收到 mq 响应时，同样会失去 uuid，再从 map 中获取 rsp 进行响应。
- 将 (uuid, rsp) 放入 map 的同时，也会将 (uuid,curenttime) 放入 exceedMap 中，网关会定时查看 mq 类的交易是否超时。（exceedMap 革新为 linkedHashMap）
- mqfilter 的 isAlready。。因为是全局路由，解决 mq/http 协定的最初的 filter；对于 http，防止走了 nettyroute 又走 forward
技术演进：
- 最开始只有互联网网关，对接的是内部机构，须要对参数进行加解密，签名验签。后续有了新的需要：
开发外部网关：公司外部的零碎做为调用方，走的内网不须要加密，只进行 md5 验证即可。互联网网关和外部网关有共用的 filter，也有各自独有的 filter。与后端的对接形式也有所不同，外部网关没有 lb 的对接模式。
- 提取公共 filter，定义共性 filter，可自由组合 filter 和 predicate 进而构建网关
按需配置：有时须要在内网环境部署网关进行功能测试，只须要配置一条 http 路由即可，没必要部署 redis 和 mq，因而配置信息应反对从配置文件中读取，并且不去监听配置的变动。路由信息的读取也应按对接形式分为 http，lb 和 mq 类，依据网关须要按需配置。
- 路由配置化移除对 redis 的依赖
- 网关性能按需组合
- 全局与部分 filter：原架构 filter 均为全局 filter，由 map 决定交易是否走这个路由。现改为部分路由，创立路由 addCommonFilter 的时候增加。（未实现，因为须要改路由模型，比拟麻烦）
对于同一类网关，断言形式和公共过滤器是雷同的，而不同的对接模式有各自的 filter。为了实现 filter 的复用及灵便配置，定义了 GatewayRouteDynamicService 类，其中 RouteUpdate 办法创立一类路由的流程模板：
- 从数据源获取路由信息 apiPlan
- 增加网关公共断言（实现 addCommonPredicate 接口）
- 增加公共过滤器（实现 addCommonFilter）
- 增加特定断言 / 过滤器（实现 addSpecificDynamicRoute）
- 公布路由
扩展性的实现：
- 不同的网关实现各自的 addCommonPredicate，addCommonFilter 接口，可增加该类网关的共有断言及接口。
- 如果 token 校验，加解密有不同的实现形式，重写 filter 增加到 CommonFIlter 里即可
- 不同的路由类型实现 addSpecificDynamicRoute 接口，如 http，mq，lb
- 数据源可选 redis 和配置文件
- 可选是否监听数据源的变动，如果监听，须要应用 redis
- 后续数据源和监听反对抉择 zk 等中间件
- 目前断言为 apiName+version 对应一条路由。也反对依据传入的机构号，银行号进行路由，继承 predicateFactory 类，实现 addCommonPredicate 即可。
gateway 几大功能模块：
加载并初始化路由：
- 次要是按与后端的对接形式划分，如果有新的对接形式，实现 addSpecificDynamicRoute 接口
如果有 mq 的路由：
- 配置 mq 响应监听：因为有多个 gateway 实例，同一交易的申请和响应应该由同一个 gateway 解决。不同 gateway 的申请 queue 地址一样，但响应 queue 不同。响应 queue 地址在申请交易 jms 信息的 reply 字段，因而后盾服务只需配置申请 queue，响应 queue 蕴含在申请的 jms 信息中。这里响应 queue 地址为 service_name + docker.slot(1, 2, 3…)。这样服务每次重启时，响应 queue 地址不会变动。如果 gateway 弹性扩大，slot+1，不必改变配置文件，实现主动扩容。如果响应 queue 为 docker 容器虚构 ip，服务每次都会新建 queue，会非常凌乱。
- 超时 mq 音讯解决：在 exceedMap 中查看是否有超时交易
读取配置：
- 去除对 redis 的依赖，可抉择从 redis 或者配置文件。注入 redis 或配置文件的实现类。实现配置的获取和实现的拆散，配置批改监听和配置获取的拆散
监听配置批改：
- 能够抉择不去监听，或者通过 redis，zk 监听
- 监听新的配置，如某个 api 的限流大小，监听某个 key 如 change，如果变动值为 value，就从 spring 中找到名字为 value 的 bean，调用 run 办法。
- 如果减少新配置，不必再 if else 或 switch 地改变代码，新建类即可，实现对扩大凋谢，批改敞开。
劣势：
- 更加形象，扩展性更强，
劣势：
- 架构更加简单，调试不便，学习曲线平缓
网关搭建好之后，须要欠缺对网关交易的监控性能。咱们须要实时（准实时）把握交易状况和网关的运行状况，如：
交易监控统计：
- 交易总比数随工夫的变动
- 过来一段时间哪些机构调用哪个银行的哪些 api，哪些 api 被调用的次数最多
- 有没有异样交易，如超时，后盾服务挂掉等引起的失败交易
交易告警：
- 配置告警规定，如果有异样交易，及时发出通知
交易链路日志查看：
- 通过流水号查看网关链路的日志
出报表：
- 过来一段时间机构，银行，api 级别的调用统计状况，便于统计免费
网关服务监控：
- 过来一段时间网关内存应用，gc，沉闷线程数等 jvm 信息，如果有异样及时告警
异样解决：
网关转发申请到后盾的异样：
- 无奈连贯后盾
- 连贯超时
自定义异样：
- filter 未通过的异样，如参数校验失败，token 校验失败，加解密失败等；
- 断言异样，网关未匹配到路由
未知异样：
- 运行时异样等
这些异样在对立的中央由 handler 解决。
对于 mq 类交易异样，个别只有响应超时异样，由守护线程 AutoGcFlux 解决。
