【原】关于接口规范的重要性

    前言：单体项目拆分为SOA分布式架构后,关于接口层的定义规范尤其重要。今天就总结一下关于一次不规范的定义接口导致的问题。

　　#首先我目前从事的项目架构大致是下图这样的（借鉴58沈剑的图）：

         主技术栈：dubbo+spring boot;其中我们内部的wap、app、pc都有相似的业务,例如user-service。

　　　　

　　

    #出现问题起源

      产品给了一个比较急的需求,是关于以前一个校验漏洞的修复,经过代码查阅,我开始定义的接口是：

      int queryUserIsOpen(String cardId);

      后来发现返回的类型无法满足我业务的需求,于是我进行改造后如下:

      Result queryUserIsOpen(String cardid,int userType);

      在PC端测试OK后直接丢上生产;结果第二天收到反应wap端和app端某业务出现异常,进行日志排查发现报错是返回类型有误。后来才想起其他端也有调用这个方法,由于我改了接口返回的参数类型,然后又发布到了线上,那么之前的服务已经被我的版本覆盖,这时候其他端还是用的旧的代码,一旦它们那边远程调用后由于返回的实际是Result,但它们还是用 int去接收。

     于是我先让wap和app升级我改的版本,然后同步两边代码后再发到生产以此解决这个问题。

   #为什么SOA架构会普遍存在这个问题：

　　库的版本维护与业务线之间代码的耦合：

　　业务线A将user.so由版本1升级至版本2，如果不兼容业务线B的代码，会导致B业务出现问题；

      业务线A如果通知了业务线B升级，则是的业务线B会无故做一些“自身业务无关”的升级，非常郁闷。当然，如果各个业务线都是拷贝了一份代码则不存在这个问题。

   #如何避免这个问题

   很早之前就有看过接口规范的必要性,但有时候大意了忽略了其他部门负责的也共同调用了这个服务。通过上面的例子不难发现其实一开始只要定义好接口的规范就可以避免这个问题。如刚开始就定义好返回的bean为Result,入参统一为Vo,那么当我下游出现变动,由于返回的结果已经显示规定好了为Result,那么就避免了刚开始我在文中遇到的那个问题,减少线上维护的成本。

  Result代码如下：

　　

public class Result<T> implements Serializable {

    private static final long serialVersionUID = 1L;

    /** 返回代码 */
    private String code = "200";

    /** 返回错误消息提示 */
    private String message;

    /** 如果需要验签则返回请求过来的token */
    private String token;

    /** 返回客户端的签名 */
    private String sign;

    /** 返回结果 */
    private T t;

    public Result() {
        super();
    }