【原】關於接口規範的重要性

    前言：單體項目拆分爲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();
    }