维护性差: 因需求与日俱增,接口的数量也变得繁多而不可控,接口调用关系复杂;可读性差,学习及维护成本大;
可控性差: 没法细粒度控制到方法,没法动态管理接口、方法(如权限校验、流控、降级容错、方法隔离)等;
适应性好:就是说想怎么写就怎么写,无拘无束,无需考虑太多;
复制代码
- Trans001001Facade
- Trans002001Facade
- Trans003001Facade
- Trans004001Facade
- Trans005001Facade
- Trans006001Facade
- 成百上千个Facade向你袭来 ........
复制代码
每当看到成千上万个这种接口时,老是感受菊花一紧一紧的;
这些接口里隐藏着让你深深蛋疼的x个未知方法;
对业务作修改和扩展时,是否有过一个类一个类翻注释看捋业务代码的经历?java
扩展性: 接口能够适应突如起来的业务变动,而不对外部产生任何影响;
维护性: 业务易读、易维护、可动态调整;编码者只需关注业务实现便可,快速迭代开发;
可控性: 控制权交给控制台,跟踪方法执行,动态调整方法(添加权限,报警,日志等),无需修改代码、上下线;
复制代码
控制台样例展现spring
因工做比较忙,工程处于开发阶段
详细设计因公暂不能公开json
设计思路bash
设计离不开场景,切记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类型 若数据量大,建议分批请求学习
序号 | 字段 | 长度 | 是否可空 | 描述 |
---|---|---|---|---|
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);
复制代码