【原】關於介面規範的重要性

    前言：單體項目拆分為SOA分散式架構後,關於介面層的定義規範尤其重要。今天就總結一下關於一次不規範的定義介面導致的問題。

　　#首先我目前從事的項目架構大致是下圖這樣的：

         主技術棧：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();
    }