本文介紹了什么是分布式ID，分布式ID的業(yè)務(wù)場(chǎng)景以及9種分布式ID的實(shí)現(xiàn)方式，同時(shí)基于vivo內(nèi)部IT的業(yè)務(wù)場(chǎng)景，介紹了自研魯班分布式ID服務(wù)的實(shí)踐。

一、方案背景

1.1 分布式ID應(yīng)用的場(chǎng)景

隨著系統(tǒng)的業(yè)務(wù)場(chǎng)景復(fù)雜化、架構(gòu)方案的優(yōu)化演進(jìn)，我們?cè)诳朔栴}的過程中，也總會(huì)延伸出新的技術(shù)訴求。分布式ID也是誕生于這樣的IT發(fā)展過程中，在不同的關(guān)聯(lián)模塊內(nèi)，我們需要一個(gè)全局唯一的ID來(lái)讓模塊既能并行地解耦運(yùn)轉(zhuǎn)，也能輕松地進(jìn)行整合處理。以下，首先讓我們一起回顧這些典型的分布式ID場(chǎng)景。

1.1.1 系統(tǒng)分庫(kù)分表

隨著系統(tǒng)的持續(xù)運(yùn)作，常規(guī)的單庫(kù)單表 在支撐更高規(guī)模的數(shù)量級(jí)時(shí)，無(wú)論是在性能或穩(wěn)定性上都已經(jīng)難以為繼，需要我們對(duì)目標(biāo)邏輯數(shù)據(jù)表進(jìn)行合理的物理拆分，這些同一業(yè)務(wù)表數(shù)據(jù)的拆分，需要有一套完整的 ID生成方案來(lái)保證拆分后的各物理表中同一業(yè)務(wù)ID不相沖突，并能在后續(xù)的合并分析中可以方便快捷地計(jì)算。

以公司的營(yíng)銷系統(tǒng)的訂單為例，當(dāng)前不但以分銷與零售的目標(biāo)組織區(qū)別來(lái)進(jìn)行分庫(kù)存儲(chǔ)，來(lái)實(shí)現(xiàn)多租戶的數(shù)據(jù)隔離，并且會(huì)以訂單的業(yè)務(wù)屬性（訂貨單、退貨單、調(diào)拔單等等）來(lái)進(jìn)一步分拆訂單數(shù)據(jù) 。在訂單創(chuàng)建的時(shí)候，根據(jù)這些規(guī)則去構(gòu)造全局唯一ID，創(chuàng)建訂單單據(jù)并保存在對(duì)應(yīng)的數(shù)據(jù)庫(kù)中；在通過訂單號(hào)查詢時(shí)，通過ID的規(guī)則，快速路由到對(duì)應(yīng)的庫(kù)表中查詢；在BI數(shù)倉(cāng)的統(tǒng)計(jì)業(yè)務(wù)里，又需要匯總這些訂單數(shù)據(jù)進(jìn)行報(bào)表分析。

1.1.2 系統(tǒng)多活部署

無(wú)論是面對(duì)著全球化的各國(guó)數(shù)據(jù)合規(guī)訴求 ，還是針對(duì)容災(zāi)高可用的架構(gòu)設(shè)計(jì) ，我們都會(huì)對(duì)同一套系統(tǒng)進(jìn)行多活部署。多活部署架構(gòu)的各單元化服務(wù)，存儲(chǔ)的單據(jù)（如訂單/出入庫(kù)單/支付單等）均帶有部署區(qū)域?qū)傩缘腎D結(jié)構(gòu)去構(gòu)成全局唯一ID，創(chuàng)建單據(jù)并保存在對(duì)應(yīng)單元的數(shù)據(jù)庫(kù)中，在前端根據(jù)單據(jù)號(hào)查詢的場(chǎng)景，通過ID的規(guī)則，可快速路由到對(duì)應(yīng)的單元區(qū)域進(jìn)行查詢。對(duì)應(yīng)多活部署架構(gòu)的中心化服務(wù)，同步各單元的單據(jù)數(shù)據(jù)時(shí)，單據(jù)的ID是全局唯一，避免了匯聚數(shù)據(jù)時(shí)的ID沖突。

在公司的系統(tǒng)部署中，公共領(lǐng)域的 BPM 、待辦、營(yíng)銷領(lǐng)域的系統(tǒng)都大范圍地實(shí)施多活部署。

1.1.3 鏈路跟蹤技術(shù)

在微服務(wù)架構(gòu)流行的大背景下，此類微服務(wù)的應(yīng)用對(duì)比單體應(yīng)用的調(diào)用鏈路會(huì)更長(zhǎng)、更復(fù)雜，對(duì)問題的排查帶來(lái)了挑戰(zhàn)，應(yīng)對(duì)該場(chǎng)景的解決方案，會(huì)在流量入口處產(chǎn)生全局唯一的TraceID，并在各微服務(wù)之間進(jìn)行透?jìng)鳎M(jìn)行流量染色與關(guān)聯(lián)，后續(xù)通過該全局唯一的TraceID ，可快速地查詢與關(guān)聯(lián)全鏈路的調(diào)用關(guān)系與狀態(tài)，快速定位根因問題。

在公司的各式各樣的監(jiān)控系統(tǒng)、灰度管理平臺(tái)、跨進(jìn)程鏈路日志中，都會(huì)伴隨著這么一個(gè)技術(shù)組件進(jìn)行支撐服務(wù)。

1.2 分布式ID核心的難點(diǎn)

唯一性 : 保持生成的ID全局唯一，在任何情況下也不會(huì)出現(xiàn)重復(fù)的值（如防止時(shí)間回拔，時(shí)鐘周期問題）。

高性能 : ID的需求場(chǎng)景多，中心化生成組件后，需要高并發(fā)處理，以接近 0ms的響應(yīng)大規(guī)模并發(fā)執(zhí)行。

高可用 : 作為ID的生產(chǎn)源頭，需要100%可用，當(dāng)接入的業(yè)務(wù)系統(tǒng)多的時(shí)候，很難調(diào)整出各方都可接受的停機(jī)發(fā)布窗口，只能接受無(wú)損發(fā)布。

易接入 : 作為邏輯上簡(jiǎn)單的分布式ID要推廣使用，必須強(qiáng)調(diào)開箱即用，容易上手。

規(guī)律性 : 不同業(yè)務(wù)場(chǎng)景生成的ID有其特征，例如有固定的前后綴，固定的位數(shù)，這些都需要配置化管理。

1.3 分布式ID常見的方案

常用系統(tǒng)設(shè)計(jì)中主要有下圖9種ID生成的方式：

1.4 分布式ID魯班的方案

我們的系統(tǒng)跨越了公共、生產(chǎn)制造、營(yíng)銷、供應(yīng)鏈、財(cái)經(jīng) 等多個(gè)領(lǐng)域。在分布式ID訴求下還有如下的特點(diǎn) ：

在業(yè)務(wù)場(chǎng)景上除了常規(guī)的Long類型 ID，也需要支持“String類型 ”、“MixId類型 ”（后詳述）等多種類型的ID生成，每一種類型也需要支持不同的長(zhǎng)度的ID。

在ID的構(gòu)成規(guī)則上需要涵蓋如操作類型、區(qū)域 、代理 等業(yè)務(wù)屬性的標(biāo)識(shí)；需要集中式的配置管理。

在一些特定的業(yè)務(wù)上，基于安全的考慮，還需要在尾部加上隨機(jī)數(shù)來(lái)保證ID不能被輕易猜測(cè)。

綜合參考了業(yè)界優(yōu)秀的開源組件與常用方案均不能滿足，為了統(tǒng)一管理這類基礎(chǔ)技術(shù)組件的訴求，我們選擇基于公司業(yè)務(wù)場(chǎng)景自研一套分布式ID服務(wù)：魯班分布式ID服務(wù) 。

二、系統(tǒng)架構(gòu)

2.1 架構(gòu)說明

三、 設(shè)計(jì)要點(diǎn)

3.1 支持多種類型的ID規(guī)則

目前魯班分布式ID服務(wù)共提供"Long類型 "、“String類型 ”、“MixId類型 ”等三種主要類型的ID，相關(guān)ID構(gòu)成規(guī)則與說明如下：

3.1.2 Long類型

（1）構(gòu)成規(guī)則

靜態(tài)結(jié)構(gòu)由以下三部分?jǐn)?shù)據(jù)組成，組成部分共19位 ：

固定部分（4位） ：

由FixPart+ServerPart組成。

① FixPart（4位） ：由大區(qū)zone 1位/代理 agent 1位/項(xiàng)目 project 1位/應(yīng)用 app 1位,組成的4位數(shù)字編碼。

② ServerPart（4位） ：用于定義產(chǎn)生全局ID的服務(wù)器標(biāo)識(shí)位，服務(wù)節(jié)點(diǎn)部署時(shí)動(dòng)態(tài)分配。

動(dòng)態(tài)部分DynPart（13位） ：

System.currentTimeMillis()-固定配置時(shí)間的TimeMillis （可滿足使用100年）。

自增部分SelfIncreasePart（2位） ：用于在全局ID的客戶端SDK內(nèi)部自增部分，由客戶端SDK控制，業(yè)務(wù)接入方無(wú)感知。共 2位組成。

（2）降級(jí)機(jī)制

主要自增部分在服務(wù)器獲取初始值后，由客戶端SDK維護(hù)，直到自增99后再次訪問服務(wù)端獲取下一輪新的ID以減少服務(wù)端交互頻率，提升性能，服務(wù)端獲取失敗后拋出異常，接入業(yè)務(wù)側(cè)需介入進(jìn)行處理。

（3）樣例說明

3.1.2 String類型

（1）構(gòu)成規(guī)則

靜態(tài)結(jié)構(gòu)由以下五部分?jǐn)?shù)據(jù)組成，組成部分共25~27位 ：

固定部分操作位op+FixPart（9~11位） ：

① 操作位op（2~4位） ：2~4位由業(yè)務(wù)方傳入的業(yè)務(wù)類型標(biāo)識(shí)字符。

② FixPart（7位） ：業(yè)務(wù)接入時(shí)申請(qǐng)獲取，由大區(qū)zone 1位，代理 agent 2位，項(xiàng)目 project 2位，應(yīng)用 app 2位組成。

服務(wù)器標(biāo)識(shí)部分 ServerPart（1位） : 用于定義產(chǎn)生全局ID的服務(wù)器標(biāo)識(shí)位，服務(wù)節(jié)點(diǎn)部署時(shí)動(dòng)態(tài)分配A~Z編碼。

動(dòng)態(tài)部分DynPart（9位） ：

System.currentTimeMillis()-固定配置時(shí)間的TimeMillis ，再轉(zhuǎn)換為32進(jìn)制字符串（可滿足使用100年）。

自增部分SelfIncreasePart（3位） ：用于在全局ID的客戶端SDK內(nèi)部自增部分，由客戶端SDK控制，業(yè)務(wù)接入方無(wú)感知。

隨機(jī)部分secureRandomPart（3位） ：用于在全局ID的客戶端SDK的隨機(jī)部分，由SecureRandom隨機(jī)生成3位0-9,A-Z字母數(shù)字組合的安全隨機(jī)數(shù)，業(yè)務(wù)接入方無(wú)感知。

（2）降級(jí)機(jī)制

主要自增部分由客戶端SDK內(nèi)部維護(hù)，一般情況下只使用001–999 共999個(gè)全局ID。也就是每向服務(wù)器請(qǐng)求一次，都在客戶端內(nèi)可以自動(dòng)維護(hù)999個(gè)唯一的全局ID。特殊情況下在訪問服務(wù)器連接出問題的時(shí)候，可以使用帶字符的自增來(lái)做服務(wù)器降級(jí)處理，使用產(chǎn)生00A, 00B... 0A0, 0A1,0A2....ZZZ. 共有36 * 36 * 36 - 1000 （999純數(shù)字，000不用）**= 45656個(gè)降級(jí)使用的全局ID** 。

（3）樣例說明

3.1.3 MixId類型

（1）構(gòu)成規(guī)則

靜態(tài)結(jié)構(gòu)由以下三部分?jǐn)?shù)據(jù)組成，組成部分共17位 ：

固定部分FixPart(4~6位） ：

① 操作位op（2~4位） ：2~4位由業(yè)務(wù)方傳入的業(yè)務(wù)類型標(biāo)識(shí)字符

② FixPart（2位） ：業(yè)務(wù)接入時(shí)申請(qǐng)獲取由代理 agent 2位組成。

動(dòng)態(tài)部分DynPart（6位） : 生成ID的時(shí)間，年（2位）月（2位）日（2位）。

自增部分SelfIncreasePart（7位） ：用于在全局ID的客戶端SDK內(nèi)部自增部分，由客戶端SDK控制，業(yè)務(wù)接入方無(wú)感知。

（2）降級(jí)機(jī)制

無(wú)，每次ID產(chǎn)生均需到服務(wù)端請(qǐng)求獲取，服務(wù)端獲取失敗后拋出異常，接入業(yè)務(wù)側(cè)需介入進(jìn)行處理。

（3）樣例說明

3.2 業(yè)務(wù)自定義ID規(guī)則實(shí)現(xiàn)

魯班分布式ID服務(wù)內(nèi)置“Long類型”，“String類型”，“MixId類型”等三種長(zhǎng)度與規(guī)則固定的ID生成算法，除以上三種類型的ID生成算法外，業(yè)務(wù)側(cè)往往有自定義ID長(zhǎng)度與規(guī)則的場(chǎng)景訴求，在魯班分布式ID服務(wù)內(nèi)置ID生成算法未能滿足業(yè)務(wù)場(chǎng)景時(shí)，為了能在該場(chǎng)景快速支持業(yè)務(wù)，魯班分布式ID服務(wù)提供了業(yè)務(wù)自定義接口并通過SPI機(jī)制在服務(wù)運(yùn)行時(shí)動(dòng)態(tài)加載，以實(shí)現(xiàn)業(yè)務(wù)自定義ID生成算法場(chǎng)景的支持，相關(guān)能力的實(shí)現(xiàn)設(shè)計(jì)與接入流程 如下：

（1）ID的構(gòu)成部分主要分FixPart、DynPart、SelfIncreasePart三個(gè)部分。

（2）魯班分布式ID服務(wù)的客戶端SDK提供

LuBanGlobalIDClient的接口與getGlobalId（...）/ setFixPart(...)/setDynPart(...)/setSelfIncreasePart(...)等四個(gè)接口方法 。

（3）業(yè)務(wù)側(cè)實(shí)現(xiàn)LuBanGlobalIDClient接口內(nèi)的4個(gè)方法，通過SPI機(jī)制在業(yè)務(wù)側(cè)服務(wù)進(jìn)行加載，并向外暴露出HTTP或DUBBO協(xié)議的接口。

（4）用戶在魯班分布式ID服務(wù)管理后臺(tái)對(duì)自定義ID生成算法的類型名稱與服務(wù)地址信息進(jìn)行配置，并關(guān)聯(lián)需要使用的AK接入信息。

（5）業(yè)務(wù)側(cè)使用時(shí)調(diào)用客戶端SDK提供的LuBanGlobalIDClient的接口與getGlobalId方法，并傳入ID生成算法類型與IdRequest入?yún)?duì)象，魯班分布式ID服務(wù)接收請(qǐng)求后，動(dòng)態(tài)識(shí)別與路由到對(duì)應(yīng)ID生產(chǎn)算法的實(shí)現(xiàn)服務(wù)，并構(gòu)建對(duì)象的ID返回給客戶端，完成整個(gè)ID生成與獲取的過程。

3.3 保證ID生成不重復(fù)方案

3.4 ID服務(wù)無(wú)狀態(tài)無(wú)損管理

服務(wù)部署的環(huán)境在虛擬機(jī)上，ip是固定，常規(guī)的做法是在配置表里配置ip與機(jī)器碼的綁定關(guān)系（這樣在服務(wù)擴(kuò)縮容的時(shí)候就需要人為介入操作，存在一定的遺漏配置風(fēng)險(xiǎn)，也帶來(lái)了一定的運(yùn)維成本），但在容器的部署場(chǎng)景，因?yàn)槊看尾渴饡r(shí)IP均是動(dòng)態(tài)變化的，以前通過配置表里ip與機(jī)器碼的映射關(guān)系的配置實(shí)現(xiàn)方式顯然不能滿足運(yùn)行在容器場(chǎng)景的訴求，故在服務(wù)端設(shè)計(jì)了通過心跳上報(bào)實(shí)現(xiàn)機(jī)器碼動(dòng)態(tài)分配的機(jī)制，實(shí)現(xiàn)服務(wù)端節(jié)點(diǎn)ip與機(jī)器碼動(dòng)態(tài)分配、綁定的能力，達(dá)成部署自動(dòng)化與無(wú)損發(fā)布的目的。

相關(guān)流程如下：

【注意】

服務(wù)端節(jié)點(diǎn)可能因?yàn)楫惓?非正常地退出,對(duì)于該場(chǎng)景,這里就需要有一個(gè)解綁的過程，當(dāng)前實(shí)現(xiàn)是通過公司平臺(tái)團(tuán)隊(duì)的分布式定時(shí)任務(wù)服務(wù)，檢查持續(xù)5分鐘(可配置)沒有上報(bào)心跳的機(jī)器碼分配節(jié)點(diǎn)進(jìn)行數(shù)據(jù)庫(kù)綁定信息清理的邏輯,重置相關(guān)機(jī)器碼的位置供后續(xù)注冊(cè)綁定使用。

3.5 ID使用方接入SDK設(shè)計(jì)

SDK設(shè)計(jì)主要以"接入快捷,使用簡(jiǎn)單 "的原則進(jìn)行設(shè)計(jì)。

（1）接入時(shí):

魯班分布式ID服務(wù)提供了spring-starter包,應(yīng)用只需再pom文件依賴該starter，在啟動(dòng)類里添加**@EnableGlobalClient** ，并配置AK/SK 等租戶參數(shù)即可完成接入。

同時(shí)魯班分布式ID服務(wù)提供Dubbo & Http的調(diào)用方式，通過在啟動(dòng)注解配置accessType 為HTTP/DUBBO 來(lái)確定，SDK自動(dòng)加載相關(guān)依賴。

（2）使用時(shí):

根據(jù)"Long "、"String "、"MixId "等三種id類型分別提供GlobalIdLongClient 、

GlobalIdStringClient 、GlobalIdMixIDClient 等三個(gè)客戶端對(duì)象，并封裝了統(tǒng)一的入?yún)?strong>RequestDTO 對(duì)象，業(yè)務(wù)系統(tǒng)使用時(shí)只需構(gòu)建對(duì)應(yīng)Id類型的RequestDTO對(duì)象（支持鏈?zhǔn)綐?gòu)建），并調(diào)用對(duì)應(yīng)id類型的客戶端對(duì)象getGlobalID （GlobalBaseRequestDTO

globalBaseRequestDTO） 方法，即可完成ID的構(gòu)建。

Long類型Id獲取代碼示例

packagecom.vivo.it.demo.controller;

importcom.vivo.it.platform.luban.id.client.GlobalIdLongClient;
importcom.vivo.it.platform.luban.id.dto.GlobalLongIDRequestDTO;
importorg.springframework.beans.factory.annotation.Autowired;
importorg.springframework.web.bind.annotation.RequestMapping;

@RequestMapping("/globalId")
publicclassGlobalIdDemoController{

@Autowired
privateGlobalIdLongClientglobalIdLongClient;

@RequestMapping("/getLongId")
publicStringgetLongId(){
GlobalLongIDRequestDTOglobalLongIDRequestDTO=GlobalLongIDRequestDTO.Builder()
.setAgent("1")//代理,接入申請(qǐng)時(shí)確定
.setZone("0")//大區(qū),接入申請(qǐng)時(shí)確定
.setApp("8")//應(yīng)用,接入申請(qǐng)時(shí)確定
.setProject("7")//項(xiàng)目,接入申請(qǐng)時(shí)確定
.setIdNumber(2);//當(dāng)次返回的id數(shù)量,只對(duì)getGlobalIDQueue有效,對(duì)getGlobalID(...)無(wú)效
longlongId=globalIdLongClient.getGlobalID(globalLongIDRequestDTO);
returnString.valueOf(longId);
}
}

3.6 關(guān)鍵運(yùn)行性能優(yōu)化場(chǎng)景

3.6.1 內(nèi)存使用優(yōu)化

在項(xiàng)目上線初時(shí)，經(jīng)常發(fā)生FGC，導(dǎo)致服務(wù)停頓，獲取ID超時(shí)，經(jīng)過分析，魯班分布式ID服務(wù)的服務(wù)端主要為內(nèi)存敏感的應(yīng)用，當(dāng)高并發(fā)請(qǐng)求時(shí)，過多對(duì)象進(jìn)入老年代從而觸發(fā)FGC，經(jīng)過排查主要是JVM內(nèi)存參數(shù)上線時(shí)是使用默認(rèn)的，沒有經(jīng)過優(yōu)化配置，JVM初始化的內(nèi)存較少，高并發(fā)請(qǐng)求時(shí)JVM頻繁觸發(fā)內(nèi)存重分配，相關(guān)的對(duì)象也流程老年代導(dǎo)致最終頻繁發(fā)送FGC。

對(duì)于這個(gè)場(chǎng)景的優(yōu)化思路主要是要相關(guān)內(nèi)存對(duì)象在年輕代時(shí)就快速經(jīng)過YGC回收，盡量少的對(duì)象進(jìn)行老年代而引起FGC。

基于以上的思路主要做了以下的優(yōu)化：

增大JVM初始化內(nèi)存（-Xms，容器場(chǎng)景里為-XX:InitialRAMPercentage）

增大年輕代內(nèi)存（-Xmn）

優(yōu)化代碼，減少代碼里臨時(shí)對(duì)象的復(fù)制與創(chuàng)建

3.6.2 鎖顆粒度優(yōu)化

客戶端SDK再自增值使用完或一定時(shí)間后會(huì)向服務(wù)端請(qǐng)求新的id生成，這個(gè)時(shí)候需要保證該次請(qǐng)求在多線程并發(fā)時(shí)是只請(qǐng)求一次，當(dāng)前設(shè)計(jì)是基于用戶申請(qǐng)ID的接入配置，組成為key，去獲取對(duì)應(yīng)key的對(duì)象鎖，以減少同步代碼塊鎖的粒度，避免不同接入配置去在并發(fā)去遠(yuǎn)程獲取新的id時(shí)，鎖粒度過大，造成線程的阻塞，從而提升在高并發(fā)場(chǎng)景下的性能。

四、 業(yè)務(wù)應(yīng)用

當(dāng)前魯班分布式ID服務(wù)日均ID生成量億級(jí) ，平均RT在0~1ms 內(nèi),單節(jié)點(diǎn)可支持 萬(wàn)級(jí) QPS，已全面應(yīng)用在公司IT內(nèi)部營(yíng)銷訂單、支付單據(jù)、庫(kù)存單據(jù)、履約單據(jù)、資產(chǎn)管理編碼 等多個(gè)領(lǐng)域的業(yè)務(wù)場(chǎng)景。

五、未來(lái)規(guī)劃

在可用性方面，當(dāng)前魯班分布式ID服務(wù)仍對(duì)Redis、Mysql等外部DB組件有一定的依賴（如應(yīng)用接入配置信息、MixId類型自增部分ID計(jì)數(shù)器），規(guī)劃在該依賴極端宕機(jī)的場(chǎng)景下，魯班分布式ID服務(wù)仍能有一些降級(jí)策略，為業(yè)務(wù)提供可用的服務(wù)。

同時(shí)基于業(yè)務(wù)場(chǎng)景的訴求，支持標(biāo)準(zhǔn)形式的雪花算法等ID類型。

六、 回顧總結(jié)

本文通過對(duì)分布式ID的3種應(yīng)用場(chǎng)景，實(shí)現(xiàn)難點(diǎn)以及9種分布式ID的實(shí)現(xiàn)方式進(jìn)行介紹，并對(duì)結(jié)合vivo業(yè)務(wù)場(chǎng)景特性下自研的魯班分布式id服務(wù)從系統(tǒng)架構(gòu)，ID生成規(guī)則與部分實(shí)現(xiàn)源碼進(jìn)行介紹，希望對(duì)本文的閱讀者在分布式ID的方案選型或自研提供參考。

編輯：黃飛