趁热记录下,给未来的自己
0 | 需求阐明
事务场景:服务A对接了服务B,服务C等服务的一些接口,然后由服务A一致露出接口给到外部用户使用。
需求是:
- 服务A能够动态的接入服务B/C的接口,对外露出并无需重启(《OpenAPI开发 | 怎么动态的添加接口》)
- 对接的服务B/C的接口部分字段需求过滤掉,不透出给外部用户(如数据库的自增ID等敏感信息)。
1 | 思路计划
基本思路:在服务A里对各个服务接口回来的数据进行拦截并二次加工后再回来给前端。
-
拦截:比较简单,能够在服务A对其他服务接口恳求的回来之后进行事务操作,也能够一致放到切面里用 @After 注解进行操作。从 demo 的快速演示考虑,这儿挑选直接在恳求的回来体直接进行事务操作。
-
二次加工:服务A对回来body的部分字段过滤掉,不回来给前端。二次加工的方法有很多种,比如:
a. 用一个 map 去接纳 body,然后对这个 body map 进行遍历,和服务A里的 map 进行比较, 将服务A map 里需求的 key-value,从 body map 里遍历取出,put 到一个新的 map,最终回来这个新的 map 给前端。
b. 用 string 去接纳 body,接纳到的body是一个 json 字符串,然后将 json 字符串转成特定的目标(这个目标是回来给前端的),这样目标里没有界说的字段在 json 字符串转目标的过程中就会被舍弃。
计划a有几个缺陷:
- 首先,要求其他服务接口的回来有必要是一个 json 类型(可用 map 接纳),如果是一个 json数组([{},{}])的话, 就无法用map接纳,这样会导致对接入服务的接口数据结构有约束,不ok;
- 其次,map 数据类型可能会很杂乱,因为不确定 map 里的 value的数据结构是 string,list 还是 map 等,就需求用 instanceof 对一切的数据结构进行遍历判断再比较赋值,很杂乱,计算效率也不高。
- 没有可使用的轮子,类似将目标A赋值给目标B的属性复制(BeanUtils.copyProperties()),能够将mapA的 key-value 赋值给mapB
# mapA
{
"a": "a",
"b": "b",
"c": "c"
}
# mapB
{
"a": null,
"b": null,
}
相反,计划b有一个很大的优势:能够使用现成的序列化和反序列化东西(如Gson)来完成咱们的需求。先放一个反序列化的东西,后边会用到:
/**
* Json字符串转为指定的目标
* @param ret json字符串
* @param clazz 指定目标的类
* @return T 指定的目标
*/
public class JsonUtil {
public static <T> T jsonStr2Obj(String ret, Class<T> clazz) {
Gson gson = new Gson();
return gson.fromJson(ret, (Type) clazz);
}
}
可是提到这儿,解决的仅仅对接口回来body的修改,没有体现出标题的“动态”二字。那么怎么能够动态的对回来的body数据进行过滤处理呢?用 groovy 动态加载类。
2 | 具体实施
- 获取接口的回来(以string类型):
ResponseEntity<String> exchange = restTemplate.getForEntity($url, String.class);
String body = exchange.getBody();
- 经过groovy获取动态编译类
String clazzInString = getFromRedis($key) // 从redis获取字符串类型的java class
Object obj = DynamicClassCompilerUtil.run(clazzInString)
public class DynamicClassCompilerUtil {
public static Object run(String cls) {
Class<?> clazz = new GroovyClassLoader().parseClass(cls);
try {
return clazz.newInstance();
} catch (Exception e) {
log.error("parse groovy class failed: {}", e);
return null;
}
}
}
- 将 body 反序列化
Object ret = JsonUtil.jsonStr2Obj(body, obj.getClass())
该 ret 目标即为过滤后的目标,能够加工后回来给前端。
至此,“对接的服务B/C的接口部分字段需求过滤掉,不透出给外部用户(如数据库的自增ID等敏感信息)” 需求完成了。
至于 “服务A能够动态的接入服务B/C的接口,对外露出并无需重启” 需求,有时间的话,将会另起一篇来讲。
以上。
欢迎参加我的常识星球烂笔头