设计实现一个轻量的开放API网关

关最基本的功能是转发请求, 常见的方式是根据配置中的路由规则将请求转发给内部服务, 如:

将/order/*的请求转发给内部的订单系统、/user/*的请求转发给内部的用户系统, 这种做法常用于对整个业务系统负责的基础网关.

而本文所设计的是服务于第三方的开放API网关, 并未使用上述做法, 而是将请求的资源作为参数放到请求体中, 其原因如下:

1. 开放API服务于第三方, 屏蔽内部路径, 有利于提供命名统一且规范的接口.
2. 请求接口的映射由网关的路由表维护, 内部接口升级甚至切换到新服务对外接口不变.
3. 能够更细粒度地针对接口进行权限控制、限流、统计等.

地址

开放API网关对外提供唯一入口, 具体请求的资源作为参数传入.

公共参数

为了简化签名和验签的操作, 同时也提高灵活度, 唯一入口的约定了固定的公共参数和返回值, 如下:

公共请求参数
 

• pp: 调用方主体, 用于标识请求方身份.
• group: 组, app分组, 可通过group统一进行授权.
• subject: 主体(app/group).
• resource: 资源, 维护请求资源与内部接口的映射关系, url+http_method 对应唯一的resource_id.

技术选型

网关除了满足功能上的需求外, 性能上的需求也需要着重考虑, 毕竟作为各个业务系统对外的唯一入口, 网关的性能可能会成为整个业务系统的瓶颈. 业务并不复杂, 性能要求高, 响应式编程正是一个不错的选择.

• Spring WebFlux + netty: 响应式Web框架.
• Spring Data Reactive Redis + Lettuce: 响应式redis客户端.
• Guava: Google工具包, 使用LoadingCache作为进程内缓存.

结语

网关作为内部系统外面的一层屏障和入口, 除基本功能和性能上的需求外, 监控、统计、日志等都是需要考虑到的问题, 网关方面开源产品众

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!