維護性差: 因需求與日俱增,接口的數量也變得繁多而不可控,接口調用關係複雜;可讀性差,學習及維護成本大; 可控性差: 沒法細粒度控制到方法,沒法動態管理接口、方法(如權限校驗、流控、降級容錯、方法隔離)等; 適應性好:就是說想怎麼寫就怎麼寫,無拘無束,無需考慮太多;
- Trans001001Facade - Trans002001Facade - Trans003001Facade - Trans004001Facade - Trans005001Facade - Trans006001Facade - 成百上千個Facade向你襲來 ........
每當看到成千上萬個這種接口時,老是感受菊花一緊一緊的;
這些接口裏隱藏着讓你深深蛋疼的x個未知方法;
對業務作修改和擴展時,是否有過一個類一個類翻註釋看捋業務代碼的經歷?java
擴展性: 接口能夠適應突如起來的業務變動,而不對外部產生任何影響; 維護性: 業務易讀、易維護、可動態調整;編碼者只需關注業務實現便可,快速迭代開發; 可控性: 控制權交給控制檯,跟蹤方法執行,動態調整方法(添加權限,報警,日誌等),無需修改代碼、上下線;
控制檯樣例展現spring
因工做比較忙,工程處於開發階段
詳細設計因公暫不能公開json
設計思路dom
設計離不開場景,切記分佈式
@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(); }
通訊方式 Hessian學習
序號 | 字段 | 描述 |
---|---|---|
1 | CLEARING | 組標識號 |
2 | small.batch.pay | 小額批付業務 |
3 | clearing.bank.code.add | 小額批付新增行名行號 |
4 | requestTime | 請求時間new Date() |
5 | traceId | 鏈路ID |
6 | paramJson | 業務參數(見參數明細) |
格式Json類型
若數據量大,建議分批請求ui
序號 | 字段 | 長度 | 是否可空 | 描述 |
---|---|---|---|---|
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);