分布式唯一Id，它比GUID好
一、前言
分布式唯一Id，顾名思义，是指在全世界任何一台计算机上都不会重复的唯一Id。
在单机/单服务器/单数据库的小型应用中，不需要用到这类东西。但在高并发、海量数据、大型分布式应用中，分布式唯一Id却是构建整个系统的最核心一环。
二、场景
在某个大型电商系统A中，“订单”这类大数据（比如，每天产生2000万条订单）必定不会存储在1台数据库服务器中，而是分布式的存储在多台数据库服务器组成的一个集群中（比如，1000台数据库服务器组成一个集群）。由于海量数据+高并发等特性时常会伴随“订单”发生，所以，如何确保订单Id在整个系统中唯一不重复，已经有些设计难度了。
若此时，另外一家公司的电商系统B，要与你家的电商系统A合并（甚至还有更多公司的C、D、E、等等），那么这些系统合并时订单Id出现重复的概率是很大的。要把这些重复修改成唯一，又会要费一番不小的改造功夫，十分麻烦…
但是，若我们一开始就使用分布式唯一Id来实现订单Id，则不会有这些麻烦，一切迎刃而解，且十分轻松…
三、方案
DeveloperSharp包中，提供了完善的分布式唯一Id生成工具
使用示例如下：
若是在.Net Core环境下
//从NuGet引用DeveloperSharp包
using DeveloperSharp.Framework.CoreUtility; //首先在Startup.cs或Program.cs文件中进行工具预载
Services.AddTransient<IUtility, Utility>();//IU是在相关文件中，通过依赖注入方式获取的IUtility类型对象
var Id = IU.GenerateId("Order");//产生分布式唯一Id
若是在.Net Framework环境下
//从NuGet引用DeveloperSharp包
using DeveloperSharp.Framework.CoreUtility;IUtility IU = new Utility();
var Id = IU.GenerateId("Order");//产生分布式唯一Id
说明：
- “分布式唯一Id”的长度较长，具有全球唯一性，最早起源于facebook、twitter的应用。
- “分布式唯一Id”比GUID更好。GUID偶尔还是会有重复出现，而且它是无序的，会导致数据库查询性能下降，而“分布式唯一Id”是相对有序的。
经验：
其实，无论是单机小型应用，还是多机大型分布式应用，从今天开始，你都应采用“分布式唯一Id”作为数据库中、每个表的“主键”。因为与所谓可读性、长短、自增Id比起来，它的扩展性好太多、太多…
