从草图着手

起手式应该着眼于功能，而非布局。不要一开始就考虑有没有顶栏或侧边栏。先思考软件的功能是什么？

如果是出行类网站，那就要提供搜索航班的功能，需要以下功能组件：

1. 出发地和目的地
2. 出发和返回日期
3. 搜索按钮

组合基本的功能组件就得到了草图。

不要一开始就把时间花在打磨细节上，要先关注功能和布局，做一个低保真的原型图。

为什么需要分布式唯一ID

传统的单机情况下，通过内存或者数据的主键就可以维护一个唯一ID，但随着业务增长，免不了增加主机和分库分表，在这种情况下如何表示一个唯一的订单或者用户呢？

这就是分布式唯一ID的意义。如果并非此场景，利用数据库自增值或者时间戳随机种子(为避免1ms内碰撞，可以再维护几位顺序位，可以参考后文snowflake算法)即可。当然由于绝大多数分布式唯一ID算法效率很高，想用也是可以的。

分布式唯一ID的要求

分布式唯一ID的要求可以拆解为三个层面：

1. 不重复。本质上不要求随机，单纯递增也可以，因为不需要避免被猜测。很多时候以随机代替不重复(随机算法够好池子够大，能够极大程度避免碰撞)。
2. 细化不重复这一要求到时间唯一和空间唯一两项。如果单纯以当前时间戳作为种子，伪随机数生成器在同一时刻、不同机器可以得出相同结果(下文有介绍原因)。
3. 还有一个隐含的要求是有序，分布式唯一ID需要作为被频繁查询的索引列。数据库索引的基本原理是B+树，通俗来说，是一个子节点更多的二叉搜索树，所以需要有序,最好是纯数字，可以避免字符类型排序的字符集转换消耗。