[[187741]]

在《分布式服務化系統(tǒng)一致性的“最佳實干”》一文中提出了保證系統(tǒng)最終一致性的定期校對模式，在定期校對模式中最常使用的方法是在每個系統(tǒng)間傳遞和保存一個統(tǒng)一的唯一流水號(或稱為traceid)，通過系統(tǒng)間兩兩核對或者第三方統(tǒng)一核對唯一流水號來保證各個系統(tǒng)之間步伐一致、沒有掉隊的行為，也就是系統(tǒng)間狀態(tài)一致，在互聯(lián)網(wǎng)的世界里，產(chǎn)生唯一流水號的服務系統(tǒng)俗稱發(fā)號器。Twitter的Snowflake是一個流行的開源的發(fā)號器的實現(xiàn)。Slowfake是由Scala語言實現(xiàn)的，并且文檔簡單、發(fā)布模式單一、缺少支持和維護，很難在現(xiàn)實的項目中直接使用。

為了能讓Java領(lǐng)域的小伙伴們在不同的環(huán)境下快速使用發(fā)號器服務，本文向大家推薦一款自主研發(fā)的多場景分布式發(fā)號器Vesta，這是由Java語言編寫的，可以通過Jar包的形式嵌入到任何Java開發(fā)的項目中，也可以通過服務化或者REST服務發(fā)布，發(fā)布樣式靈活多樣，使用簡單、方便、高效。

Vesta是一款通用的唯一流水號產(chǎn)生器，它具有全局唯一、粗略有序、可反解和可制造等特性，它支持三種發(fā)布模式：嵌入發(fā)布模式、中心服務器發(fā)布模式、REST發(fā)布模式，根據(jù)業(yè)務的性能需求，它可以產(chǎn)生最大峰值型和最小粒度型兩種類型的ID，它的實現(xiàn)架構(gòu)使其具有高性能，高可用和可伸縮等互聯(lián)網(wǎng)產(chǎn)品需要的質(zhì)量屬性，是一款通用的高性能的發(fā)號器產(chǎn)品。

本文聚焦在筆者原創(chuàng)的多場景分布式發(fā)號器Vesta的設(shè)計、實現(xiàn)、性能評估等方面，同時介紹Vesta的發(fā)布模式以及使用方式，并在最后給讀者介紹如何在你的項目中使用Vesta。

1 如何思考和設(shè)計

1.1 當前遇到的問題

當前業(yè)務系統(tǒng)的ID使用數(shù)據(jù)庫的自增字段，自增字段完全依賴于數(shù)據(jù)庫，這在數(shù)據(jù)庫移植，擴容，洗數(shù)據(jù)，分庫分表等操作時帶來了很多麻煩。

在數(shù)據(jù)庫分庫分表時，有一種辦法是通過調(diào)整自增字段或者數(shù)據(jù)庫sequence的步長來達到跨數(shù)據(jù)庫的ID的唯一性，但仍然是一種強依賴數(shù)據(jù)庫的解決方案，有諸多的限制，并且強依賴數(shù)據(jù)庫類型，我們并不推薦這種方法。

1.2 為什么不用UUID

UUID雖然能夠保證ID的唯一性，但是，它無法滿足業(yè)務系統(tǒng)需要的很多其他特性，例如：時間粗略有序性，可反解和可制造型。另外，UUID產(chǎn)生的時候使用完全的時間數(shù)據(jù)，性能比較差，并且UUID比較長，占用空間大，間接導致數(shù)據(jù)庫性能下降，更重要的是，UUID并不具有有序性，這導致B+樹索引在寫的時候會有過多的隨機寫操作(連續(xù)的ID會產(chǎn)生部分順序?qū)?，另外寫的時候由于不能產(chǎn)生順序的append操作，需要進行insert操作，這會讀取整個B+樹節(jié)點到內(nèi)存，然后插入這條記錄后寫整個節(jié)點回磁盤，這種操作在記錄占用空間比較大的情況下，性能下降比較大，具體壓測報告請參考：Mysql性能壓測實踐報告

1.3 需求分析和整理

既然數(shù)據(jù)庫自增ID和UUID有諸多的限制，我們需要整理一下發(fā)號器的需求。

1. 全局唯一

有些業(yè)務系統(tǒng)可以使用相對小范圍的唯一性，例如，如果用戶是唯一的，那么同一用戶的訂單采用自增序列在用戶范圍內(nèi)也是唯一的，但是如果這樣設(shè)計，訂單系統(tǒng)就會在邏輯上依賴用戶系統(tǒng)，因此，不如我們保證ID在系統(tǒng)范圍內(nèi)的全局唯一性更實用。

分布式系統(tǒng)保證全局唯一的一個悲觀策略是使用鎖或者分布式鎖，但是，只要使用了鎖，就會大大的降低性能。

因此，我們決定利用時間的有序性，并且在時間的某個單元下采用自增序列，達到全局的唯一性。

2. 粗略有序

上面討論了UUID的最大問題就是無序的，任何業(yè)務都希望生成的ID是有序的，但是，分布式系統(tǒng)中要做到完全有序，就涉及到數(shù)據(jù)的匯聚，當然要用到鎖或者布式鎖，考慮到效率，只能采用折中的方案，粗略有序，到底有多粗略，目前有兩種主流的方案，一種是秒級有序，一種是毫秒級有序，這里又有一個權(quán)衡和取舍，我們決定支持兩種方式，通過配置來決定服務使用其中的一種方式。

3. 可反解

一個 ID 生成之后，ID本身帶有很多信息量，線上排查的時候，我們通常首先看到的是ID，如果根據(jù)ID就能知道什么時候產(chǎn)生的，從哪里來的，這樣一個可反解的 ID 可以幫上很多忙。

如果ID 里有了時間而且能反解，在存儲層面就會省下很多傳統(tǒng)的timestamp 一類的字段所占用的空間了，這也是一舉兩得的設(shè)計。

4. 可制造

一個系統(tǒng)即使再高可用也不會保證永遠不出問題，出了問題怎么辦，手工處理，數(shù)據(jù)被污染怎么辦，洗數(shù)據(jù)，可是手工處理或者洗數(shù)據(jù)的時候，假如使用數(shù)據(jù)庫自增字段，ID已經(jīng)被后來的業(yè)務覆蓋了，怎么恢復到系統(tǒng)出問題的時間窗口呢?

所以，我們使用的發(fā)號器一定要可復制，可恢復 ，可制造。

5. 高性能

不管哪個業(yè)務，訂單也好，商品也好，如果有新記錄插入，那一定是業(yè)務的核心功能，對性能的要求非常高，ID生成取決于網(wǎng)絡IO和CPU的性能，CPU一般不是瓶頸，根據(jù)經(jīng)驗，單臺機器TPS應該達到10000/s。

6. 高可用

首先，發(fā)號器必須是一個對等的集群，一臺機器掛掉，請求必須能夠轉(zhuǎn)發(fā)到其他機器，另外，重試機制也是必不可少的。最后，如果遠程服務宕機，我們需要有本地的容錯方案，本地庫的依賴方式可以作為高可用的最后一道屏障。

7. 可伸縮

作為一個分布式系統(tǒng)，永遠都不能忽略的就是業(yè)務在不斷地增長，業(yè)務的絕對容量不是衡量一個系統(tǒng)的唯一標準，要知道業(yè)務是永遠增長的，所以，系統(tǒng)設(shè)計不但要考慮能承受的絕對容量，還必須考慮業(yè)務增長的速度，系統(tǒng)的水平伸縮是否能滿足業(yè)務的增長速度是衡量一個系統(tǒng)的另一個重要標準。

1.4 設(shè)計與實現(xiàn)

1. 發(fā)布模式

根據(jù)最終的客戶使用方式，可分為嵌入發(fā)布模式，中心服務器發(fā)布模式和REST發(fā)布模式。

1. 嵌入發(fā)布模式：只適用于Java客戶端，提供一個本地的Jar包，Jar包是嵌入式的原生服務，需要提前配置本地機器ID(或者服務啟動時候Zookeeper動態(tài)分配唯一的ID,在第二版中實現(xiàn))，但是不依賴于中心服務器。
2. 中心服務器發(fā)布模式：只適用于Java客戶端，提供一個服務的客戶端Jar包，Java程序像調(diào)用本地API一樣來調(diào)用，但是依賴于中心的ID產(chǎn)生服務器。
3. REST發(fā)布模式：中心服務器通過Restful API導出服務，供非Java語言客戶端使用。

發(fā)布模式最后會記錄在生成的ID中。也參考下面數(shù)據(jù)結(jié)構(gòu)段的發(fā)布模式相關(guān)細節(jié)。

2. ID類型

根據(jù)時間的位數(shù)和序列號的位數(shù)，可分為最大峰值型和最小粒度型。

1). 最大峰值型：采用秒級有序，秒級時間占用30位，序列號占用20位

2). 最小粒度型：采用毫秒級有序，毫秒級時間占用40位，序列號占用10位

最大峰值型能夠承受更大的峰值壓力，但是粗略有序的粒度有點大，最小粒度型有較細致的粒度，但是每個毫秒能承受的理論峰值有限，為1k，同一個毫秒如果有更多的請求產(chǎn)生，必須等到下一個毫秒再響應。

ID類型在配置時指定，需要重啟服務才能互相切換。

3. 數(shù)據(jù)結(jié)構(gòu)

1). 機器ID

10位， 2^10=1024, 也就是最多支持1000+個服務器。中心發(fā)布模式和REST發(fā)布模式一般不會有太多數(shù)量的機器，按照設(shè)計每臺機器TPS 1萬/s，10臺服務器就可以有10萬/s的TPS，基本可以滿足大部分的業(yè)務需求。

但是考慮到我們在業(yè)務服務可以使用內(nèi)嵌發(fā)布方式，對機器ID的需求量變得更大，這里最多支持1024個服務器。

2). 序列號

最大峰值型

20位，理論上每秒內(nèi)平均可產(chǎn)生2^20= 1048576個ID，百萬級別，如果系統(tǒng)的網(wǎng)絡IO和CPU足夠強大，可承受的峰值達到每毫秒百萬級別。

最小粒度型

10位，每毫秒內(nèi)序列號總計2^10=1024個, 也就是每個毫秒最多產(chǎn)生1000+個ID，理論上承受的峰值完全不如我們最大峰值方案。

3). 秒級時間/毫秒級時間

最大峰值型

30位，表示秒級時間，2^30/60/60/24/365=34，也就是可使用30+年。

最小粒度型

40位，表示毫秒級時間，2^40/1000/60/60/24/365=34，同樣可以使用30+年。

4). 生成方式

2位，用來區(qū)分三種發(fā)布模式：嵌入發(fā)布模式，中心服務器發(fā)布模式，REST發(fā)布模式。

• 00：嵌入發(fā)布模式
• 01：中心服務器發(fā)布模式
• 02：REST發(fā)布模式
• 03：保留未用

5). ID類型

1位，用來區(qū)分兩種ID類型：最大峰值型和最小粒度型。

• 0：最大峰值型
• 1：最小粒度型

6). 版本

1位，用來做擴展位或者擴容時候的臨時方案。

• 0：默認值，以免轉(zhuǎn)化為整型再轉(zhuǎn)化回字符串被截斷
• 1：表示擴展或者擴容中

作為30年后擴展使用，或者在30年后ID將近用光之時，擴展為秒級時間或者毫秒級時間來掙得系統(tǒng)的移植時間窗口，其實只要擴展一位，完全可以再使用30年。

4. 并發(fā)

對于中心服務器和REST發(fā)布方式，ID生成的過程涉及到網(wǎng)絡IO和CPU操作，ID的生成基本都是內(nèi)存到高速緩存的操作，沒有IO操作，網(wǎng)絡IO是系統(tǒng)的瓶頸。

相對于CPU計算速度來說網(wǎng)絡IO是瓶頸，因此，ID產(chǎn)生的服務使用多線程的方式，對于ID生成過程中的競爭點time和sequence，我們使用concurrent包的ReentrantLock進行互斥。

5. 機器ID的分配

我們將機器ID分為兩個區(qū)段，一個區(qū)段服務于中心服務器發(fā)布模式和REST發(fā)布模式，另外一個區(qū)段服務于嵌入發(fā)布模式。

0-923：嵌入發(fā)布模式，預先配置，(或者由Zookeeper產(chǎn)生，第二版中實現(xiàn))，最多支持924臺內(nèi)嵌服務器

924 – 1023：中心服務器發(fā)布模式和REST發(fā)布模式，最多支持300臺，最大支持300*1萬=300萬/s的TPS

如果嵌入式發(fā)布模式和中心服務器發(fā)布模式以及REST發(fā)布模式的使用量不符合這個比例，我們可以動態(tài)調(diào)整兩個區(qū)間的值來適應。

另外，各個垂直業(yè)務之間具有天生的隔離性，每個業(yè)務都可以使用最多1024臺服務器。

6. 與Zookeeper集成

對于嵌入發(fā)布模式，服務啟動需要連接Zookeeper集群，Zookeeper分配一個0-923區(qū)間的一個ID，如果0-923區(qū)間的ID被用光，Zookeeper會分配一個大于923的ID，這種情況，拒絕啟動服務。

如果不想使用Zookeeper產(chǎn)生的唯一的機器ID，我們提供缺省的預配的機器ID解決方案，每個使用統(tǒng)一發(fā)號器的服務需要預先配置一個默認的機器ID。

注：此功能在第二版中實現(xiàn)。

7. 時間同步

使用Linux的定時任務crontab，定時通過授時服務器虛擬集群(全球有3000多臺服務器)來核準服務器的時間。

ntpdate -u pool.ntp.orgpool.ntp.org 

時間相關(guān)的影響以及思考：

1.調(diào)整時間是否會影響ID產(chǎn)生功能?

1). 未重啟機器調(diào)慢時間，Vesta拋出異常，拒絕產(chǎn)生ID。重啟機器調(diào)快時間，調(diào)整后正常產(chǎn)生ID，調(diào)整時段內(nèi)沒有ID產(chǎn)生。

2). 重啟機器調(diào)慢時間，Vesta將可能產(chǎn)生重復的時間，系統(tǒng)管理員需要保證不會發(fā)生這種情況。重啟機器調(diào)快時間，調(diào)整后正常產(chǎn)生ID，調(diào)整時段內(nèi)沒有ID產(chǎn)生。

每4年一次同步潤秒會不會影響ID產(chǎn)生功能?

1). 原子時鐘和電子時鐘每四年誤差為1秒，也就是說電子時鐘每4年會比原子時鐘慢1秒，所以，每隔四年，網(wǎng)絡時鐘都會同步一次時間，但是本地機器Windows,Linux等不會自動同步時間，需要手工同步，或者使用ntpupdate向網(wǎng)絡時鐘同步。

2). 由于時鐘是調(diào)快1秒，調(diào)整后不影響ID產(chǎn)生，調(diào)整的1s內(nèi)沒有ID產(chǎn)生。

8. 設(shè)計驗證

1. 我們根據(jù)不同的信息分段構(gòu)建一個ID，使ID具有全局唯一，可反解和可制造。
2. 我們使用秒級別時間或者毫秒級別時間以及時間單元內(nèi)部序列遞增的方法保證ID粗略有序。
3. 對于中心服務器發(fā)布模式和REST發(fā)布模式，我們使用多線程處理，為了減少多線程間競爭，我們對競爭點time和sequence使用ReentrantLock來進行互斥，由于ReentrantLock內(nèi)部使用CAS，這比JVM的Synchronized關(guān)鍵字性能更好，在千兆網(wǎng)卡的前提下，至少可達到1萬/s以上的TPS。
4. 由于我們支持中心服務器發(fā)布模式，嵌入式發(fā)布模式和REST發(fā)布模式，如果某種模式不可用，可以回退到其他發(fā)布模式，如果Zookeeper不可用，可以會退到使用本地預配的機器ID。從而達到服務的最大可用。
5. 由于ID的設(shè)計，我們最大支持1024臺服務器，我們將服務器機器號分為兩個區(qū)段，一個從0開始向上，一個從128開始向下，并且能夠動態(tài)調(diào)整分界線，滿足了可伸縮性。

2 如何保證性能需求

一款軟件的發(fā)布必須保證滿足性能需求，這通常需要在項目初期提出性能需求，在項目進行中做性能測試來驗證，請參考本文末尾的源碼連接下載源代碼，查看性能測試用例，本章節(jié)只討論性能需求和測試結(jié)果，以及改進點。

2.1 性能需求

最終的性能驗證要保證每臺服務器的TPS達到1萬/s以上。

2.2 測試環(huán)境

筆記本，客戶端服務器跑在同一臺機器

雙核2.4G I3 CPU， 4G內(nèi)存

2.3 嵌入發(fā)布模式壓測結(jié)果

設(shè)置：

并發(fā)數(shù)：100

2.4 中心服務器發(fā)布模式壓測結(jié)果

設(shè)置：

并發(fā)數(shù)：100

2.5 REST發(fā)布模式(Netty實現(xiàn))壓測結(jié)果

設(shè)置：

并發(fā)數(shù)：100

Boss線程數(shù)：1

Workder線程數(shù)：4

測試結(jié)果：

2.6 REST發(fā)布模式(Spring Boot + Tomcat)壓測結(jié)果

設(shè)置：

并發(fā)數(shù)：100

Boss線程數(shù)：1

Workder線程數(shù)：2

Exececutor線程數(shù)：最小25最大200

測試結(jié)果：

2.7 性能測試總結(jié)

1. 根據(jù)測試，Netty服務可到達11000的QPS，而Tomcat只能答道5000左右的QPS。
2. 嵌入發(fā)布模式，也就是JVM內(nèi)部調(diào)用最快，沒秒可答道40萬以上?？梢娋€上服務的瓶頸在網(wǎng)絡IO以及網(wǎng)絡IO的處理上。
3. 使用Dubbo導入導出的中心服務器發(fā)布模式的QPS只有不到2000, 這比Tomcat提供的HTTP服務的QPS還要小，這個不符合常理，一方面需要查看是否Dubbo RPC需要優(yōu)化，包括線程池策略，序列化協(xié)議，通信協(xié)議等，另外一方面REST使用apache ab測試，嵌入式發(fā)布模式使用自己寫的客戶端測試，是否測試工具存在一定的差異。
4. 測試過程中發(fā)現(xiàn)loopback虛擬網(wǎng)卡達到30+M的流量，沒有到達千兆網(wǎng)卡的極限，雙核心CPU占用率已經(jīng)接近200%，也就是CPU已經(jīng)到達瓶頸。

參考上面總結(jié)第三條，中心服務器的性能問題需要在后期版本跟進和優(yōu)化。

3 如何快速使用

Vesta多場景分布式發(fā)號器支持嵌入發(fā)布模式、中心服務器發(fā)布模式、REST發(fā)布模式，每種發(fā)布 模式的API文檔以及使用向?qū)Э蓞㈨椖恐黜摰奈臋n連接。

3.1 安裝與啟動

1. 下載最新版本的REST發(fā)布模式的發(fā)布包

點擊下載：

vesta-rest-netty-0.0.1-bin.tar.gz

如果你通過源代碼方式安裝Vesta的發(fā)布包到你的Maven私服，你可以直接從你的Maven私服下載此安裝包：

wget http://ip:port/nexus/content/groups/public/com/robert/vesta/vesta-rest-netty/0.0.1/vesta-rest-netty-0.0.1-bin.tar.gz

2. 解壓發(fā)布包到任意目錄

解壓：

tar xzvf vesta-rest-netty-0.0.1-bin.tar.gz

3. 解壓后更改屬性文件

屬性文件：

vesta-rest-netty-0.0.1/conf/vesta-rest-netty.properties

文件內(nèi)容：

vesta.machine=1022

vesta.genMethod=2

vesta.type=0

注意：

機器ID為1022, 如果你有多臺機器，遞減機器ID，同一服務中機器ID不能重復。

genMethod為2表示使用嵌入發(fā)布模式

type為0, 表示最大峰值型，如果想要使用最小粒度型，則設(shè)置為1

4. REST發(fā)布模式的默認端口為8088,你可以通過更改啟動文件來更改端口號,這里以10010為例

啟動文件：

vesta-rest-netty/target/vesta-rest-netty-0.0.1/bin/server.sh

文件內(nèi)容：

port=10010

5. 修改啟動腳本，并且賦予執(zhí)行權(quán)限

進入目錄：

cd vesta-rest-netty-0.0.1/bin 

執(zhí)行命令：

chmod 755 * 

6. 啟動服務

進入目錄：

cd vesta-rest-netty-0.0.1/bin 

執(zhí)行命令：

./start.sh 

7. 如果看到如下消息，服務啟動成功

輸出：

apppath: /home/robert/vesta/vesta-rest-netty-0.0.1  
Vesta Rest Netty Server is started. 

3.2 測試Rest服務

1. 通過URL訪問產(chǎn)生一個ID

命令：

curl  

結(jié)果：

1138729511026688

2. 把產(chǎn)生的ID進行反解

命令：

curl  

結(jié)果：

{"genMethod":0,"machine":1,"seq":0,"time":12235264,"type":0,"version":0} 

JSON字符串顯示的是反解的ID的各個組成部分的數(shù)值。

3. 對產(chǎn)生的日期進行反解

命令：

curl  

結(jié)果：

Fri May 22 14:41:04 CST 2015 

4. 使用反解的數(shù)據(jù)偽造ID

命令：

curl  

結(jié)果：

1138729511026688

4 總結(jié)思考

發(fā)號器作為分布式服務化系統(tǒng)不可或缺的基礎(chǔ)設(shè)施之一，它在保證系統(tǒng)正確運行和高可用上發(fā)揮著不可替代的作用。而本文介紹了一款原創(chuàng)開源的多場景分布式發(fā)號器Vesta，并介紹了Vesta的設(shè)計、實現(xiàn)、以及使用方式，讀者在現(xiàn)實項目中可以直接使用它的任何發(fā)布模式，既裝既用，讀者也可以借鑒其中的設(shè)計思路和思想，開發(fā)自己的分布式發(fā)號器，除了發(fā)號器本身，本文按照一款開源項目的生命周期構(gòu)思文章結(jié)果，從設(shè)計、實現(xiàn)、驗證到使用向?qū)В约罢撌鲞z留的問題等，并提供了參考的開源實現(xiàn)，幫助讀者學習如何創(chuàng)建一款平臺類軟件的過程的思路，幫助讀者在技術(shù)的道路上發(fā)展越來越好。

在《分布式服務化系統(tǒng)一致性的“最佳實干”》一文中提到全局的唯一流水ID可以把一個請求在分布式系統(tǒng)中流轉(zhuǎn)的路徑聚合，而調(diào)用鏈中的spanid可以把聚合的請求路徑通過樹形結(jié)構(gòu)進行展示，讓技術(shù)支持人員輕松的發(fā)現(xiàn)系統(tǒng)出現(xiàn)的問題，能夠快速定位出現(xiàn)問題的服務節(jié)點，提高應急效率。

點擊《如何設(shè)計一款多場景分布式發(fā)號器(Vesta)》閱讀原文。

【本文為51CTO專欄作者“李艷鵬”的原創(chuàng)稿件，轉(zhuǎn)載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯(lián)系】

戳這里，看該作者更多好文