接口设计原则

 

    系统越来越多，越来越复杂，项目开发中不可避免的遇到多个系统间调用，例如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;
	}