北京
Stripe工程师最近摊牌了一件事：他们花了三年，把用了十年的PostgreSQL序列号生成器整个换掉，涉及100多个服务，却没让任何团队改代码。听起来像典型的"重构地狱"，但他们最后发现，最难的部分不是技术，是说服自己"其实可以做得更少"。
最初团队假设所有服务都需要"连续不跳号"的ID，还得严格按时间排序。这逼他们设计了一套复杂的分布式协调方案，光是脑补就觉得头发在掉。后来硬着头皮去聊，才发现大部分团队根本不在乎中间缺几个号，顺序差几毫秒也无所谓。「That single shift collapsed a hard distributed coordination problem into something almost embarrassingly simple」——原话就这么写的，"embarrassingly simple"，尴尬地简单。
他们最后把序列号生成做成了客户端库，直接嵌在应用里。99%的情况下，生成ID就是本地内存里加个数字，不用网络、不用调服务、不用碰数据库。剩1%才走服务端缓存，服务端再挂一层DynamoDB。两层缓存的设计不是为了快，是为了DynamoDB崩了业务也无感知——过去一年里，缓存救命的次数比加速多得多。
最损的一招是兼容性处理。新系统完全复刻了旧系统的每一个参数和行为，包括几个"明显设计错误"的bug。结果迁移时，团队真的只改了一行配置，从sequence_type=legacy换成sequence_type=new。有个工程师在内部帖子里说，看到监控曲线平稳得像死人的心电图时，反而有点失落，"准备了三年的 rollback 方案，一次没用上"。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
