一个简单的全接口日志设计文档，先分享设计文档，后面分享核心设计代码。
对外接口要遵守的基本原则：
1、 开闭原则
2、 依赖倒置原则
3、 单一职责原则
4、 接口隔离原则
5、 迪米特发则（最少知道原则）
6、 里氏替换原则
7、 合成/复用原则（组合/复用原则）
以上原则还可以进行组合、剪裁，根据实际情况搭建接口框架、技术选型。
本次设计方案按照基本原则剪裁，对外提供的API接口遵循以下设计原则：
1、 安全性
2、 幂等性
3、 数据规范统一
2.1.接口交互流程设计
对外接口的交互流程设计如上：
接口请求在安全方面除了apiKey、apiSecret权限校验，再增加有效token校验。
1、 客户端黑白名单 （可以提到运维级别做基本的ip限制）
2、 客户端加强版黑白名单 （设计黑白名单、限制拒绝请求时长等）
3、 请求限流
4、 https协议，优先采用post请求
5、 请求参数增加签名防伪
6、 防止重放攻击 （业务数据）
扩展机制可以剪裁，同时实现可以采用配置文件方式实现，也可以采用统一接口管理。
从长久考虑，为方便以后运维，服务治理，接口记录、日志查看，统一接口管理方式更合适，而且是一劳永逸，后期甚至可以做到轻运维，接口日志查看、接口异常分析也更方便。
对接口统一增加幂等机制，防止恶意请求占用资源，避免资源浪费、影响性能。
同时可以考虑与客户端黑名单、接口限流机制做结合，对具体异常接口做监控、记录异常日志、设置接口限流策略，设置实时生效。
以上是一个概要流程图，具体个流程细节节点与架构设计、表设计、技术选型有关。后面实现可见各分项实习的细节。
前期整体架构设计时就明确了BASE的统一对接地位，相当于我们的网关层。现在的对外接口架构设计是在原整体设计上扩展架构，出入口统一走BASE，BASE增加一层“路由”逻辑，主要负责接口请求全链路的相关认证、限流、路由等机制。接口实现由园xxx、生xxx、安xxx具体实现。
1、静态授权：
apiKey + apiSecret方式
配合授权管理：负责apiKey、apiSecret的分配、授权有效期等基本管理
2、动态授权：
根据静态授权信息apiKey /apiSecret获取动态有效期的token，第三方请求BASE的接口携带token。
3.1.2.权限机制
1、有效token校验
2、验证接口是否开放
配合接口管理：负责接口相关信息配置，包括接口url、是否开发、版本信息，以及简单的限流策略设置等。
1、请求参数按照约定规则计算sign
2、前端按照约定生成jwt令牌，请求时携带，后端验证令牌
1、配合接口配置信息，匹配限流策略做相关校验 （计数器限流）
2、配合黑白名单管理信息，做请求抛弃返回提示信息
3、令牌桶限流，使用redis-reactive或guava
基于redis简单实现（非绝对严谨）：
配合sign实现，sign作为key放redis，并设置过期时长。如果key存在，则认为是重复提交。
这块的设计应该是属于一个支撑的界面配置的设计，内部实现，时间来不及，没有资源可以先不提供界面。这里的接口日志与业务日志有交叉，可以扩展支撑业务的日志。
负责配置接口信息，新增、修改的信息实时缓存。
3.2.1.1.表结构设计
主键、接口名称、接口提供方、接口controller、接口url、方法名、请求类型、版本、业务类型、接口类型、接口状态、接口描述、开启开始时间、开启结束时间、请求限制频率（1s次数）、是否删除
3.2.1.2.界面设计
待补充
负责配置接口请求来源的黑名单ip，可设置限制策略。
3.2.2.1.表结构设计
主键、ip、限制类型（允许\拒绝）、开始时间、结束时间、是否删除
3.2.2.2.界面设计
待补充
记录接口请求日志、出参、入参、方法补充内容。同时从日志提取接口到接口管理，然后在接口管理补充相应配置信息即可接入权限使用。
3.2.3.1.表结构设计
主键、接口id（接口信息表主键）、请求ip、入参、返回数据、耗时、请求来源、业务接口补充（说明）、请求时间
3.2.3.2.界面设计
待补充
此流程为授权认证机制、授权机制、接口防伪机制3个机制合并流程。
1、配合接口配置信息、黑名单、做异常请求拦截
2、削峰限流（保障性能，如果接口是必须支持，可以去掉）
序号 规范名称 内容 备注
1 请求协议 https/http 推荐https
2 接口类型 Post/get 优先post
3 传参 Headers + body（json） 禁止路径传参方式
4
BASE提供接口文档、负责接口配置等工作。
接口url约定：
所有接口都不禁止使用路径传参，例如：/传参1/传参2
接口url除域名、ip、上下文外，固定以baseOpenApi/开头
权限传参放在headers：
token：请求BASE活得接口请求授权token
sign：约定生成，md5值，传参按照key的自然顺序排序组成字符串生成md5值。
Jwt：约定生成，具体格式：标准载荷 + 自定义载荷（请求方apiKey、apiSecret、token），RS256非对称加密
业务传参放在body：
以json形式，具体根据接口文档。
以json对象返回，BASE可提供统一泛型对象。
出参key 出参valu 类型 说明
code 200 数字 200表示成功，其他均表示异常，具体异常原因见message
data 接口返回数据 Json串
message 信息 String SUCCESS表示成功，其他字符串为接口返回
示例格式如下：
{
“code”: 200,
“data”: {
“countId”: “”,
“current”: 1,
“optimizeCountSql”: true,
“orders”: [],
“pages”: 0,
“records”: [],
“searchCount”: true,
“size”: 2,
“total”: 0
},
“message”: “SUCCESS”
}
日志体系配合缓存，实现从请求进入系统，到进入业务接口，再到出业务接口，返回数据全流程的监控。
业务接口中实现可取本次请求日志，补充相关信息重新放入缓存，接口后置事件时做最好日志设置异步执行记录接口日志。
对于日志的保存有2个设计思路，一个AOP切面+缓存+自动任务，一个是AOP切面+缓存+kafka消息队列。
2种方案理论上都没有问题，唯一就是对业务接口开放了补充日志内容的过程，可能导致插入数据库的sql执行报错，这个就需要在保存到数据库前做一定的格式、字段长度等校验，保证数据库执行成功。否则可能会导致日志缓存积压、kafka消息队列积压。
