如何設(shè)計(jì)一款多場景分布式發(fā)號(hào)器（Vesta）

作者：李艷鵬 2017-04-06 15:15:02


分布式 在定期校對(duì)模式中最常使用的方法是在每個(gè)系統(tǒng)間傳遞和保存一個(gè)統(tǒng)一的唯一流水號(hào)(或稱為traceid)，通過系統(tǒng)間兩兩核對(duì)或者第三方統(tǒng)一核對(duì)唯一流水號(hào)來保證各個(gè)系統(tǒng)之間步伐一致、沒有掉隊(duì)的行為，也就是系統(tǒng)間狀態(tài)一致，在互聯(lián)網(wǎng)的世界里，產(chǎn)生唯一流水號(hào)的服務(wù)系統(tǒng)俗稱發(fā)號(hào)器。

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

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

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

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

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

1.1 當(dāng)前遇到的問題

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

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

1.2 為什么不用UUID

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

1.3 需求分析和整理

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

1. 全局唯一

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

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

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

2. 粗略有序

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

3. 可反解

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

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

4. 可制造

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

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

5. 高性能

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

6. 高可用

首先，發(fā)號(hào)器必須是一個(gè)對(duì)等的集群，一臺(tái)機(jī)器掛掉，請(qǐng)求必須能夠轉(zhuǎn)發(fā)到其他機(jī)器，另外，重試機(jī)制也是必不可少的。最后，如果遠(yuǎn)程服務(wù)宕機(jī)，我們需要有本地的容錯(cuò)方案，本地庫的依賴方式可以作為高可用的最后一道屏障。

7. 可伸縮

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

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

1. 發(fā)布模式

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

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

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

2. ID類型

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

1). 最大峰值型：采用秒級(jí)有序，秒級(jí)時(shí)間占用30位，序列號(hào)占用20位

2). 最小粒度型：采用毫秒級(jí)有序，毫秒級(jí)時(shí)間占用40位，序列號(hào)占用10位

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

ID類型在配置時(shí)指定，需要重啟服務(wù)才能互相切換。

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

1). 機(jī)器ID

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

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

2). 序列號(hào)

最大峰值型

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

最小粒度型

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

3). 秒級(jí)時(shí)間/毫秒級(jí)時(shí)間

最大峰值型

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

最小粒度型

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

4). 生成方式

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

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

5). ID類型

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

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

6). 版本

1位，用來做擴(kuò)展位或者擴(kuò)容時(shí)候的臨時(shí)方案。

• 0：默認(rèn)值，以免轉(zhuǎn)化為整型再轉(zhuǎn)化回字符串被截?cái)?/li>
• 1：表示擴(kuò)展或者擴(kuò)容中

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

4. 并發(fā)

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

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

5. 機(jī)器ID的分配

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

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

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

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

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

6. 與Zookeeper集成

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

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

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

7. 時(shí)間同步

使用Linux的定時(shí)任務(wù)crontab，定時(shí)通過授時(shí)服務(wù)器虛擬集群(全球有3000多臺(tái)服務(wù)器)來核準(zhǔn)服務(wù)器的時(shí)間。

  
 
 
 

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

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

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

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

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

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

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

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

8. 設(shè)計(jì)驗(yàn)證

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

2 如何保證性能需求

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

2.1 性能需求

最終的性能驗(yàn)證要保證每臺(tái)服務(wù)器的TPS達(dá)到1萬/s以上。

2.2 測試環(huán)境

筆記本，客戶端服務(wù)器跑在同一臺(tái)機(jī)器

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

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

設(shè)置：

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

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

設(shè)置：

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

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

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

3 如何快速使用

Vesta多場景分布式發(fā)號(hào)器支持嵌入發(fā)布模式、中心服務(wù)器發(fā)布模式、REST發(fā)布模式，每種發(fā)布 模式的API文檔以及使用向?qū)Э蓞㈨?xiàng)目主頁的文檔連接。

3.1 安裝與啟動(dòng)

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

點(diǎn)擊下載：

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

注意：

機(jī)器ID為1022, 如果你有多臺(tái)機(jī)器，遞減機(jī)器ID，同一服務(wù)中機(jī)器ID不能重復(fù)。

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

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

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

啟動(dòng)文件：

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

文件內(nèi)容：

port=10010

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

進(jìn)入目錄：

  
 
 
 

   
  
  
  
cd vesta-rest-netty-0.0.1/bin 
  
 
 
 

執(zhí)行命令：

  
 
 
 

   
  
  
  
chmod 755 * 
  
 
 
 

6. 啟動(dòng)服務(wù)

進(jìn)入目錄：

  
 
 
 

   
  
  
  
cd vesta-rest-netty-0.0.1/bin 
  
 
 
 

執(zhí)行命令：

  
 
 
 

   
  
  
  
./start.sh 
  
 
 
 

7. 如果看到如下消息，服務(wù)啟動(dòng)成功

輸出：

  
 
 
 

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

3.2 測試Rest服務(wù)

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

命令：

  
 
 
 

   
  
  
  
curl  
  
 
 
 

結(jié)果：

1138729511026688

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

命令：

  
 
 
 

   
  
  
  
curl  
  
 
 
 

結(jié)果：

  
 
 
 

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

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

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

命令：

  
 
 
 

   
  
  
  
curl  
  
 
 
 

結(jié)果：

  
 
 
 

   
  
  
  
Fri May 22 14:41:04 CST 2015 
  
 
 
 

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

命令：

  
 
 
 

   
  
  
  
curl  
  
 
 
 

結(jié)果：

1138729511026688

4 總結(jié)思考

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

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

點(diǎn)擊《如何設(shè)計(jì)一款多場景分布式發(fā)號(hào)器(Vesta)》閱讀原文。

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

分享文章：如何設(shè)計(jì)一款多場景分布式發(fā)號(hào)器（Vesta）
路徑分享：http://www.dlmjj.cn/article/cddjpsh.html