在网上发现了一个牛X的思路,在做restful的时候,如果业务改变,需要每次都修改controller,后来方便了,直接透传的方式,其实也比较麻烦,每次都要写controller。需求变了接口也发生了改变,长期这样的结果,就是维护成本越来越高。源码:https://github.com/limingios/netFuture/tree/master/api网关/idig8-api-gateway
背景移动互联时代,都在追寻一个万能的解,其实这个解可能不存在。其实后端开发的挑战越来越多。里面很多个controller,如果系统越来越庞大,导致的结果维护困难。
什么是API网关API网关是一个轻量的java http 接口组件,可无缝将普通的 Serive 方法转换成 http 接口。并从已下几点来达到提高开发效率与接口质量的目的。
1. 去掉mvc控制器,将http请求直接无缝接入JAVA服务接口
2. 统一出入参格式
3. 统一异常规范
4. 自动检测服务接口规
5. 负责路由协议的转换
当初一个接口开发一个控制器,1000个接口开发1000个控制器。一个一个封装参数,质量也提高了统一规范,出问题统一的方式回馈。不规范的代码也会被api网关拦截掉。
代码讲解就5个类,不到500行代码。开发的人最喜欢又小又精湛的代码,不容易软。方便理解,方便使用,又粗又大的代码,很不方便迁移,不好控制容易软。
1. ApiGatewayHandler.java
转换器和调用加载器
2. ApiGatewayServlet.java
类似springboot的一个入口类
3. APIMapping.java
注解暴露类
4. ApiRequest.java
请求封装类
5.ApiStore.java
API IOC 大仓库
代码的方式流程图
名称 | 类型 | 描述 |
---|
method | string | 方法名称 | paramter | json | 业务参数 | timestamp | long | 请求时间戳 |
java servlet spring Ioc Json 转换工具的使用
接口安全的业务需求黑名单组 >我的,账户信息 白名单组 >商品展示,商品列表 3.黑白名单组 >商品详情内的展示,已登录和未登录之间的区别
登录鉴权 防止业务参数串改 >fiddler抓包工具。可以实现。 保护用户敏感信息 >用户Id,在网络上是不进行传输的,都是用token来代替 防签名伪造 >客户端和服务端都有一套token和Secret的,传输的时候不是用secret传输,是的签名
Token生成指在登陆成功之后生成 Token 和密钥,并其与用户隐私信息、客户端信息一起存储至Token表,同时返回Token 与Secret 至客户端。 Token认证指客户端请求业务接口时,认证中心基于Token生成签名。
名称 | 类型 | 描述 | 约束 |
---|
id | number | id主键 | 主键,自增长 | memberId | number | 会员ID |
| accessToken | varchar(50) | Token | 索引 | secret | varchar(50) | 密钥 |
| createdTime | datetime | 创建时间 |
| expiresTime | datetime | 有效期至 |
| clientIp | varchar(50) | 客户端IP |
| clientType | varchar(50) | 客户端类别 |
| eCode | varchar(50) | 设备标识 |
| uCode | varchar(50) | 设备用户标识 |
|
名称 | 类型 | 描述 |
---|
method | string | 方法名称 | param | json | 业务参数 | token | string | token值 | sign | string | 签名规则:md5(secret+method+param+token+secret+timestamp) | timestamp | long | 请求时间搓,允许与服务端10分钟误差 |
签名规则:
1. 已指定顺序拼接字符串 secret+method+param+token+timestamp+secret
2. 使用MD5进行加密,在转化成大写 签名的目的:
1. 防串改
2. 防伪造
3. 防重复使用签名
服务端签名验证的具体流程:
签名认证与API网关的整体认证流程
PS:代码直接看源码,主要是了解思路,对于性能我建议先别考虑,先实现之后才能谈性能问题,性能问题没有绝对的只有相对的。最主要是签名的获取生成的思路。
|