在实际业务中，是否碰到过这种场景：
我们需要一个单号，要在业务系统里面保证唯一，保证增长？
在运营过程，需要知道业务单发生的时间，最好不用经过系统查找就知道发生的时间？
在排障过程中，不用再次查找就知道，订单的一些信息？
业务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) 也比较常见。