vivo 自研鲁班分布式 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，可快速地查询与关联全链路的调用关系与状态，快速定位根因问题。

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