对于某些单个请求或响应中含有多个用户信息的服务，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；