对于分布式系统而言，意味着会有很多个instance会并发的生成很多业务数据，比如订单。不同的机房、不同的机器、不同的应用实例会同时生成。所以，如何生成一个好用的全局id并不是一个简单的uuid就能够搞定的事情。事实上，数据库内置的序列(oracle)或者自增机制（mysql）也无法满足需求。虽然可以设置gap，但是他无法做到扩展时基本不受影响。

同时，纯粹意义上的uuid（指的是逻辑上，而非技术上的uuid）或者整数自增在大型应用中，很有可能是不合适的，因为很多时候，我们真正需要的ID是有一定意义的，比如反应了业务类型，日期，甚至客户编号。当然纯粹意义上的业务无关的uuid也不是一无是处，比如说在图片分享应用中，id可能就确实不需要什么含义，在社交应用中，可能id也确实不需要意义。

但是，很多应用比如saas、大型分布式企业应用比如金融交易系统、电商交易系统，完全无意义的uuid很有可能使得成本增加很多。因为不同于社交应用，企业应用的业务模式通常是用户自己的数据相关的，而不是没有倾向性的。所以，在设计uuid的过程中，我们其实针对场景进行细化，整理了一下如下的草图：

电商类的，可能需要进一步细化是搜索的还是交易处理的、资金处理的。总的来说，就是整个平台内需要根据实际情况进行分类：

1、纯UUID的；

2、业务前缀+UUID；

3、业务前缀+用户+UUID；

对于saas的，可能还会出现

4：APPID+业务前缀+用户+UUID；

日期部分，看情况，可能有，也可以没有。

为了保证长度不超过32位，UUID我们采用的是snowflake的算法实现参考。

采用一刀切的方法，通常来说，这个架构师是经验欠缺的。