做旅游景点网站的目的和意义,南阳网站营销外包公司,如何用表格做网站,世界建设企业网站对于某些单个请求或响应中含有多个用户信息的服务#xff0c;SDK提供了一套基于统一的UCS拆分和聚合的解决方案供开发者使用。
请求拆分
对于跨用户服务的请求#xff0c;我们提供了两个处理方案#xff1a; 【1】根据用户信息拆分请求#xff1a; 场景#xff1a;请求内…对于某些单个请求或响应中含有多个用户信息的服务SDK提供了一套基于统一的UCS拆分和聚合的解决方案供开发者使用。
请求拆分
对于跨用户服务的请求我们提供了两个处理方案 【1】根据用户信息拆分请求 场景请求内含有对应多个用户的对象列表。例如批量查询批量匹配订单进行批量操作。
MapSwitchTag, R split(R originalRequest, // 原始的请求RequestType。String splitItemCollectionFieldName, // 请求内含有多个用户信息的对象集合由于契约限制必须为List类型。FunctionT, K splitKeyGetter, // 获取上述多用户对象集合内用来分割请求的key支持的类型参照上文MappingFieldType的类型。MappingFieldType keyType) throws RequestSplitException; // 分割请求的key对应的类型示例用法以特殊事件强绑接口为例EditForceMatchedOrderRequest中forceMatchedOrderList内可能会包含多个不同用户的订单且对象内含有订单号的信息可以用来匹配用户的uid。代码如下 MultiUserRequestSplitter splitter MultiUserRequestSplitterImpl.getInstance();
EditForceMatchedOrderRequest request new EditForceMatchedOrderRequest();
try {MapSwitchTag, EditForceMatchedOrderRequest splitRequests splitter.split(request,forceMatchedOrderList,ForceMatchedOrder::getOrderId,MappingFieldType.FLIGHT_ORDER_ID);} catch (RequestSplitException e) {// exception process
}【2】广播请求至所有Region 场景请求中不含有用户信息但是返回结果会存在多个用户的数据。例如最终行程匹单利用规则ID查询所有匹配特殊事件规则的订单。
MapSwitchTag, R broadcast(R originalRequest) throws RequestSplitException;用户只需要提供原始的请求该方法就会将该请求复制多份到每个region。
以查询强绑订单为例QueryForceMatchedOrderRequest中可以只传入configId匹配所有符合该id的订单。代码如下
MultiUserRequestSplitter splitter MultiUserRequestSplitterImpl.getInstance();
QueryForceMatchedOrderRequest request new QueryForceMatchedOrderRequest();
try {MapSwitchTag, QueryForceMatchedOrderRequest splitRequests splitter.split(request);
} catch (RequestSplitException e) {// exception process
}请求执行
SDK中提供了标准的api可以让开发者方便的执行被拆分出来的请求。API列表如下
ListRequestExecutionContextR,P execRequests(MapSwitchTag, R requestMap,ClassP responseClz,C serviceClient,String operationName) throws RequestExecutionException;
RequestExecutionContextR,P execRequest(SwitchTag switchTag,R request,ClassP responseClz,C serviceClient,String operationName) throws RequestExecutionException;大部分情况下开发者只需调用execRequests方法传入上述拆分功能返回的请求列表以及调用客户端相关信息即可。当且仅当开发者对调用顺序有严格要求或需要对每次请求单独做自定义异常处理可以调用execRequest进行单个请求逐个执行。
以特殊事件强绑接口为例使用请求拆分功能后紧接着实际发送请求的示例代码为
MultiUserRequestExecutor executor MultiUserRequestExecutorImpl.getInstance();
ListRequestExecutionContextEditForceMatchedOrderRequest, EditForceMatchedOrderResponse execResults executor.execRequests(// 拆分后的请求列表splitRequests,// 请求的响应契约类型EditForceMatchedOrderResponse.class,// 请求的客户端实例FlightchangeSpecialeventServiceClient.getInstance(),// 请求的对应操作名editForceMatchedOrder);返回值中的RequestExecutionContext对象包括了请求响应SwitchTag以及该次请求的异常信息一般来说无需关心。
请求聚合
SDK中提供了一些标准的api来对拆分后不同用户的多个请求的一系列响应做聚合最终返回客户端的只有一个响应对象使得业务代码中除了调用部分之外的代码可以保持一致。
响应聚合的方式主要包括以下三类根据UCS策略聚合
P aggregateByUCS(ListRequestExecutionContextR,P responseContext,// 可以不传则默认有响应都是成功不进行过滤PredicateP failedRespPredictor,String itemCollectionFieldName,FunctionT, 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(ListRequestExecutionContextR,P responseContext,String itemCollectionFieldName,// 判断两个含有用户信息的对象是否属于同一个业务记录的函数默认为Object.equalsBiPredicateT, T itemEqualPredictor,// 可以不传则默认有响应都是成功不进行过滤PredicateP failedRespPredictor) throws Exception;场景批量操作请求按照用户被拆分成多个后需要获取所有响应进行展示或数据完全隔离后单边进行查询。
示例场景以特殊事件强绑接口为例请求按照用户被拆分成多个请求后返回的响应是操作失败的订单列表此时只需要聚合所有失败的订单返回给客户端即可。示例代码如下
MultiUserResponseAggregator aggregator MultiUserResponseAggregatorImpl.getInstance();
EditForceMatchedOrderResponse response aggregator.aggregateAllDistinct(execResults,updateFailedList,// 返回的itemCollection为Long直接使用默认的Object.equals比较即可null,// 无特别的响应状态码默认即可null);返回任意结果任意成功/任意失败/失败优先
// 任意成功
P getAnySuccessResponse(ListRequestExecutionContextR,P responseContext, PredicateP successRespPredictor);
// 失败优先
R extends SpecificRecord, P extends SpecificRecord
P getAnyResponseWithFailFast(ListRequestExecutionContextR,P responseContext,PredicateP failedRespPredictor) throws Exception;
// 所有失败
R extends SpecificRecord, P extends SpecificRecord
ListRequestExecutionContextR,P getAllFailedResponseContext(ListRequestExecutionContextR,P responseContext, PredicateP failedRespPredictor);场景批量操作请求按照用户被拆分成多个后响应中不含有用户信息仅存在成功/失败/状态码的字段
典型场景示例代码综合以上的用法我们针对典型的场景给出两套标准的示例代码 【1】批量编辑强绑订单请求中含有多个待编辑的订单信息响应为编辑失败的订单号集合
private EditForceMatchedOrderResponse editForceMatchedOrder(EditForceMatchedOrderRequest request) {
MultiUserRequestSplitter splitter MultiUserRequestSplitterImpl.getInstance();MultiUserRequestExecutor executor MultiUserRequestExecutorImpl.getInstance();MultiUserResponseAggregator aggregator MultiUserResponseAggregatorImpl.getInstance();
try {MapSwitchTag, EditForceMatchedOrderRequest splitRequests splitter.split(request,forceMatchedOrderList,ForceMatchedOrder::getOrderId,MappingFieldType.FLIGHT_ORDER_ID);
ListRequestExecutionContextEditForceMatchedOrderRequest, 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 {MapSwitchTag, QueryForceMatchedOrderRequest splitRequests splitter.broadcast(request);
ListRequestExecutionContextQueryForceMatchedOrderRequest, 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, DISABLEdisableUCSFiltering : false // 在数据完全隔离后跳过UCS过滤的步骤直接聚合全量数据。}},...
]splitMode拆分的模式 【1】BY_UID默认的每个用户拆分一个请求适用于绝大部分情况 【2】BY_UDL使用前请联系上云组评估仅当单个批量请求的用户可能非常多导致性能问题时使用 【3】BROADCAST 广播模式同一个请求复制到所有Region
