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

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

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

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

复制代码

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

2. MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
3. EditForceMatchedOrderRequest request = new EditForceMatchedOrderRequest();
4. ​
5. try {
6.     Map<SwitchTag, EditForceMatchedOrderRequest> splitRequests =
7.     splitter.split(request,
8.                    "forceMatchedOrderList",
9.                    ForceMatchedOrder::getOrderId,
10.                    MappingFieldType.FLIGHT_ORDER_ID);
11.    
12. } catch (RequestSplitException e) {
13.     // exception process
14. }

复制代码

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

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

复制代码

用户只需要提供原始的哀求，该方法就会将该哀求复制多份到每个region。
以查询强绑订单为例，QueryForceMatchedOrderRequest中，可以只传入configId，匹配所有符合该id的订单。代码如下：

1. MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
2. QueryForceMatchedOrderRequest request = new QueryForceMatchedOrderRequest();
3. ​
4. try {
5.     Map<SwitchTag, QueryForceMatchedOrderRequest> splitRequests = splitter.split(request);
6. } catch (RequestSplitException e) {
7.     // exception process
8. }

复制代码

哀求执行

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

1. List<RequestExecutionContext<R,P>> execRequests(Map<SwitchTag, R> requestMap,
2.                                                 Class<P> responseClz,
3.                                                 C serviceClient,
4.                                                 String operationName) throws RequestExecutionException;
5. ​
6. RequestExecutionContext<R,P> execRequest(SwitchTag switchTag,
7.                                          R request,
8.                                          Class<P> responseClz,
9.                                          C serviceClient,
10.                                          String operationName) throws RequestExecutionException;

复制代码

大部门情况下，开发者只需调用execRequests方法，传入上述拆分功能返回的哀求列表，以及调用客户端相关信息即可。当且仅当开发者对调用次序有严格要求，或需要对每次哀求单独做自定义异常处置惩罚，可以调用execRequest举行单个哀求逐个执行。
以特殊事件强绑接口为例，使用哀求拆分功能后紧接着实际发送哀求的示例代码为：

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

复制代码

返回值中的RequestExecutionContext对象包罗了哀求，响应，SwitchTag以及该次哀求的异常信息，一样平常来说无需关心。
哀求聚合

SDK中提供了一些尺度的api来对拆分后差别用户的多个哀求的一系列响应做聚合，终极返回客户端的只有一个响应对象，使得业务代码中除了调用部门之外的代码可以保持一致。
响应聚合的方式主要包罗以下三类：根据UCS战略聚合

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

复制代码

场景：广播哀求后返回了多个地域的多个用户的哀求，需要筛选出Region中灰度范围内用户的数据，包管数据奇怪度。
此中，responseContext为上述哀求执行后返回的包装结果，failedRespPredictor为判定单个响应是否乐成的函数，其余参数和哀求拆分中的定义保持一致（用户信息对象为响应中的对象）。
注意：返回的响应集合中，假如有一个响应经过failedRespPredictor判定为失败，则默认情况下，会以为整个哀求失败，返回该失败的响应。该举动可以通过配置ignoreFailureAndExceptions改变，后续配置项介绍会具体说明。
示例代码：以用规则ID查询所有匹配的强绑规则订单为例，该场景下哀求内仅含有需要查询的规则ID无用户信息，所以被广播到了SHA和SIN两个Region同时举行查询。现在需要对查询结果做聚合：

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

复制代码

聚合全量差别的结果

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

复制代码

场景：批量操纵哀求按照用户被拆分成多个后，需要获取所有响应举行展示，或数据完全隔离后单边举行查询。
示例场景：以特殊事件强绑接口为例，哀求按照用户被拆分成多个哀求后，返回的响应是操纵失败的订单列表，此时只需要聚合所有失败的订单返回给客户端即可。示例代码如下：

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

复制代码

返回恣意结果（恣意乐成/恣意失败/失败优先）

1. // 任意成功
2. P getAnySuccessResponse(List<RequestExecutionContext<R,P>> responseContext, Predicate<P> successRespPredictor);
3. ​
4. // 失败优先
5. <R extends SpecificRecord, P extends SpecificRecord>
6. P getAnyResponseWithFailFast(List<RequestExecutionContext<R,P>> responseContext,
7.                              Predicate<P> failedRespPredictor) throws Exception;
8. ​
9. // 所有失败
10. <R extends SpecificRecord, P extends SpecificRecord>
11. List<RequestExecutionContext<R,P>> getAllFailedResponseContext(
12.         List<RequestExecutionContext<R,P>> responseContext, Predicate<P> failedRespPredictor);

复制代码

场景：批量操纵哀求按照用户被拆分成多个后，响应中不含有效户信息，仅存在乐成/失败/状态码的字段
典型场景示例代码：综合以上的用法，我们针对典型的场景给出两套尺度的示例代码：
【1】批量编辑强绑订单，哀求中含有多个待编辑的订单信息，响应为编辑失败的订单号集合

1. private EditForceMatchedOrderResponse editForceMatchedOrder(EditForceMatchedOrderRequest request) {
2. ​
3.     MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
4.     MultiUserRequestExecutor executor = MultiUserRequestExecutorImpl.getInstance();
5.     MultiUserResponseAggregator aggregator = MultiUserResponseAggregatorImpl.getInstance();
6. ​
7.     try {
8.         Map<SwitchTag, EditForceMatchedOrderRequest> splitRequests =splitter.split(
9.           request,
10.           "forceMatchedOrderList",
11.           ForceMatchedOrder::getOrderId,
12.           MappingFieldType.FLIGHT_ORDER_ID);
13. ​
14.         List<RequestExecutionContext<EditForceMatchedOrderRequest, EditForceMatchedOrderResponse>> execResults = executor.execRequests(
15.           splitRequests,
16.           EditForceMatchedOrderResponse.class,
17.           FlightchangeSpecialeventServiceClient.getInstance(),
18.           "editForceMatchedOrder");
19. ​
20.         return aggregator.aggregateAllDistinct(execResults, "updateFailedList", null, null);
21.     } catch (Exception e) {
22.         // exception process
23.     }
24. }

复制代码

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

1. private QueryForceMatchedOrderResponse queryForceMatchedOrder(QueryForceMatchedOrderRequest request) {
2.     MultiUserRequestSplitter splitter = MultiUserRequestSplitterImpl.getInstance();
3.     MultiUserRequestExecutor executor = MultiUserRequestExecutorImpl.getInstance();
4.     MultiUserResponseAggregator aggregator = MultiUserResponseAggregatorImpl.getInstance();
5. ​
6.     try {
7.         Map<SwitchTag, QueryForceMatchedOrderRequest> splitRequests = splitter.broadcast(request);
8. ​
9.         List<RequestExecutionContext<QueryForceMatchedOrderRequest, QueryForceMatchedOrderResponse>> execResults = executor.execRequests(
10.           splitRequests,
11.           QueryForceMatchedOrderResponse.class,
12.           FlightchangeSpecialeventServiceClient.getInstance(),
13.           "queryForceMatchedOrder");
14. ​
15.         return aggregator.aggregateByUCS(execResults,
16.                                          "forceMatchedOrderList",
17.                                          ForceMatchedOrder::getOrderId,
18.                                          MappingFieldType.FLIGHT_ORDER_ID);
19.     } catch (Exception e) {
20.         // exception process
21.     }
22. }

复制代码

配置项列表

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

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

复制代码

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

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。