写代码最怕是改完bug又出新bug, 乃至在区块链这类底层逻辑里。很多人以为升级代码就是简单加个功能, 核心在于状态迁移的平滑性。你得清楚, 旧数据怎么无缝转换到新数据结构里, 成为最容易翻车的地方。
升级代码如何兼容旧数据
旧数据兼容当真是个挖得极深的坑, 我碰见好多不少团队为了想要省些琐碎麻烦, 干脆直接将原本的旧存储方案扔掉作废,没曾想就此闹出了用户资产的读取报错事态, 外界社区群起不满怨言不断。行之有效的正确做法理应是引入一套名叫“双写”的关键过渡期机制, 或是编写专门用于转换旧数据的迁移脚本工具。
譬如以太坊在前一段时间的升级, 就牵扯到了合约字节码的重新部署。此际没法只盯着逻辑是对还是不对, 还得验证哈希值是否有不一致之处。我往日常常会在测试网上跑三遍模拟环境, 专门构造些极端数据的计量, 瞧瞧内存的占用和响应时间有没有陡然猛涨。
绝可小看这种细节。一点微小的整数溢出没整治好, 发版上线后恐直接让链卡死。因此每次发版前, 鄙人会花一半工夫写单元测试, 遮盖许多过往数据态势。唯有搞清旧数据的“脾气”摸了后, 新代码方可稳稳承传。
升级代码怎么避免分叉
分叉是升级的噩梦, 节点们倘若未把版本同步好, 轻则网络出现延迟, 重则因硬分叉引发生态发生割裂, 为规避这一点, 升级不能是一刀切, 等词语出现。
我们选用投票机制附加软启动。先让一成核心节点执行新代码, 观测七十二钟头。这段时间当中, 新旧节点依托P2P网络互校区块头, 保证共识未乱。假使指标异常, 自动回滚机制当即起效。
这种设计貌似繁杂, 但能救命? 有一次更新时, 某个依赖库版本不合适配引发编译翻车, 回撤机制让我们在五分钟内恢复了旧版, 避免了全网“死机”, 要记清, 代码回撤能力比起升级代码本身更要紧。
另外, 升级包得做成增量式, 别推全量。全量升级流量太大得很, 容易把带宽生生打爆。增量包只包含发生了变的那些部分, 不同节点上下载得快得很, 且验证起来也简单得多。这不仅是技术方面的合理考量, 更是对所有节点资源的用心爱护啊。
