RPC呼叫介面設計

寒露君發表於2019-03-03
RPC

內部RPC呼叫介面設計案例一

DEMO原始碼

介面現狀分析

  • 維護性較差
  • 可控性性差
  • 適用性良好
     
     維護性差: 因需求與日俱增,介面的數量也變得繁多而不可控,介面呼叫關係複雜;可讀性差,學習及維護成本大;
     
     可控性差: 無法細粒度控制到方法,無法動態管理介面、方法(如許可權校驗、流控、降級容錯、方法隔離)等；
     
     適應性好：就是說想怎麼寫就怎麼寫,無拘無束,無需考慮太多;
     
     
複製程式碼
  • 介面現狀舉例
          - Trans001001Facade
          - Trans002001Facade
          - Trans003001Facade
          - Trans004001Facade
          - Trans005001Facade
          - Trans006001Facade
          - 成百上千個Facade向你襲來  ........
      
複製程式碼

每當看到成千上萬個這種介面時,總是感覺菊花一緊一緊的;
這些介面裡隱藏著讓你深深蛋疼的x個未知方法;
對業務做修改和擴充套件時,是否有過一個類一個類翻註釋看捋業務程式碼的經歷？

RPC呼叫介面設計

介面改造設計

  • 通用性
  • 擴充套件性
  • 維護性
  • 可控性
        
        擴充套件性: 介面可以適應突如起來的業務變更,而不對外部產生任何影響;
        
        維護性: 業務易讀、易維護、可動態調整;編碼者只需關注業務實現即可,快速迭代開發;
        
        可控性: 控制權交給控制檯,跟蹤方法執行,動態調整方法(新增許可權,報警,日誌等),無需修改程式碼、上下線;
        
     
複製程式碼

  • 控制檯樣例展示

    因工作比較忙,工程處於開發階段
    詳細設計因公暫不能公開

RPC呼叫介面設計

  • 設計思路

    設計離不開場景,切記

    • 維護性：便於管理, 採用統一介面呼叫方式, 對外部服務只暴露一個介面, 介面業務引數統一採用Json格式, 以介面文件約定開發規則;
    • 可控性：為加強對介面、方法的管理控制; 方法和介面由簽名做對映關係、由spring容器或自定義容器來管理、操作;
    • 擴充套件性：因對外部介面暴露的是簽名, 那麼可以控制簽名的狀態來對訪問做控制和隔離; 對容器裡的例項做攔截鏈; 動態的為業務增加功能;
    • 適用性：約定大於俗稱; 開發人員只需關注業務程式碼開發, 內部服務聯調介面只需配置即可啟用, 無需再為介面欄位變更和介面名變更而憂愁, 加快開發進度;
    • 易讀性：採用Spring容器管理和反射原理做基礎實現, 通俗易懂;
    • 難點：分散式下，應用叢集、同城、異地機房部署叢集的介面、方法管理;

介面文件demo

RPC呼叫介面設計

介面說明

  • 統一呼叫介面commonFacade.process(Request req);
  • 介面統一入參Request
  • 統一出參Result
  • 入參出參按介面文件約定進行互動
  • 示例
 @Test
    public void testTransQuery(){
        Request trans = remoteRequest("small.pay","trans.small.pay.query","{}");
        Result process = commonFacade.process(trans);
        log.info(process.toString());
    }



    private Request remoteRequest(String bizType,String operateType,String json) {
        return Request.builder()
                .bizType(bizType)
                .operateType(operateType)
                .paramJson(json)
                .requestTime(new Date())
                .systemId("TRANS")
                .traceId(UUID.randomUUID().toString())
                .build();
    }

複製程式碼
  • 介面引數Request

通訊方式 Hessian

序號 欄位 描述
1 CLEARING 組標識號
2 small.batch.pay 小額批付業務
3 clearing.bank.code.add 小額批付新增行名行號
4 requestTime 請求時間new Date()
5 traceId 鏈路ID
6 paramJson 業務引數(見引數明細)
  • 引數明細

格式Json型別
若資料量大，建議分批請求

序號 欄位 長度 是否可空 描述
1 bankCode Text(24) 是 參與機構行號
2 bankType Text(8) 是 參與機構類別
3 category Text (8) 是 行別程式碼
4 drctBankCode Text(16) 是 所屬直參行號
5 lglPrsn Text(32) 是 所屬法人
6 highOrg Text (128) 是 本行上級參與機構
7 ineffectiveDate TimeStamp 是 失效日期
8 createdBy Text (32) 否 建立人
9 updatedBy Text (32) 否 更新人
  • 出參
## Result<String> result = new Result();
## String 值為下行程式碼

JSON.toJSONString(Boolean.TRUE);

複製程式碼

相關文章