在實際業務中，是否碰到過這種場景：

我們需要一個單號，要在業務系統裏面保證唯一，保證增長？

在運營過程，需要知道業務單發生的時間，最好不用經過系統查找就知道發生的時間？

在排障過程中，不用再次查找就知道，訂單的一些信息？

業務ID 經常需要生成以方便後續跟蹤使用。一般需要滿足以下特性：

1. 唯一性

2. 可閱讀

3. 增長

4. 數字類型？

5. 其他信息(payload)

所以，業務ID的生成，這裏涉及兩個問題：

1. ID 的規則，也就是ID 最終長什麽樣，滿足什麽約束

2. ID 生成策略

比如，一個常見的訂單號生成規則可能如下：{yyyyMMddHHmm}[0-9][0-9]{4}

這個規則滿足了以下約束：

1. 17位數字， 數據庫存儲可以用BIGINT 存儲， 各系統接口可以使用Long 類型交互

2. 可以閱讀， 通過{yyyyMMddHHmm} 快速的知道訂單的創建時間

3. 可以猜測類型， 如中間的[0-9],支持10種類型， 這個數據豐富信息，可不存。

4. 支持的最大並發在每分鐘10000，在系統確實有每分鐘10000個訂單，這個單號生成策略就夠了

當然，上述訂單號規則，只是一種實例，不過對大多數小系統足夠了。即便是這樣，上述規則，也有一些缺陷。

比如Long 範圍的限定情況下， 使用了類似string 的 拼接技術，未能充分使用Long的範圍。

如果ID 規則，不用太多考慮可讀性的話， 可以像設計序列化協議一樣，設計的更為緊湊，以容納更多信息， 比如Long 有64bit，可以按照bit 長度劃分成若幹段。

現實中，有很多系統為了單號的可讀性，經常會超出Long的最大值，所以設計為 NChar(128) 也比較常見。

業務ID 生成規則