从本地到云端：跨用户哀求问题的完美解决方案
对于某些单个哀求或响应中含有多个用户信息的服务，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；
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]