下载掌阅APP，畅读海量书库
立即打开
在分布式系统中，整体的业务被拆分成多个自治的微服务，每个微服务之间需要通过网络进行通信和交互，由于网络的不确定性，会给系统带来各种各样的不一致问题。为了避免和解决不一致问题，最重要的模式就是做系统之间的实时核对和事后核对，核对的基础就是领域对象及系统间的请求要有唯一ID来标识，这样在核对时才能有据可依。
需求是所有设计的起点，一切偏离需求的设计都是“耍流氓”。下面是笔者总结的分布式系统对发号器的基本需求。
有些业务系统可以使用相对小范围的唯一性，例如，如果用户是唯一的，那么同一用户的订单采用的自增序列在用户范围内也是唯一的，但是如果这样设计，订单系统就会在逻辑上依赖用户系统，因此，不如保证ID在系统范围内的全局唯一更实用。
分布式系统保证全局唯一的一个悲观策略是使用锁或者分布式锁，但是，只要使用了锁，就会大大地降低性能。
因此，我们决定利用时间的有序性，并且在时间的某个单元下采用自增序列，来达到全局唯一。
在前面讨论了UUID的最大问题是无序，任何业务都希望生成的ID是有序的，但是在分布式系统中要做到完全有序，就涉及数据的汇聚，当然要用到锁或者分布式锁。考虑到效率，我们只能采用折中的方案：粗略有序。目前有两种主流的方案，一种是秒级有序，另一种是毫秒级有序。这里又有一个权衡和取舍，我们决定支持两种方式，通过配置来决定服务使用其中的某种方式。
一个ID在生成之后，其本身带有很多信息量。在线上排查的时候，我们通常首先看到的是ID，如果根据ID就能知道它是什么时候产生的及是从哪里来的，则这个可反解的ID能帮我们很多忙。
如果在ID里有了时间且能反解，在存储层面就会省下很多传统的timestamp类的字段所占用的空间了，这也是一举两得的设计。
一个系统即使再高可用也不会保证永远不出问题，那么出了问题怎么办？手工处理。数据被污染了怎么办？洗数据。可是在手工处理或者洗数据时，假如使用了数据库的自增字段，ID已经被后来的业务覆盖了，那么怎么恢复到系统出问题的时间窗口呢？所以，我们使用的发号器一定要可复制、可恢复、可制造。
不管哪种业务，订单也好，商品也好，如果有新记录插入，那么一定是业务的核心功能，对性能的要求非常高。ID的生成取决于网络I/O和CPU的性能，网络I/O一般不是瓶颈，根据经验，单台机器的TPS应该能达到10000/s。
首先，发号器必须是一个对等的集群，在一台机器挂掉时，请求必须能够转发到其他机器上，重试机制也是必不可少的。然后，如果远程服务宕机，我们还需要有本地的容错方案，本地库的依赖方式可以作为高可用的最后一道屏障。
在分布式系统中，我们永远都不能忽略的是业务量在不断增长，业务的绝对容量不是衡量系统性能的唯一标准，要知道业务是永远增长的，所以，对系统的设计不但要考虑能承受的绝对容量，还必须考虑业务量增长的速度。系统的水平伸缩能否满足业务的增长速度，是衡量系统性能的另一个重要标准。