从 到 搭建技术中台之 ID 生成服务实践.docxVIP

从 0 到 1 搭建技术大陆与台湾之 ID 生成服务实践 ID 生成器在前后端系统内都比较常见，应用场景广泛，如：订单 ID、账户 ID 、流水号、消息 ID 等等。常见的 ID 类型如下： UUID 和 GUID：GUID 和 UUID 本质类似，GUID 来源于微软。一个 UUID 是一个 16 字节 (128 bit) 的数字。UUID 由网卡 MAC 地址、时间戳、名字空间 ( Namespace )、随机或伪随机数、时序等元素进行生成。优点：在特定范围内可以保证全局独一；生成便利，单机管理即可。缺点：所占空间比较大；无序，在插入数据库时可能会引起大规模数据位置变动，功能不友好。 数据库自增 ID：次要基于关系数据库如 MySQL 的 auto_increment 自增键，在业务量不是很大时使用比较便利。基于数据库自增字段也有一些变种，如下面会引见到的号段模式。优点：实现成本低，直接基于 DB 实现，不需要引入额外组件；能够实现单调自增，递增场景友好。缺点：需要考虑高可用、横向扩展问题。 snowflake ：雪花算法由毫秒时间戳 ( 41 位) + 机器 ID( workerId 10 位) + 自增序列 ( 12 位)，理论上最多支持 1024 台机器每秒生产 400w 个 ID。雪花算法综合考虑了功能、全局独一、趋势自增、可用性等，是一种格外抱负的 ID 生成算法，也是伴鱼内部使用最为广泛的 ID 生成算法。 伴鱼内部也有很多 ID 生成的需求，像是我们的订单、领取单、一对一课程、绘本、 IM 谈天消息、账号等等。ID 类型上也基本脱离不了上面几种，但是使用质量上参差不齐。 背景 第一阶段：各自封装 伴鱼晚期业务量比较少，各系统基本都是有本人的 ID 生成模块，有基于 TiDB 自增 ID 的，有基于 UUID 的，也有基于雪花算法的，其中雪花算法也被称为 snowflake ，使用最为广泛。各自封装模块比较简约，但是实现分散、各系统模块的质量也很难统一保证。 其次阶段：集成框架 为了处理上述分散实现的问题，我们统一实现了一个综合各类 ID 生成功能的基础库，供业务方统一调用。统一基础库处理了分散调用问题，但是对于 snowflake 这种带有 workerId 的算法，需要业务系统关注 workerId 安排的规律。于是，我们把 snowflake 的规律封装到了服务管理框架内，服务启动时，由框架来担任 workerId 的安排和服务内的独一性。 第三阶段：idgen 服务 封装到框架后，同一服务的不同实例之间可以很好的处理 workerId 的安排问题。但是， workerId 的规律也使得服务内多个实例成为了无形态实例， K8s 部署也只能使用 StatefulSet 。最近两年，伴鱼业务量突飞猛进，系统数量暴增，业务对系统的稳定性、弹性提出了更高的要求，我们需要 ID 生成规律格外稳定、高效，我们需要服务实例都是无形态实例 Deployment ，使服务具备快速滚动升级、弹性伸缩的力量。基于这样的背景，我们打算供应一个单独的 ID 生成服务，需求如下： 支持 DB 号段和 snowflake 两种模式 ID 生成器本身的可用性、稳定性情外高，具备时钟校准力量 TP99 必需格外低 兼容现有规律，业务迁移要格外便利 服务使用 Deployment 部署 伴鱼的 ID 生成器能基本经受了以上三个阶段，可能有人会有疑问: 开源 ID 生成服务也不少，为什么不直接使用开源项目呢？这里有三点考虑： 开源 ID 生成服务基本以 Java 实现为主，比如 Leaf、tinyid ，我司的技术栈以 Go 为主。 历史缘由，我司之前都是使用 slowId （后面有引见，防止 js 中精度丢失的简约处理）的方式，即便直接使用开源项目也肯定要进行二次开发。 ID 生成本身并不简单，以上开源项目也缺少必要的时钟回退、多节点时钟校验等优化。综合考虑下来，我们还是打算本人开发，后续也有开源的方案，期望能为 Go 社区做些贡献。 基于以上背景和需求，我们打造了伴鱼第一代 ID 生成服务: idgen 。 系统设计 DB 号段模式 号段模式可以理解为对 DB 自增 ID 方案的优化，本质是利用批量猎取的方式，定期猎取一个号段，缓存在本地供外部使用，减轻 DB 的压力，提升对外服务功能。交互方式如下: snowflake 模式 snowflake 是 Twitter 于 2021 年初次对外公开，其值为 64 位整数，可以做到全局独一。构造如下: 系统优化 号段模式优化 双 buffer 提升功能、削减毛刺 DB 号段模式的原理比较简约，但是上面的实现方案也有肯定的潜在风险。首先，任一节点的号段耗尽时都需要从 DB 中取出下一个号段再前往