開發十年，就只剩下這套架構體系了！ >>>   

為什麼要改進Twitter_Snowflake演算法呢？開始我是覺得原來的設計可能會生成的ID長度不是固定的，和設定的起始時間也有關係，而且服務還要配置這個起始時間，根據當前時間減去起始時間放入41位的時間戳裡面，所以生成的ID的長度依賴於這個起始時間，從使用者的角度，可用性不是很清晰。我想生成的ID是長度固定的，不然在使用者使用來說會很奇怪。

因為因為最大2的63次方-1，是個18位數 我看最小的18位是 ：

1101111000 0010110110 1011001110 1001110110 0100000000 0000000000
這個數還不到63位，所以在64位數前面的01就能確定位數啦。

還有原來設定了workId和datacenterId，每個佔據了5位，可以用於配置多機房的某個機器，那就是32個機房，每個機房配置32臺機器，這樣我感覺不靈活，比如，根據業務發展，就是有的機房需要配置40臺，但是有的機房就是隻需要5臺，所以我覺得這10位合併一下，可以表示1024臺機器，但是至於什麼機房的哪一臺機器，這個關係可以配置在其他地方，在發號器裡面配置Id，將這兩塊的邏輯解偶，考慮到一般中小企業也不會有那麼多臺機器要配置吧，我覺得7位128就已經夠了，除去去了前面的01佔位符，保持12位的序列不變，那麼時間戳位數就有了43位，比起原來的69年*2*2，所以有這個時間的範圍，去掉原來的起始時間設定也是合理的。

然後以下這個類的屬性的定義就是如下了：

然後主要的實現邏輯：

/**
 * 改過的SnowFlake的結構如下(每部分用-分開):
 * 01 - 0000000000 0000000000 0000000000 0000000000 000 - 0000000 - 000000000000 <br>
 * 1位標識，最高位是0<br>
 * 標識位後的1確定位數
 * 41位時間截(毫秒級)，注意，43位時間截不是儲存當前時間的時間截 69*2*2 年
 * 7位的資料機器位，來確定是一臺機器，128臺一般也夠用啦
 * 12位序列，毫秒內的計數，12位的計數順序號支援每個節點每毫秒(同一機器，同一時間截)產生4096個ID序號<br>
 * 加起來剛好64位，為一個Long型。
 */

git地址：https://github.com/woshi