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

对于某些单个请求或响应中含有多个用户信息的服务，

SDK

提供了一套基于统一的

UCS

拆分和聚合的解决方案供开发者使用。

请求拆分

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

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

示例用法：以特殊事件强绑接口为例，

EditForceMatchedOrderRequest

中，

forceMatchedOrderList

内可能会包含多个不同用户的订单，且对象内含有订单号的信息，可以用来匹配用户的

uid

。代码如下：

MultiUserRequestSplitter splitter =MultiUserRequestSplitterImpl.getInstance();EditForceMatchedOrderRequest request =newEditForceMatchedOrderRequest();
​
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)throwsRequestSplitException;

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

region

。

以查询强绑订单为例，

QueryForceMatchedOrderRequest

中，可以只传入

configId

，匹配所有符合该

id

的订单。代码如下：

MultiUserRequestSplitter splitter =MultiUserRequestSplitterImpl.getInstance();QueryForceMatchedOrderRequest request =newQueryForceMatchedOrderRequest();
​
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)throwsRequestExecutionException;
​
RequestExecutionContext<R,P>execRequest(SwitchTag switchTag,R request,Class<P> responseClz,C serviceClient,String operationName)throwsRequestExecutionException;

大部分情况下，开发者只需调用

execRequests

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

execRequest

进行单个请求逐个执行。

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

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

返回值中的

RequestExecutionContext

对象包括了请求，响应，

SwitchTag

以及该次请求的异常信息，一般来说无需关心。

请求聚合

SDK

中提供了一些标准的

api

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

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

UCS

策略聚合

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

场景：广播请求后返回了多个区域的多个用户的请求，需要筛选出

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

聚合全量不同的结果

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

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

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

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

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

// 任意成功PgetAnySuccessResponse(List<RequestExecutionContext<R,P>> responseContext,Predicate<P> successRespPredictor);
​
// 失败优先<RextendsSpecificRecord,PextendsSpecificRecord>PgetAnyResponseWithFailFast(List<RequestExecutionContext<R,P>> responseContext,Predicate<P> failedRespPredictor)throwsException;
​
// 所有失败<RextendsSpecificRecord,PextendsSpecificRecord>List<RequestExecutionContext<R,P>>getAllFailedResponseContext(List<RequestExecutionContext<R,P>> responseContext,Predicate<P> failedRespPredictor);

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

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

privateEditForceMatchedOrderResponseeditForceMatchedOrder(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

，响应为所有匹配的订单信息的集合

privateQueryForceMatchedOrderResponsequeryForceMatchedOrder(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

；