vivo 自研鲁班分布式 ID 服务实践

作者：vivo IT 平台团队 - An Peng

本文介绍了什么是分布式 ID，分布式 ID 的业务场景以及 9 种分布式 ID 的实现方式，同时基于 vivo 内部 IT 的业务场景，介绍了自研鲁班分布式 ID 服务的实践。

一、方案背景

1.1 分布式 ID 应用的场景

随着系统的业务场景复杂化、架构方案的优化演进，我们在克服问题的过程中，也总会延伸出新的技术诉求。分布式 ID 也是诞生于这样的 IT 发展过程中，在不同的关联模块内，我们需要一个全局唯一的 ID 来让模块既能并行地解耦运转，也能轻松地进行整合处理。以下，首先让我们一起回顾这些典型的分布式 ID 场景。

**1.1.1 系统分库分表**

随着系统的持续运作，常规的**单库单表**在支撑更高规模的数量级时，无论是在性能或稳定性上都已经难以为继，需要我们对目标逻辑数据表进行合理的物理拆分，这些同一业务表数据的拆分，需要有一套完整的 ID 生成方案来保证拆分后的各物理表中同一业务 ID 不相冲突，并能在后续的合并分析中可以方便快捷地计算。

以公司的营销系统的订单为例，当前**不但以分销与零售的目标组织区别来进行分库存储，来实现多租户的数据隔离，并且会以订单的业务属性（订货单、退货单、调拔单等等）来进一步分拆订单数据**。在订单创建的时候，根据这些规则去构造全局唯一 ID，创建订单单据并保存在对应的数据库中；在通过订单号查询时，通过 ID 的规则，快速路由到对应的库表中查询；在 BI 数仓的统计业务里，又需要汇总这些订单数据进行报表分析。

**1.1.2 系统多活部署**

无论是面对着全球化的**各国数据合规诉求**，还是针对**容灾高可用的架构设计**，我们都会对同一套系统进行多活部署。多活部署架构的各单元化服务，存储的单据（如订单 / 出入库单 / 支付单等）均带有部署区域属性的 ID 结构去构成全局唯一 ID，创建单据并保存在对应单元的数据库中，在前端根据单据号查询的场景，通过 ID 的规则，可快速路由到对应的单元区域进行查询。对应多活部署架构的中心化服务，同步各单元的单据数据时，单据的 ID 是全局唯一，避免了汇聚数据时的 ID 冲突。

在公司的系统部署中，公共领域的 BPM 、待办、营销领域的系统都大范围地实施多活部署。

**1.1.3 链路跟踪技术**

在微服务架构流行的大背景下，此类微服务的应用对比单体应用的调用链路会更长、更复杂，对问题的排查带来了挑战，应对该场景的解决方案，会在流量入口处产生全局唯一的 TraceID，并在各微服务之间进行透传，进行流量染色与关联，后续通过该**全局唯一的 TraceID**，可快速地查询与关联全链路的调用关系与状态，快速定位根因问题。

在公司的各式各样的监控系统、灰度管理平台、跨进程链路日志中，都会伴随着这么一个技术组件进行支撑服务。

1.2 分布式 ID 核心的难点

-   **唯一性**: 保持生成的 ID 全局唯一，在任何情况下也不会出现重复的值（如防止时间回拔，时钟周期问题）。
    
-   **高性能**: ID 的需求场景多，中心化生成组件后，需要高并发处理，以接近 0ms 的响应大规模并发执行。
    
-   **高可用**: 作为 ID 的生产源头，需要 100% 可用，当接入的业务系统多的时候，很难调整出各方都可接受的停机发布窗口，只能接受无损发布。
    
-   **易接入**: 作为逻辑上简单的分布式 ID 要推广使用，必须强调开箱即用，容易上手。
    
-   **规律性**: 不同业务场景生成的 ID 有其特征，例如有固定的前后缀，固定的位数，这些都需要配置化管理。

1.3 分布式 ID 常见的方案

常用系统设计中主要有下图 9 种 ID 生成的方式：

![](http://doc.xiqi.site/media/202307/2023-07-02_175239_5563890.5593620714876563.png)

![](https://oscimg.oschina.net/oscnet/c8540bfe-7280-4d0c-a05c-17501963fa90.png)

1.4 分布式 ID 鲁班的方案

我们的系统跨越了**公共、生产制造、营销、供应链、财经**等多个领域。在分布式 ID 诉求下还有如下的**特点**：

-   在业务场景上除了常规的 **Long 类型** ID，也需要支持 “**String 类型**”、“**MixId 类型**”（后详述）等多种类型的 ID 生成，每一种类型也需要支持不同的长度的 ID。
    
-   在 ID 的构成规则上需要涵盖如操作类型、**区域**、**代理**等业务属性的标识；需要集中式的配置管理。
    
-   在一些特定的业务上，基于安全的考虑，还需要在尾部加上随机数来保证 ID 不能被轻易猜测。

综合参考了业界优秀的开源组件与常用方案均不能满足，为了统一管理这类基础技术组件的诉求，我们选择基于公司业务场景自研一套分布式 ID 服务：**鲁班分布式 ID 服务**。

二、系统架构

![](http://doc.xiqi.site/media/202307/2023-07-02_175239_5925700.05318897985235527.png)

2.1 架构说明

![](http://doc.xiqi.site/media/202307/2023-07-02_175239_6037600.20465993282182426.png)

三、 设计要点

3.1 支持多种类型的 ID 规则

目前鲁班分布式 ID 服务共提供 "**Long 类型** "、“**String 类型**”、“**MixId 类型**” 等三种主要类型的 ID，相关 ID 构成规则与说明如下：

**3.1.2 Long 类型**

**（1）构成规则**

静态结构由以下三部分数据组成，组成部分共 **19 位**：

-   **固定部分（4 位）**：
    
    由 FixPart+ServerPart 组成。
    
    **①** **FixPart（4 位）**：由大区 zone 1 位 / 代理 agent 1 位 / 项目 project 1 位 / 应用 app 1 位，组成的 4 位数字编码。
    
    **②** **ServerPart（4 位）**：用于定义产生全局 ID 的服务器标识位，服务节点部署时动态分配。
    
-   **动态部分 DynPart（13 位）**：
    
    System.currentTimeMillis ()- 固定配置时间的 TimeMillis （可满足使用 100 年）。
    
-   **自增部分 SelfIncreasePart（2 位）**：用于在全局 ID 的客户端 SDK 内部自增部分，由客户端 SDK 控制，业务接入方无感知。共 2 位组成。

**（2）降级机制**

主要自增部分在服务器获取初始值后，由客户端 SDK 维护，直到自增 99 后再次访问服务端获取下一轮新的 ID 以减少服务端交互频率，提升性能，服务端获取失败后抛出异常，接入业务侧需介入进行处理。

**（3）样例说明**

![](http://doc.xiqi.site/media/202307/2023-07-02_175243_6715040.6090715713593384.png)

**3.1.2 String 类型**

**（1）构成规则**

静态结构由以下五部分数据组成，组成部分共 **25~27 位**：

-   **固定部分操作位 op+FixPart（9~11 位）**：
    
    **① 操作位 op（2~4 位）**：2~4 位由业务方传入的业务类型标识字符。
    
    **② FixPart（7 位）**：业务接入时申请获取，由大区 zone 1 位，代理 agent 2 位，项目 project 2 位，应用 app 2 位组成。
    
-   **服务器标识部分 ServerPart（1 位）**: 用于定义产生全局 ID 的服务器标识位，服务节点部署时动态分配 A~Z 编码。
    
-   **动态部分 DynPart（9 位）**：
    
    System.currentTimeMillis ()- 固定配置时间的 TimeMillis ，再转换为 32 进制字符串（可满足使用 100 年）。
    
-   **自增部分 SelfIncreasePart（3 位）**：用于在全局 ID 的客户端 SDK 内部自增部分，由客户端 SDK 控制，业务接入方无感知。
    
-   **随机部分 secureRandomPart（3 位）**：用于在全局 ID 的客户端 SDK 的随机部分，由 SecureRandom 随机生成 3 位 0-9,A-Z 字母数字组合的安全随机数，业务接入方无感知。

**（2）降级机制**

主要自增部分由客户端 SDK 内部维护，一般情况下只使用 001–999 共 999 个全局 ID。也就是每向服务器请求一次，都在客户端内可以自动维护 999 个唯一的全局 ID。特殊情况下在访问服务器连接出问题的时候，可以使用带字符的自增来做服务器降级处理，使用产生 00A, 00B... 0A0, 0A1,0A2....ZZZ. 共有 36 \* 36 \* 36 - 1000 （999 纯数字，000 不用）**\= 45656 个降级使用的全局 ID**。

**（3）样例说明**

![](http://doc.xiqi.site/media/202307/2023-07-02_175241_5033750.43564006652911313.png)

**3.1.3 MixId 类型**

**（1）构成规则**

静态结构由以下三部分数据组成，组成部分共 **17 位**：

-   **固定部分 FixPart (4~6 位）**：
    
    **① 操作位 op（2~4 位）**：2~4 位由业务方传入的业务类型标识字符
    
    **② FixPart（2 位）**：业务接入时申请获取由代理 agent 2 位组成。
    
-   **动态部分 DynPart（6 位）**: 生成 ID 的时间，年（2 位）月（2 位）日（2 位）。
    
-   **自增部分 SelfIncreasePart（7 位）**：用于在全局 ID 的客户端 SDK 内部自增部分，由客户端 SDK 控制，业务接入方无感知。

**（2）降级机制**

无，每次 ID 产生均需到服务端请求获取，服务端获取失败后抛出异常，接入业务侧需介入进行处理。

**（3）样例说明**

![](http://doc.xiqi.site/media/202307/2023-07-02_175242_6185610.3660679646399061.png)

3.2 业务自定义 ID 规则实现

鲁班分布式 ID 服务内置 “Long 类型”，“String 类型”，“MixId 类型” 等三种长度与规则固定的 ID 生成算法，除以上三种类型的 ID 生成算法外，业务侧往往有自定义 ID 长度与规则的场景诉求，在鲁班分布式 ID 服务内置 ID 生成算法未能满足业务场景时，为了能在该场景快速支持业务，鲁班分布式 ID 服务提供了业务自定义接口并通过 SPI 机制在服务运行时动态加载，以实现业务自定义 ID 生成算法场景的支持，相关能力的**实现设计与接入流程**如下：

（1）ID 的构成部分主要分 FixPart、DynPart、SelfIncreasePart 三个部分。

（2）鲁班分布式 ID 服务的客户端 SDK 提供

**LuBanGlobalIDClient 的接口与 getGlobalId（...）/****setFixPart (...)/setDynPart (...)/setSelfIncreasePart (...) 等四个接口方法**。

（3）业务侧实现 LuBanGlobalIDClient 接口内的 4 个方法，通过 SPI 机制在业务侧服务进行加载，并向外暴露出 HTTP 或 DUBBO 协议的接口。

（4）用户在鲁班分布式 ID 服务管理后台对自定义 ID 生成算法的类型名称与服务地址信息进行配置，并关联需要使用的 AK 接入信息。

（5）业务侧使用时调用客户端 SDK 提供的 LuBanGlobalIDClient 的接口与 getGlobalId 方法，并传入 ID 生成算法类型与 IdRequest 入参对象，鲁班分布式 ID 服务接收请求后，动态识别与路由到对应 ID 生产算法的实现服务，并构建对象的 ID 返回给客户端，完成整个 ID 生成与获取的过程。

3.3 保证 ID 生成不重复方案

![](http://doc.xiqi.site/media/202307/2023-07-02_175239_6130590.382224191561654.png)

3.4 ID 服务无状态无损管理

服务部署的环境在虚拟机上，ip 是固定，常规的做法是在配置表里配置 ip 与机器码的绑定关系（这样在服务扩缩容的时候就需要人为介入操作，存在一定的遗漏配置风险，也带来了一定的运维成本），但在容器的部署场景，因为每次部署时 IP 均是动态变化的，以前通过配置表里 ip 与机器码的映射关系的配置实现方式显然不能满足运行在容器场景的诉求，故在服务端设计了通过心跳上报实现机器码动态分配的机制，实现服务端节点 ip 与机器码动态分配、绑定的能力，达成部署自动化与无损发布的目的。