在网上发现了一个牛X的思路，在作restful的时候，若是业务改变，须要每次都修改controller，后来方便了，直接透传的方式，其实也比较麻烦，每次都要写controller。需求变了接口也发生了改变，长期这样的结果，就是维护成本愈来愈高，直接service 经过spring 让他变成controller不就少写不少代码了。源码：https://github.com/limingios/netFuture/tree/master/api网关/idig8-api-gatewayjava
背景
移动互联时代，都在追寻一个万能的解，其实这个解可能不存在。其实后端开发的挑战愈来愈多。里面不少个controller，若是系统愈来愈庞大，致使的结果维护困难。ios
什么是API网关
API网关是一个轻量的java http 接口组件，可无缝将普通的 Serive 方法转换成 http 接口。并从已下几点来达到提升开发效率与接口质量的目的。git
去掉mvc控制器，将http请求直接无缝接入JAVA服务接口
统一出入参格式
统一异常规范
自动检测服务接口规
负责路由协议的转换
普通的http接口
API网关接口的实现
当初一个接口开发一个控制器，1000个接口开发1000个控制器。一个一个封装参数，质量也提升了统一规范，出问题统一的方式回馈。不规范的代码也会被api网关拦截掉。github
代码讲解
就5个类，不到500行代码。开发的人最喜欢又小又精湛的代码，不容易软。方便理解，方便使用，又粗又大的代码，很不方便迁移，很差控制容易软。redis
ApiGatewayHandler.java
转换器和调用加载器
ApiGatewayServlet.java
相似springboot的一个入口类
APIMapping.java
注解暴露类
ApiRequest.java
请求封装类
5.ApiStore.java
API IOC 大仓库
代码的方式流程图spring
请求参数说明：
名称
类型
描述
method
string
方法名称
paramter
json
业务参数
timestamp
long
请求时间戳
实现技术：
java servlet
spring Ioc
Json 转换工具的使用
接口安全的业务需求
接口安全级别分组json
黑名单组
个人，帐户信息后端
白名单组
商品展现，商品列表
3.黑白名单组
商品详情内的展现，已登陆和未登陆之间的区别
api
基于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分钟偏差
签名规则：
已指定顺序拼接字符串 secret+method+param+token+timestamp+secret
使用MD5进行加密，在转化成大写
签名的目的：
防串改
防伪造
防重复使用签名
服务端签名验证的具体流程：
签名认证与API网关的总体认证流程
PS：代码直接看源码，主要是了解思路，对于性能我建议先别考虑，先实现以后才能谈性能问题，性能问题没有绝对的只有相对的。最主要是签名的获取生成的思路。
