网关技术实现如图：

网关初始化时，从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办法创立一类路由的流程模板：

  1. 从数据源获取路由信息apiPlan
  2. 增加网关公共断言（实现addCommonPredicate接口）
  3. 增加公共过滤器（实现addCommonFilter）
  4. 增加特定断言/过滤器（实现addSpecificDynamicRoute）
  5. 公布路由

扩展性的实现：

  • 不同的网关实现各自的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解决。