基于netty构建API网关(协议适配)

  用户访问系统入口也变得多种方式,由原来单一的PC客户端,变化到PC客户端、各种浏览器、手机移动端及智能终端等。

  同时系统之间大部分都不是单独运行,经常会涉及与其他系统对接、共享数据的需求。所以系统需要升级框架满足日新月异需求变化,支持业务发展,并将框架升级为微服务架构。“API网关”核心组件是架构用于满足此些需求,很多互联网平台已基于网关的设计思路,构建自身平台的API网关,国内主要有京东、携程、唯品会等,国外主要有Netflix、Amazon等。

  但是以上网关框架只能是满足部分需求,不能满足企业的所有要求,就我而言,我认为最大的问题是没有协议转换及OPS管理控制平台

  这类场景,前端应用通过 API 调用后端服务,需要网关具有认证、鉴权、缓存、服务编排、监控告警等功能。

  这类场景,主要为了满足业务形态对外开放,与企业外部合作伙伴建立生态圈,此时的 API 网关注重安全认证、权限分级、流量管控、缓存等功能。

  这类场景,主要为了企业内部存在不同部门,而部门之间技术栈的不同,使用的通信协议或框架不同,需要一个通用的网关来支持内部系统互联及互通,此时API网关会更注重协议转换的功能,比如说gRPC和Dubbo的协议转换

  另外:对于微服务架构下,如果基于HTTP REST传输协议,API网关还承担了一个内外API甄别的功能,只有在API网关上注册了的API还能是真正的对外API

  负责接收客户端请求、执行过滤器、 路由请求到后端服务,并处理后端服务的请求结果返回给客户端。

  提供统一的管理界面,开发人员可在此进行 API、定义过滤器及定义过滤器规则。

  实际的IO读写(内核态与用户态的数据拷贝)阻塞与非阻塞IO的区别在于第一步,发起IO请求的进程是否会被阻塞,如果阻塞直到IO操作完成才返回那么就是传统的阻塞IO,如果不阻塞,那么就是非阻塞IO;

  同步IO和异步IO的区别在于第二步,实际的IO读写(内核态与用户态的数据拷贝)是否需要进程参与,如果需要进程参与则是同步IO,如果不需要进程参与就是异步IO;

  如果实际的IO读写需要请求进程参与,那么就是同步IO。因此阻塞IO、非阻塞IO、IO复用、信号驱动IO都是同步IO

  从以上来看HTTP请求是适合同步非阻塞的方式,一个HTTP请求必然有REQUEST和RESPONSE,而在zuul2上实现的真正网络IO也是同步非阻塞,只不过在HttpAsyncEndpoint这个Filter执行HTTP请求时采用了异步方式,如下:

  gRPC基于protobuf来做传输,所以整个在gRPC的客户端来说,必须有protobuf的数据来描述当前此次gRPC请求,而proto文件是一个合适的数据描述方式,[grpc-web](也是如此来做http请求的转换

  1.将proto文件转化为protobuf的FileDeorSet对象,该对象描述了所有的proto内容,而转化也很简单,利用protobuf提供的命令即可转化,在这里我使用的是:

  在dubbo的框架设计中,其中已经包含了泛化调用的设计,所以在这块,基本上就延用了dubbo的泛化调用来实现http转dubbo的协议

  利用了[JsonPath](及Freemarker模板可以实现参数裁剪的效果,其设计思路可以参照,[amazon的做法](,实现效果如下:

  重复利用drools和groovy这些动态语言,能够将规则开放给业务系统来维护。