关于java:Dubbo服务如何优雅的校验参数

28次阅读

共计 12137 个字符，预计需要花费 31 分钟才能阅读完成。

一、背景

服务端在向外提供接口服务时，不论是对前端提供 HTTP 接口，还是面向外部其余服务端提供的 RPC 接口，经常会面对这样一个问题，就是如何优雅的解决各种接口参数校验问题？

晚期大家在做面向前端提供的 HTTP 接口时，对参数的校验可能都会经验这几个阶段：每个接口每个参数都写定制校验代码、提炼公共校验逻辑、自定义切面进行校验、通用规范的校验逻辑。

这边提到的通用规范的校验逻辑指的就是基于 JSR303 的 Java Bean Validation，其中官网指定的具体实现就是 Hibernate Validator，在 Web 我的项目中联合 Spring 能够做到很优雅的去进行参数校验。

本文次要也是想给大家介绍下如何在应用 Dubbo 时做好优雅的参数校验。

二、解决方案

Dubbo 框架自身是反对参数校验的，同时也是基于 JSR303 去实现的，咱们来看下具体是怎么实现的。

2.1 maven 依赖

<!-- 定义在 facade 接口模块的 pom 文件找那个 -->
<dependency>
    <groupId>javax.validation</groupId>
    <artifactId>validation-api</artifactId>
    <version>2.0.1.Final</version>
<!-- 如果不想 facade 包有多余的依赖，此处 scope 设为 provided，否则能够删除 -->
    <scope>provided</scope>
</dependency>
 
<!-- 上面依赖通常加在 Facade 接口实现模块的 pom 文件中 -->
<dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>6.2.0.Final</version>
</dependency>

2.2 接口定义

facade 接口定义：

public interface UserFacade {FacadeResult<Boolean> updateUser(UpdateUserParam param);
}

参数定义

public class UpdateUserParam implements Serializable {
    private static final long serialVersionUID = 2476922055212727973L;
 
    @NotNull(message = "用户标识不能为空")
    private Long id;
    @NotBlank(message = "用户名不能为空")
    private String name;
    @NotBlank(message = "用户手机号不能为空")
    @Size(min = 8, max = 16, message="电话号码长度介于 8~16 位")
    private String phone;
 
    // getter and setter ignored
}

公共返回定义

/**
 * Facade 接口对立返回后果
 */
public class FacadeResult<T> implements Serializable {
    private static final long serialVersionUID = 8570359747128577687L;
 
    private int code;
    private T data;
    private String msg;
    // getter and setter ignored
}

2.3 Dubbo 服务提供者端配置

Dubbo 服务提供者端必须作这个 validation=”true” 的配置，具体示例配置如下：

Dubbo 接口服务端配置

<bean class="com.xxx.demo.UserFacadeImpl" id="userFacade"/>
<dubbo:service interface="com.xxx.demo.UserFacade" ref="userFacade" validation="true" />

2.4 Dubbo 服务消费者端配置

这个依据业务方应用习惯不作强制要求，但倡议配置上都加上 validation=”true”，示例配置如下：

<dubbo:reference id="userFacade" interface="com.xxx.demo.UserFacade" validation="true" />

2.5 验证参数校验

后面几步实现当前，验证这一步就比较简单了，消费者调用该约定接口，接口入参传入 UpdateUserParam 对象，其中字段不必赋值，而后调用服务端接口就会失去如下的参数异样提醒：

Dubbo 接口服务端配置

javax.validation.ValidationException: Failed to validate service: com.xxx.demo.UserFacade, method: updateUser, cause: [ConstraintViolationImpl{interpolatedMessage='用户名不能为空', propertyPath=name, rootBeanClass=class com.xxx.demo.UpdateUserParam, messageTemplate='用户名不能为空'}, ConstraintViolationImpl{interpolatedMessage='用户手机号不能为空', propertyPath=phone, rootBeanClass=class com.xxx.demo.UpdateUserParam, messageTemplate='用户手机号不能为空'}, ConstraintViolationImpl{interpolatedMessage='用户标识不能为空', propertyPath=id, rootBeanClass=class com.xxx.demo.UpdateUserParam, messageTemplate='用户标识不能为空'}]
javax.validation.ValidationException: Failed to validate service: com.xxx.demo.UserFacade, method: updateUser, cause: [ConstraintViolationImpl{interpolatedMessage='用户名不能为空', propertyPath=name, rootBeanClass=class com.xxx.demo.UpdateUserParam, messageTemplate='用户名不能为空'}, ConstraintViolationImpl{interpolatedMessage='用户手机号不能为空', propertyPath=phone, rootBeanClass=class com.xxx.demo.UpdateUserParam, messageTemplate='用户手机号不能为空'}, ConstraintViolationImpl{interpolatedMessage='用户标识不能为空', propertyPath=id, rootBeanClass=class com.xxx.demo.UpdateUserParam, messageTemplate='用户标识不能为空'}]
    at org.apache.dubbo.validation.filter.ValidationFilter.invoke(ValidationFilter.java:96)
    at org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:83)
    ....
    at org.apache.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received(HeaderExchangeHandler.java:175)
    at org.apache.dubbo.remoting.transport.DecodeHandler.received(DecodeHandler.java:51)
    at org.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java:57)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

三、定制 Dubbo 参数校验异样返回

从后面内容咱们能够很轻松的验证，当生产端调用 Dubbo 服务时，参数如果不非法就会抛出相干异样信息，生产端调用时也能辨认出异样信息，仿佛这样就没有问题了。

但从后面所定义的服务接口来看，个别业务开发会定义对立的返回对象格局（如前文示例中的 FacadeResult），对于业务异常情况，会约定相干异样码并联合相关性信息提醒。因而对于参数校验不非法的状况，服务调用方天然不心愿服务端抛出一大段蕴含堆栈信息的异样信息，而是心愿还放弃这种对立的返回模式，就如上面这种返回所示：

Dubbo 接口服务端配置：

{ 
  "code": 1001,
  "msg": "用户名不能为空",
  "data": null
}

3.1 ValidationFilter & JValidator

想要做到返回格局的对立，咱们先来看下后面所抛出的异样是如何来的？

从异样堆栈内容咱们能够看出这个异样信息返回是由 ValidationFilter 抛出的，从名字咱们能够猜到这个是采纳 Dubbo 的 Filter 扩大机制的一个内置实现，当咱们对 Dubbo 服务接口启用参数校验时（即前文 Dubbo 服务配置中的 validation=”true”)，该 Filter 就会真正起作用，咱们来看下其中的要害实现逻辑：

@Override
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {if (validation != null && !invocation.getMethodName().startsWith("$")
            && ConfigUtils.isNotEmpty(invoker.getUrl().getMethodParameter(invocation.getMethodName(), VALIDATION_KEY))) {
        try {Validator validator = validation.getValidator(invoker.getUrl());
            if (validator != null) {
                // 注 1
                validator.validate(invocation.getMethodName(), invocation.getParameterTypes(), invocation.getArguments());
            }
        } catch (RpcException e) {throw e;} catch (ValidationException e) {
            // 注 2
            return AsyncRpcResult.newDefaultAsyncResult(new ValidationException(e.getMessage()), invocation);
        } catch (Throwable t) {return AsyncRpcResult.newDefaultAsyncResult(t, invocation);
        }
    }
    return invoker.invoke(invocation);
}

从前文的异样堆栈信息咱们能够晓得异样信息是由上述代码「注 2」处所产生，这边是因为捕捉了 ValidationException，通过走读代码或者调试能够得悉，该异样是由「注 1」处 valiator.validate 办法所产生。

而 Validator 接口在 Dubbo 框架中实现只有 JValidator，这个通过 idea 工具显示 Validator 所有实现的 UML 类图能够看出（如下图所示），当然调试代码也能够很轻松定位到。

既然定位到 JValidator 了，咱们就持续看下它外面 validate 办法的具体实现，要害代码如下所示：

@Override
public void validate(String methodName, Class<?>[] parameterTypes, Object[] arguments) throws Exception {List<Class<?>> groups = new ArrayList<>();
    Class<?> methodClass = methodClass(methodName);
    if (methodClass != null) {groups.add(methodClass);
    }
    Set<ConstraintViolation<?>> violations = new HashSet<>();
    Method method = clazz.getMethod(methodName, parameterTypes);
    Class<?>[] methodClasses;
    if (method.isAnnotationPresent(MethodValidated.class)){methodClasses = method.getAnnotation(MethodValidated.class).value();
        groups.addAll(Arrays.asList(methodClasses));
    }
    groups.add(0, Default.class);
    groups.add(1, clazz);
 
    Class<?>[] classgroups = groups.toArray(new Class[groups.size()]);
 
    Object parameterBean = getMethodParameterBean(clazz, method, arguments);
    if (parameterBean != null) {
        // 注 1
        violations.addAll(validator.validate(parameterBean, classgroups));
    }
 
    for (Object arg : arguments) {
        // 注 2
        validate(violations, arg, classgroups);
    }
 
    if (!violations.isEmpty()) {
        // 注 3
        logger.error("Failed to validate service:" + clazz.getName() + ", method:" + methodName + ", cause:" + violations);
        throw new ConstraintViolationException("Failed to validate service:" + clazz.getName() + ", method:" + methodName + ", cause:" + violations, violations);
    }
}

从上述代码中能够看出当「注 1」和注「2」两处代码进行参数校验时所失去的「违反束缚」的信息都被退出到 violations 汇合中，而在「注 3」处查看到「违反束缚」不为空时，就会抛出蕴含「违反束缚」信息的 ConstraintViolationException，该异样继承自 ValidationException，这样也就会被 ValidationFilter 中办法所捕捉，进而向调用方返回相干异样信息。

3.2 自定义参数校验异样返回

从前一大节咱们能够很清晰的理解到了为什么会抛出那样的异样信息给调用方，如果想做到咱们后面想要的诉求：对立返回格局，咱们须要依照上面的步骤去实现。

3.2.1 自定义 Filter

@Activate(group = {CONSUMER, PROVIDER}, value = "customValidationFilter", order = 10000)
public class CustomValidationFilter implements Filter {
 
    private Validation validation;
 
    public void setValidation(Validation validation) {this.validation = validation;}
 
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {if (validation != null && !invocation.getMethodName().startsWith("$")
                && ConfigUtils.isNotEmpty(invoker.getUrl().getMethodParameter(invocation.getMethodName(), VALIDATION_KEY))) {
            try {Validator validator = validation.getValidator(invoker.getUrl());
                if (validator != null) {validator.validate(invocation.getMethodName(), invocation.getParameterTypes(), invocation.getArguments());
                }
            } catch (RpcException e) {throw e;} catch (ConstraintViolationException e) {// 这边细化了异样类型
                // 注 1
                Set<ConstraintViolation<?>> violations = e.getConstraintViolations();
                if (CollectionUtils.isNotEmpty(violations)) {ConstraintViolation<?> violation = violations.iterator().next();// 取第一个进行提醒就行了
                    FacadeResult facadeResult = FacadeResult.fail(ErrorCode.INVALID_PARAM.getCode(), violation.getMessage());
                    return AsyncRpcResult.newDefaultAsyncResult(facadeResult, invocation);
                }
                return AsyncRpcResult.newDefaultAsyncResult(new ValidationException(e.getMessage()), invocation);
            } catch (Throwable t) {return AsyncRpcResult.newDefaultAsyncResult(t, invocation);
            }
        }
        return invoker.invoke(invocation);
    }
}

该自定义 filter 与内置的 ValidationFilter 惟一不同的中央就在于「注 1」处所新增的针对特定异样 ConstraintViolationException 的解决，从异样对象中获取蕴含的「违反束缚」信息，并取其中第一个来结构业务上所定义的通用数据格式 FacadeResult 对象，作为 Dubbo 服务接口调用返回的信息。

3.2.2 自定义 Filter 的配置

开发过 Dubbo 自定义 filter 的同学都晓得，要让它失效须要作一个合乎 SPI 标准的配置，如下所示：

a. 新建两级目录别离是 META-INF 和 dubbo，这个须要特地留神，不能间接新建一个目录名为「META-INFO.dubbo」，否则在初始化启动的时候会失败。

b. 新建一个文件名为 com.alibaba.dubbo.rpc.Filter，当然也能够是 org.apache.dubbo.rpc.Filter，Dubbo 开源到 Apache 社区后，默认反对这两个名字。

c. 文件中配置内容为：customValidationFilter=com.xxx.demo.dubbo.filter.CustomValidationFilter。

3.3.3 Dubbo 服务配置

有了自定义参数校验的 Filter 配置后，如果只做到这的话，其实还有一个问题，利用启动后会有两个参数校验 Filter 失效。当然能够通过指定 Filter 的 order 来实现自定义 Filter 先执行，但很显然这种形式不稳当，而且两个 Filter 的性能是反复的，因而只须要一个失效就能够了，Dubbo 提供了一种机制能够禁用指定的 Filter，只需在 Dubbo 配置文件中作如下配置即可：

<!-- 须要禁用的 filter 以 "-" 结尾并加上 filter 名称 -->
<!-- 查看源码，可看到须要禁用的 ValidationFilter 名为 validation-->
<dubbo:provider filter="-validation"/>

但通过上述配置后，发现 customValidationFilter 并没有失效，通过调试以及对 dubbo 相干文档的学习，对 Filter 失效机制有了肯定的理解。

a. dubbo 启动后，默认会失效框架自带的一系列 Filter；

能够在 dubbo 框架的资源文件 org.apache.dubbo.rpc.Filter 中看到具体有哪些，不同版本的内容可能会有些许差异。

cache=org.apache.dubbo.cache.filter.CacheFilter
validation=org.apache.dubbo.validation.filter.ValidationFilter  // 注 1
echo=org.apache.dubbo.rpc.filter.EchoFilter
generic=org.apache.dubbo.rpc.filter.GenericFilter
genericimpl=org.apache.dubbo.rpc.filter.GenericImplFilter
token=org.apache.dubbo.rpc.filter.TokenFilter
accesslog=org.apache.dubbo.rpc.filter.AccessLogFilter
activelimit=org.apache.dubbo.rpc.filter.ActiveLimitFilter
classloader=org.apache.dubbo.rpc.filter.ClassLoaderFilter
context=org.apache.dubbo.rpc.filter.ContextFilter
consumercontext=org.apache.dubbo.rpc.filter.ConsumerContextFilter
exception=org.apache.dubbo.rpc.filter.ExceptionFilter
executelimit=org.apache.dubbo.rpc.filter.ExecuteLimitFilter
deprecated=org.apache.dubbo.rpc.filter.DeprecatedFilter
compatible=org.apache.dubbo.rpc.filter.CompatibleFilter
timeout=org.apache.dubbo.rpc.filter.TimeoutFilter
tps=org.apache.dubbo.rpc.filter.TpsLimitFilter
trace=org.apache.dubbo.rpc.protocol.dubbo.filter.TraceFilter
future=org.apache.dubbo.rpc.protocol.dubbo.filter.FutureFilter
monitor=org.apache.dubbo.monitor.support.MonitorFilter
metrics=org.apache.dubbo.monitor.dubbo.MetricsFilter

如上「注 1」中的 Filter 就是咱们上一步配置中想要禁用的 Filter，因为这些 filter 都是 Dubbo 内置的，所以这些 filter 汇合有一个对立的名字，default，因而如果想全副禁用，除了一个一个禁用外，也能够间接用 ’-default’ 达到目标，这些默认内置的 filter 只有没有全副或独自禁用，那就会失效。

b. 想要开发的自定义 Filter 能失效，不并肯定要在 <dubbo:provider filter=”xxxFitler” > 中体现；如果咱们没有在 Dubbo 相干的配置文件中去配置 Filter 相干信息，只有写好自定义 filter 代码，并在资源文件 /META-INF/dubbo/com.alibaba.dubbo.rpc.Filter 中依照 spi 标准定义好即可，这样所有被加载的 Filter 都会失效。

c. 如果在 Dubbo 配置文件中配置了 Filter 信息，那自定义 Filter 只有显式配置才会失效。

d. Filter 配置也能够加在 dubbo service 配置中（<dubbo:service interface=”…” ref=”…” validation=”true” filter=”xFilter,yFilter”/>）。

当 dubbo 配置文件中 provider 和 service 局部都配置了 Filter 信息，针对 service 具体失效的 Filter 取两者配置的并集。

因而想要自定义的校验 Filter 在所有服务中都失效，须要作如下配置：

<dubbo:provider filter="-validation, customValidationFilter"/>

四、如何扩大校验注解

后面示例中都是利用参数校验的内置注解去实现，在理论开发中有时候会遇到默认内置的注解无奈满足校验需要，这时就须要自定义一些校验注解去满足需要，不便开发。

假如有这样一个场景，某参数值须要校验只能在指定的几个数值范畴内，相似于白名单一样，上面就以这个场景来演示下如何扩大校验注解。

4.1 定义校验注解

@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER})
@Retention(RUNTIME)
@Documented
@Constraint(validatedBy = {})// 注 1
// @Constraint(validatedBy = {AllowedValueValidator.class}) 注 2
public @interface AllowedValue {String message() default "参数值不在非法范畴内";
 
    Class<?>[] groups() default { };
 
    Class<? extends Payload>[] payload() default { };
 
    long[] value() default {};}


public class AllowedValueValidator implements ConstraintValidator<AllowedValue, Long> {private long[] allowedValues;
 
    @Override
    public void initialize(AllowedValue constraintAnnotation) {this.allowedValues = constraintAnnotation.value();
    }
 
    @Override
    public boolean isValid(Long value, ConstraintValidatorContext context) {if (allowedValues.length == 0) {return true;}
        return Arrays.stream(allowedValues).anyMatch(o -> Objects.equals(o, value));
    }
}

「注 1」中的校验器 (Validator) 并没有指定，当然是能够像「注 2」中那样间接指定校验器，但思考到自定义注解有可能是间接裸露在 facade 包中，而具体的校验器的实现有时候会蕴含一些业务依赖，所以不倡议间接在此处指定，而是通过 Hibernate Validator 提供的 Validator 发现机制去实现关联。

4.2 配置定制 Validator 发现

a. 在 resources 目录下新建 META-INF/services/javax.validation.ConstraintValidator 文件。

b. 文件中只需填入相应 Validator 的全门路：com.xxx.demo.validator.AllowedValueValidator，如果有多个的话，每行一个。

五、总结

本文次要介绍了应用 Dubbo 框架时如何应用优雅点形式实现参数的校验，首先演示了如何利用 Dubbo 框架默认反对的校验实现，而后接着演示了如何配合理论业务开发返回对立的数据格式，最初介绍了下如何进行自定义校验注解的实现，不便进行后续自行扩大实现，心愿能在理论工作中有肯定的帮忙。

作者：vivo 官网商城开发团队 -Wei Fuping

正文完
java
发表至： java
2022-03-08
 0
SpringBoot原理深入及源码剖析
关于java:最近踩的雷你中招了吗spring-boot-ftp-生成二维码上传附件以及回显
关于java:面试官常问的垃圾回收器这次全搞懂
一起来读Spring源码吧（三）ApplicationContext初始化过程