三、UDL(User Data Location)

# 一、挑战/注意事项

【1】在过渡阶段，存在未出海的应用A调用已出海的应用B。当海外对B应用进行了数据更新，国内应用A立即获取数据时，由于使用DRC同步存在延迟，就会导致国内应用A无法获取到最新的数据。因此出海的应用需要对自身业务场景进行综合评估，判断对应的技术选型。
【2】先进行增量数据UDL清洗，再进行数据的同步。因为数据同步需要根据UDL进行过滤，将海外的数据同步至SIN环境。
【3】灰度切换过程中，服务处理一个关联了多个用户的请求，其中部分用户关联Region A，部分用户关联Region B，如何正确处理？【参考六】

# 二、简介

海外用户来自不同的国家和地区，根据各国法律要求，需要合规存储数据在特定的地方。因此需要一个标识代表用户数据所属的国家和地区，以便将对应请求路由到特定的机房，应用才能获取到对应数据进行处理。

UDL（User Data Location）：用户数据所属的国家和地区，具体为用户注册时使用的国家与地区。通常为用户注册的Locale后两位（如zh-HK，UDL为HK），目前使用请求Header中携带的Locale，因此UDL的值不会变动。这里的国内和海外是用户当前所处的地理位置是国内(大陆)还是海外(含港澳台)，非国籍上的，如上海人在美国打开App，此时应当做海外用户对待。

WARNING

框架中间件根据UDL路由表和“流量”中的UDL标识来路由“流量”。
【1】UDL路由表：由UCS管理和下发；
【2】“流量”需要带UDL标识，“流量”包括：外网流量、SOA请求、QMQ消息等；

Mysql增量数据UDL清洗

# 三、如何获得UDL标识

【1】外网流量：用户中心下发用户对应的UDL到手机App/H5 cookie等；
【2】SOA流量：由对应的外网流量全链路传递下来或由业务应用设置；
【3】QMQ流量：由对应的外网流量全链路传递下来或业务应用设置，持久化在消息存储中；
【4】Job：一般来自于数据库的UDL字段；

# 四、DAL默认策略

默认从CAT获取ucs-udl信息。通过cookie/参数/head中带上UserId。

TraceContext traceContext = Cat.getTraceContext(true);
String udl = traceContext.get("ucs-udl");

1
2

JOB：通过UCS客户端，把当前环境标记成JOB。
【1】JOB如果直接操作DB，按照JOB的单元化方案，查询->过滤->操作的流程即可；
【2】如果JOB会调用SOA来操作DB，当前SOA是Local-2-Local，和直接操作DB无差别；

策略中包含以下信息：
【1】基于UID的流量分配分支（一般用于点测验证）
● 用户需要配置一个 UID 列表和目标 Region 的映射关系。
● 一个策略中可以包含多个上述这种映射关系。
【2】基于UDL的流量分配分支
● 用户可以为不同的Region设置多种分配分支，单个分支可以关联一个或多个Region取值。
● 每个分支内需要配置其关联的区域和流量分配比例（实际计算时会对UID进行哈希取模确定目标区域）。
● 实际路由时使用哪个分支会查询UDL和Region的映射表来确定。
【3】系统默认提供一个兜底分支，即当请求未命中上述任何分配逻辑时，默认就近访问，即由接受请求的服务器所在的Region负责处理该请求。
【4】兜底分支支持用户自行配置，可其关联的区域和流量分配比例。
【5】请求路由流程示意图：

# 五、UDL信息查询

用户可以通过sdk中提供的服务来查询给定业务记录对应的UID和UDL信息。代码示例如下：

public void udlQueryTest() {
    UserDataLocationQueryService udlQueryService = UserDataLocationQueryServiceImpl.getInstance();
    UDLQueryResponse udlQueryResponse = udlQueryService.query(18910498705L, MappingFieldType.FLIGHT_ORDER_ID);
    ... // custom process
}

public class UDLQueryResponse {
    private final UserDataLocation userDataLocation;
    private final UDLQueryErrorCode errorCode;
    private final Throwable occurredException;
}

1
2
3
4
5
6
7
8
9
10
11

其中，MappingFieldType是一个查询参数类型对应的枚举，目前支持的参数类型包括：

USER_ID, String.class), // 用户UID
FLIGHT_ORDER_ID(2, Long.class), // 机票订单号
PRODUCT_ORDER_ID(3, Long.class), // X产品订单号
CHANGE_ORDER_ID(4, Long.class), // 航变订单号
RETAIN_BILL_ID(6, Long.class), // 留用单单号

1
2
3
4
5

# 六、分流

客户端分流： 客户端在调用的时候明确知道这个请求关联了多个用户，则通过UCS客户端将这两拨用户按照Region进行拆分，然后分别请求。SOA客户端在路由的时候会通过UCS客户端判断这些用户是否归属于相同的Region，然后将这个请求路由至对应的Region。如果单个请求中的用户并不是归属于相同的Region，此处可考虑就近或就多数两种路由方案。这里就要求UCS客户端可以读取到各个用户所属的UDL并查表确定目标Region。

服务端分流： 服务端在处理关联了多个用户的请求时，需要主动对用户信息进行校验，判断哪些用户应由当前Region进行处理，哪些用户应由其它Region处理。对于应由其它Region处理的用户数据，服务端自行通过客户端调用服务进行请求转发。SOA客户端在路由的时候会通过UCS客户端判断这些用户是否归属于相同的Region，然后将这个请求路由至对应的Region。如果单个请求中的用户并不是归属于相同的Region，此处可考虑就近或就多数两种路由方案。这里就要求UCS客户端可以读取到各个用户所属的UDL并查表确定目标Region。

← 二、项目架构四、UCS 策略 →