接口设计原则

系统越来越多，越来越复杂，项目开发中不可避免的遇到多个系统间调用，例如A调用B、B调用C

可能遇到以下问题

1、A调用B接口不通、或者B接口响应时间太长、影响体验及吞吐量

2、上游系统压垮下月系统

3、系统越来越多，线上问题排查变得越来越困难

针对以上问题大概总结优化如下

1、尽量减少外部接口依赖，例如A 想要获取订单列表 这个时候需要调用B ，根据实际业务场景可以适当的将获取到的订单Redis缓存起来，设置有效期

2、针对接口相应时间特别慢的，例如TP99 大于1s甚至3s等，这个是不可接受的，上游系统一直等待影响体验，应该统一配置超时机制，并给予友善的提醒

3、能异步的尽量异步操作：例如别人在调用你开发的接口时，根据实际情况返回核心数据，其他数据可以采用MQ(解耦、异步、削峰) ，保证数据最终一致性

4、对外提供接口、核心方法一定要配置监控（调用频率、响应时间、可用率等），也可以根据业务需要对功能、接口等设置降级方案

5、接口参数尽量用简单的类型，比如基础类型Integer、Boolean等，如果使用自定义类型，也清保证此类型结构尽量简单、嵌套成熟尽量少，减少序列化时的消耗

6、传输的数据尽量小，大数据不可避免的会占用更多的带宽

7、线上问题排查，内部接口尽量统一系统间的返回值，例如接口调用成功还是失败、相关说明等

/**
* 页面返回值
* @param <T>
*/
public class ExecResult<T> implements Serializable {

private static final long serialVersionUID = 588661676563845067L;

/**
* 返回信息（成功或者失败信息，方便跟踪调试）
*/
private String message;

/**
* 状态码，双方约定好规则，比如1代表成功，-1代表失败
*/
private Integer statusCode;

/**
* 返回值对象
*/
private T result;

public ExecResult() {
}

public ExecResult(Integer statusCode) {
this.statusCode = statusCode;
}

public ExecResult(Integer statusCode, String message) {
this.statusCode = statusCode;
this.message = message;
}

public ExecResult(T result) {
this.statusCode=1;
this.result = result;
}

/**
* 页面返回值
*
* @param <T>
*/
public class PageResult<T> implements Serializable {

private static final long serialVersionUID = 588661676563845067L;

/**
* 信息
*/
private String message;

/**
* 状态码
*/
private Integer statusCode;

/**
* 返回值对象
*/
private List<T> content;
/**
* 集合大小
*/
private long totalNum;

public PageResult() {
}

public PageResult(Integer statusCode) {
this.statusCode = statusCode;
}

public PageResult(Integer statusCode, String message) {
this.statusCode = statusCode;
this.message = message;
}

public PageResult(List<T> content, int totalNum) {
this.statusCode = 1;
this.content = content;
this.totalNum = totalNum;
}