内容简介:在网上发现了一个牛X的思路,在做restful的时候,如果业务改变,需要每次都修改controller,后来方便了,直接透传的方式,其实也比较麻烦,每次都要写controller。需求变了接口也发生了改变,长期这样的结果,就是维护成本越来越高。源码:https://github.com/limingios/netFuture/tree/master/api网关/idig8-api-gateway移动互联时代,都在追寻一个万能的解,其实这个解可能不存在。其实后端开发的挑战越来越多。里面很多个controlle
在网上发现了一个牛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. 负责路由协议的转换
- 普通的http接口
- API网关接口的实现
当初一个接口开发一个控制器,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.黑白名单组
>商品详情内的展示,已登录和未登录之间的区别
- 基于Token安全机制认证要求
- 登录鉴权
- 防止业务参数串改
>fiddler抓包工具。可以实现。 - 保护用户敏感信息
>用户Id,在网络上是不进行传输的,都是用token来代替 - 防签名伪造
>客户端和服务端都有一套token和Secret的,传输的时候不是用secret传输,是的签名
-
Token 认证机制整体架构
>整体架构分为Token生成与认证两部分:
- Token生成指在登陆成功之后生成 Token 和密钥,并其与用户隐私信息、客户端信息一起存储至Token表,同时返回Token 与Secret 至客户端。
- Token认证指客户端请求业务接口时,认证中心基于Token生成签名。
-
Token表结构说明:
> 其实如果token加入索引的话,查询也比较快,但是相对于 redis 来说肯定是没有redis快的。
名称 | 类型 | 描述 | 约束 |
---|---|---|---|
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:代码直接看源码,主要是了解思路,对于性能我建议先别考虑,先实现之后才能谈性能问题,性能问题没有绝对的只有相对的。最主要是签名的获取生成的思路。
>>原创文章,欢迎转载。转载请注明:转载自,谢谢!>>原文链接地址:上一篇:
已是最新文章
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 个推微服务网关架构实践
- 【行业分享】(3)—— 支付网关架构演进
- 『互联网架构』软件架构-zuul微服务网关(上)(100)
- 微服务架构基础之 API 网关
- 微服务架构基础之API网关
- 游戏服务器架构系列 - 网关限流
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
How to Build a Billion Dollar App
George Berkowski / Little, Brown Book Group / 2015-4-1 / USD 24.95
Apps have changed the way we communicate, shop, play, interact and travel and their phenomenal popularity has presented possibly the biggest business opportunity in history. In How to Build a Billi......一起来看看 《How to Build a Billion Dollar App》 这本书的介绍吧!