从本地到云端：跨用户请求问题的完美解决方案

对于某些单个请求或响应中含有多个用户信息的服务，SDK提供了一套基于统一的UCS拆分和聚合的解决方案供开发者使用。

请求拆分

对于跨用户服务的请求，我们提供了两个处理方案：
【1】根据用户信息拆分请求： 场景：请求内含有对应多个用户的对象列表。例如批量查询，批量匹配订单进行批量操作。

Map<SwitchTag, R> split(R originalRequest,  //  原始的请求RequestType。
                        String splitItemCollectionFieldName,  // 请求内含有多个用户信息的对象集合，由于契约限制必须为List类型。
                        Function<T, K> splitKeyGetter,  // 获取上述多用户对象集合内用来分割请求的key，支持的类型参照上文MappingFieldType的类型。
                        MappingFieldType keyType) throws RequestSplitException;   // 分割请求的key对应的类型

示例用法：以特殊事件强绑接口为例，EditForceMatchedOrderRequest中，forceMatchedOrderList内可能会包含多个不同用户的订单，且对象内含有订单号的信息，可以用来匹配用户的uid。代码如下：

MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
EditForceMatchedOrderRequest request = new EditForceMatchedOrderRequest();
​
try {
    Map<SwitchTag, EditForceMatchedOrderRequest> splitRequests =
    splitter.split(request,
                   "forceMatchedOrderList",
                   ForceMatchedOrder::getOrderId,
                   MappingFieldType.FLIGHT_ORDER_ID);
   
} catch (RequestSplitException e) {
    // exception process
}

【2】广播请求至所有Region： 场景：请求中不含有用户信息，但是返回结果会存在多个用户的数据。例如最终行程匹单，利用规则ID查询所有匹配特殊事件规则的订单。

Map<SwitchTag, R> broadcast(R originalRequest) throws RequestSplitException;

用户只需要提供原始的请求，该方法就会将该请求复制多份到每个region。

以查询强绑订单为例，QueryForceMatchedOrderRequest中，可以只传入configId，匹配所有符合该id的订单。代码如下：

MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
QueryForceMatchedOrderRequest request = new QueryForceMatchedOrderRequest();
​
try {
    Map<SwitchTag, QueryForceMatchedOrderRequest> splitRequests = splitter.split(request);
} catch (RequestSplitException e) {
    // exception process
}

请求执行

SDK中提供了标准的api可以让开发者方便的执行被拆分出来的请求。API列表如下：

List<RequestExecutionContext<R,P>> execRequests(Map<SwitchTag, R> requestMap,
                                                Class<P> responseClz,
                                                C serviceClient,
                                                String operationName) throws RequestExecutionException;
​
RequestExecutionContext<R,P> execRequest(SwitchTag switchTag,
                                         R request,
                                         Class<P> responseClz,
                                         C serviceClient,
                                         String operationName) throws RequestExecutionException;

大部分情况下，开发者只需调用execRequests方法，传入上述拆分功能返回的请求列表，以及调用客户端相关信息即可。当且仅当开发者对调用顺序有严格要求，或需要对每次请求单独做自定义异常处理，可以调用execRequest进行单个请求逐个执行。

以特殊事件强绑接口为例，使用请求拆分功能后紧接着实际发送请求的示例代码为：

MultiUserRequestExecutor executor = MultiUserRequestExecutorImpl.getInstance();
​
List<RequestExecutionContext<EditForceMatchedOrderRequest, EditForceMatchedOrderResponse>> execResults =
                executor.execRequests(
                        // 拆分后的请求列表
                        splitRequests,
                        // 请求的响应契约类型
                        EditForceMatchedOrderResponse.class,
                        // 请求的客户端实例
                        FlightchangeSpecialeventServiceClient.getInstance(),
                        // 请求的对应操作名
                        "editForceMatchedOrder");

返回值中的RequestExecutionContext对象包括了请求，响应，SwitchTag以及该次请求的异常信息，一般来说无需关心。

请求聚合

SDK中提供了一些标准的api来对拆分后不同用户的多个请求的一系列响应做聚合，最终返回客户端的只有一个响应对象，使得业务代码中除了调用部分之外的代码可以保持一致。

响应聚合的方式主要包括以下三类：根据UCS策略聚合

P aggregateByUCS(List<RequestExecutionContext<R,P>> responseContext,
                 // 可以不传，则默认有响应都是成功，不进行过滤
                 Predicate<P> failedRespPredictor,
                 String itemCollectionFieldName,
                 Function<T, K> splitKeyGetter,
                 MappingFieldType keyType) throws Exception;

场景：广播请求后返回了多个区域的多个用户的请求，需要筛选出Region中灰度范围内用户的数据，保证数据新鲜度。

其中，responseContext为上述请求执行后返回的包装结果，failedRespPredictor为判断单个响应是否成功的函数，其余参数和请求拆分中的定义保持一致（用户信息对象为响应中的对象）。

注意：返回的响应集合中，如果有一个响应经过failedRespPredictor判断为失败，则默认情况下，会认为整个请求失败，返回该失败的响应。该行为可以通过配置ignoreFailureAndExceptions改变，后续配置项介绍会详细说明。

示例代码：以用规则ID查询所有匹配的强绑规则订单为例，该场景下请求内仅含有需要查询的规则ID无用户信息，所以被广播到了SHA和SIN两个Region同时进行查询。现在需要对查询结果做聚合：

MultiUserResponseAggregator aggregator = MultiUserResponseAggregatorImpl.getInstance();
QueryForceMatchedOrderResponse aggregated = aggregator.aggregateByUCS(execResults,
        response -> response.getResponseStatus().getAck() != AckCodeType.Success,
        "forceMatchedOrderList",
        ForceMatchedOrder::getOrderId,
        MappingFieldType.FLIGHT_ORDER_ID);
// handle response as used to be

聚合全量不同的结果

P aggregateAllDistinct(List<RequestExecutionContext<R,P>> responseContext,
                       String itemCollectionFieldName,
                       // 判断两个含有用户信息的对象是否属于同一个业务记录的函数，默认为Object.equals
                       BiPredicate<T, T> itemEqualPredictor,
                       // 可以不传，则默认有响应都是成功，不进行过滤
                       Predicate<P> failedRespPredictor) throws Exception;

场景：批量操作请求按照用户被拆分成多个后，需要获取所有响应进行展示，或数据完全隔离后单边进行查询。

示例场景：以特殊事件强绑接口为例，请求按照用户被拆分成多个请求后，返回的响应是操作失败的订单列表，此时只需要聚合所有失败的订单返回给客户端即可。示例代码如下：

MultiUserResponseAggregator aggregator = MultiUserResponseAggregatorImpl.getInstance();
EditForceMatchedOrderResponse response = aggregator.aggregateAllDistinct(
        execResults,
        "updateFailedList",
        // 返回的itemCollection为Long，直接使用默认的Object.equals比较即可
        null,
        // 无特别的响应状态码，默认即可
        null);

返回任意结果（任意成功/任意失败/失败优先）

// 任意成功
P getAnySuccessResponse(List<RequestExecutionContext<R,P>> responseContext, Predicate<P> successRespPredictor);
​
// 失败优先
<R extends SpecificRecord, P extends SpecificRecord>
P getAnyResponseWithFailFast(List<RequestExecutionContext<R,P>> responseContext,
                             Predicate<P> failedRespPredictor) throws Exception;
​
// 所有失败
<R extends SpecificRecord, P extends SpecificRecord>
List<RequestExecutionContext<R,P>> getAllFailedResponseContext(
        List<RequestExecutionContext<R,P>> responseContext, Predicate<P> failedRespPredictor);

场景：批量操作请求按照用户被拆分成多个后，响应中不含有用户信息，仅存在成功/失败/状态码的字段

典型场景示例代码：综合以上的用法，我们针对典型的场景给出两套标准的示例代码：
【1】批量编辑强绑订单，请求中含有多个待编辑的订单信息，响应为编辑失败的订单号集合

private EditForceMatchedOrderResponse editForceMatchedOrder(EditForceMatchedOrderRequest request) {
​
    MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
    MultiUserRequestExecutor executor = MultiUserRequestExecutorImpl.getInstance();
    MultiUserResponseAggregator aggregator = MultiUserResponseAggregatorImpl.getInstance();
​
    try {
        Map<SwitchTag, EditForceMatchedOrderRequest> splitRequests =splitter.split(
          request,
          "forceMatchedOrderList",
          ForceMatchedOrder::getOrderId,
          MappingFieldType.FLIGHT_ORDER_ID);
​
        List<RequestExecutionContext<EditForceMatchedOrderRequest, EditForceMatchedOrderResponse>> execResults = executor.execRequests(
          splitRequests,
          EditForceMatchedOrderResponse.class,
          FlightchangeSpecialeventServiceClient.getInstance(),
          "editForceMatchedOrder");
​
        return aggregator.aggregateAllDistinct(execResults, "updateFailedList", null, null);
    } catch (Exception e) {
        // exception process
    }
}

【2】根据强绑规则ID查询所有匹配的订单信息，请求中只含有规则ID，响应为所有匹配的订单信息的集合

private QueryForceMatchedOrderResponse queryForceMatchedOrder(QueryForceMatchedOrderRequest request) {
    MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
    MultiUserRequestExecutor executor = MultiUserRequestExecutorImpl.getInstance();
    MultiUserResponseAggregator aggregator = MultiUserResponseAggregatorImpl.getInstance();
​
    try {
        Map<SwitchTag, QueryForceMatchedOrderRequest> splitRequests = splitter.broadcast(request);
​
        List<RequestExecutionContext<QueryForceMatchedOrderRequest, QueryForceMatchedOrderResponse>> execResults = executor.execRequests(
          splitRequests,
          QueryForceMatchedOrderResponse.class,
          FlightchangeSpecialeventServiceClient.getInstance(),
          "queryForceMatchedOrder");
​
        return aggregator.aggregateByUCS(execResults,
                                         "forceMatchedOrderList",
                                         ForceMatchedOrder::getOrderId,
                                         MappingFieldType.FLIGHT_ORDER_ID);
    } catch (Exception e) {
        // exception process
    }
}

配置项列表

为了启用SDK中的多用户请求处理功能，开发者必须在客户端的QConfig上新建名为requestprocessorconfig.json的配置文件, 并按照目标操作的维度配置必要的信息。示例的配置文件如下：

[
    {
        "requestTypeFullName" : "com.huwei.soa.flight.flightchange.specialevent.v1.EditForceMatchedOrderRequest", // 要调用的操作的请求契约全类名
        "targetServiceCode" : "24249",  // 要调用的服务对应的serviceCode，用于关联UCS策略以及路由规则
        "splitterSettings" : {
            "enableRequestSplit" : true,  // 是否打开请求拆分功能，默认不打开，即原样转发请求
            "splitMode" : "BY_UID",  // 拆分的模式
            "interruptOnUDLError" : false, // 查询UDL信息出现异常如超时时，是否直接中断当前请求。默认或设置为false时，查询UDL出错，请求会继续被执行，但是不会带上UDL信息，所以都会被路由到SHA。设置为true时，查询UDL出错，方法直接抛错中断执行
            "allowNullSplitKey": false // 默认情况下，split key为空的时候走SHA。设置为true后，split key为空的时候，该key会拆分为广播的请求。场景为某些特殊的批量查询下，查询的key即可能是订单号也有可能是规则ID。
        },
        "executorSettings" : {
            "enableConcurrentExecute" : false, // 是否启用并发请求。当拆分后的用户数量很多，或客户端对响应时间比较敏感的情况下，该选项设置为true可以开启并发执行。默认为不开启。
            "concurrentExecThreshold" : 10,  // 并发执行的请求个数阈值。默认为0。当并发请求开启后，可以通过设置该值，来达到仅当拆分后请求数量大于该阈值才并发执行的效果。
            "maxConcurrentThreads" : 16, // 最大并发线程数，仅对当前操作生效。
            "interruptOnRemoteCallError" : false, // 是否在远程调用发生异常时立即中断。默认为不中断。
            "execTimeoutMillis" : 3000, // 并发执行时，总体的超时时间（单位ms）。默认为10秒。
            "requestFormat" : "json" // 调用服务端时的请求格式，针对服务端只接受特定的格式的场景。默认即跟随baiji框架设置。
        },
        "aggregatorSettings" : {
            "ignoreFailureAndExceptions" : false, // 是否在聚合时忽略异常和失败的请求，默认为不忽略。设置为true时，异常或失败的请求会被跳过，系统只会聚合合法的响应并返回客户端。
            "dataInconsistentErrorLogLevel" : "INFO", // 当Region之间数据不一致时，log信息的级别。可选有INFO, ERROR, DISABLE
            "disableUCSFiltering" : false // 在数据完全隔离后，跳过UCS过滤的步骤，直接聚合全量数据。
        }
    },
  ...
]

splitMode：拆分的模式
【1】BY_UID：默认的每个用户拆分一个请求，适用于绝大部分情况；
【2】BY_UDL：（使用前请联系上云组评估）仅当单个批量请求的用户可能非常多导致性能问题时使用；
【3】BROADCAST： 广播模式，同一个请求复制到所有Region；