核心内容摘要
《WWW.17C.COM》
时间入职第 5 天天气晴由于肾上腺素飙升感觉有点热任务以太坊 Shanghai (上海) 硬分叉升级SLA 要求业务零中断刚到公司打开 Slack我就感受到了一股紧迫的气氛。
#announcements频道里弹出了一条加急通知以太坊主网将于区块高度18,500,000正式激活 Shanghai 升级。
组长把我叫到白板前画了两条线一条向左一条向右。
“Alen这是硬分叉 (Hard Fork)。
如果我们在高度达到之前没有升级 Geth 和 Lighthouse我们的节点就会因为不认识新规则跑向右边这条废弃的分叉链。
到时候 Scanner 读到的就是假数据这属于 P0 级事故。
”目前的挑战截止时间还有 48 小时。
业务限制Scanner 正在高频扫链一秒钟都不能停。
停机意味着漏块漏块意味着用户充值无法入账。
上午 10:00制定策略 —— 拒绝原地升级我的第一反应是像维护 Web2 服务那样停服务 - 换包 - 重启。
但在脑子里预演了一遍后我否决了这个方案。
风险点Geth 在重启时需要重新加载巨大的数据库索引可能耗时
分钟。
这段时间 Nginx 会报 502Scanner 业务会断。
万一新版本 binary 有 Bug 起不来或者数据库结构不兼容需要 Migration迁移那我就挂在半空了回滚都来不及。
决定方案AWS 蓝绿部署 (Blue/Green Deployment)我要起一台全新的Node B (Green)在后台升级并同步好。
等它准备就绪再在 Nginx 层把流量像扳道岔一样切过去。
用户无感风险可控。
☁️
上午 11:00AWS 的“时间魔法” —— EBS 快照如果从零同步一台新节点需要 2 天根本来不及。
这时候我作为 AWS 老兵的经验派上了用场。
操作步骤制作快照 (无需停机) 我登录 AWS 控制台找到正在运行的 Node A (旧节点) 的数据盘卷 (vol-xxxxxx)。
这块盘是io2类型的支持高性能热快照。
Action:Create SnapshotDescription:eth-mainnet-pre-shanghai-fork耗时: 因为是增量快照大约 15 分钟就完成了。
克隆磁盘 用刚刚做好的快照创建一块新的 EBS 卷 (vol-yyyyyy)。
Type:io2 Block Express(必须保持高性能)IOPS: 10,000Size: 2000 GB启动 Node B 启动一台新的 EC2 实例 (r6g.2xlarge)把这块新磁盘挂载到/dev/nvme1n1。
此时的状态 我拥有了一台 Node B它的硬盘里拥有 Node A 15 分钟前所有的区块链数据包括 JWT 密钥等配置文件。
我省去了 2 天的同步时间。
️
下午 2:00在 Node B 上执行升级现在我有充足的时间在 Node B 上折腾完全不影响正在跑业务的 Node A。
SSH 连接 Node B 进行操作挂载磁盘sudo mount /dev/nvme1n1 /data/ethereum # 确认数据都在 ls -l /data/ethereum/execution/geth/chaindata下载新版本客户端 根据公告我们需要 Gethv
1.
1
5和 Lighthousev
4.
1。
# 下载并解压 Geth wget https://gethstore.blob.core.windows.net/builds/geth-linux-amd64-
1.
11.
tar.gz tar -xvf geth-linux-amd64-
1.
11.
tar.gz sudo cp geth-linux-amd64-
1.
1
5/geth /usr/local/bin/geth # 下载并解压 Lighthouse wget https://github.com/sigp/lighthouse/releases/download/v
4.
1/lighthouse-v
4.
1-x86_64-unknown-linux-gnu.tar.gz tar -xvf lighthouse-v
4.
1-x86_64-unknown-linux-gnu.tar.gz sudo cp lighthouse /usr/local/bin/lighthouse关键验证 (Version Check) 在启动前必须确认新程序包含了硬分叉的代码逻辑。
/usr/local/bin/geth version # Output: Version:
1.
1
5-stable # Check flags: ShanghaiTime 1681338479看到这个时间戳我就放心了。
启动服务 使用 Day 1 写好的 systemd 脚本无需修改因为目录结构一样。
sudo systemctl start geth lighthouse同步追赶 因为快照是几小时前打的Node B 启动后Lighthouse 迅速连接 Peers指挥 Geth 开始下载这几个小时落后的区块。
journalctl -fu geth显示Importing new chain segment。
15 分钟后日志显示age4s。
Node B 已追平主网且运行着最新版本。
下午 4:30无感切换 (Traffic Switch)现在我有两套环境Node A (旧):
172.
31.
2
100正在承载 Scanner 流量。
Node B (新):
172.
31.
2
101已同步空闲。
我在Node A上配置了 Nginx参见 Day 4现在只需要修改 Nginx 的后端指向就能把流量引到 Node B。
虽然这会引入一次跨机器的内网跳转约 1ms 延迟但为了平滑升级这是值得的。
修改 Nginx 配置# /etc/nginx/sites-available/ethereum-rpc.conf upstream geth_backend { # [旧配置] 指向本机 (注释掉) # server
127.
0.
1:8545; # [新配置] 指向 Node B 的内网 IP # 保持长连接 (keepalive) 以减少 TCP 握手开销 server
172.
31.
2
101:8545; keepalive 32; }执行切换命令# 检查配置语法 sudo nginx -t # 平滑重载 (不中断现有连接) sudo nginx -s reload✅
下午 5:00验证与收尾切换的一瞬间我盯着三个窗口Scanner 业务日志一片祥和没有502没有Timeout。
业务方甚至没感觉到发生了变化。
Node B 监控CPU 和网络流量瞬间上来开始处理请求。
Node A 监控流量归零变成了一台安静的备用机。
后续处理 我并没有立即销毁 Node A。
我登录 Node A把它的软件也升级到了最新版。
我把它保留作为Cold Standby (冷备)。
如果明天 Node B 所在的 AWS 可用区 (Availability Zone) 挂了或者新硬盘坏了我只需要把 Nginx 配置改回
127.
0.
1一秒钟就能切回来。
今日
总结Web3 的升级比 Web2 更残酷因为涉及“共识”。
一旦掉队就是两个世界的差别。
但运维的本质是不变的——利用冗余架构AWS 快照 蓝绿部署来对抗不确定性。
Day 5 特别附录硬分叉与网络架构详解
Shanghai Upgrade (上海升级) 是什么意思是在上海进行升级吗Alen 的回答哈哈不是的。
这只是一个“代号”。
命名规则以太坊的每一次重大升级通常会用“Devcon开发者大会举办过的城市”来命名。
历史比如以前有London Upgrade伦敦升级EIP-1559 燃烧机制。
这次叫Shanghai Upgrade上海升级允许信标链质押提款。
下次可能叫Cancun Upgrade坎昆升级。
本质这就像 Android 系统用甜点命名安卓 8 是 Oreo安卓 9 是 Pie或者 macOS 用加州地名命名Mojave, Catalina一样。
它只是指代v
1.
1
5 这个版本引入的一系列新功能跟物理地点毫无关系。
“确认了最终高度”是说老版本到了这个高度就必须换新版本Alen 的回答是的绝对必须换。
原理区块链的代码里其实写了一段像“定时炸弹”一样的逻辑if current_block_height 18,500,000: use_new_rules() # 使用上海升级的新规则比如允许提款 else: use_old_rules() # 继续用老规则老版本的 Geth它的代码里没有new_rules()这部分逻辑。
后果当区块高度达到18,500,000时全网都在用新规则打包区块。
你的老版本 Geth 会看着新区块说“咦这个区块格式不对啊我不认” 于是你的老节点就会拒绝同步接下来的所有新区块或者卡死或者走上一条错误的路。
“Scanner 读到假数据用户充值到了但我们看不到”是什么意思通俗解释Alen 的回答这是最可怕的后果。
我们用“火车变轨”来打比方。
场景区块链就像一条铁轨所有节点都是火车跑在同一条轨道上。
高度 18,500,000是一个“变轨点” (Switch)。
正常情况升级了的节点到了变轨点大家按照新地图向“左”拐继续在那条繁华的主网 (Mainnet)上跑。
用户的充值交易比如 100 ETH都在这条主网上。
异常情况没升级的 Alen 节点到了变轨点Alen 的老节点没有新地图它不知道要向左拐。
它会直直地向“右”冲过去进入一条“废弃的岔路” (Forked Chain)。
关键点这条岔路可能也会生成区块虽然是无效的Alen 的节点会以为自己还在正常跑。
结果用户在主网左边充了 100 ETH。
Etherscan 上显示到账了。
Alen 的 Scanner连着 Alen 的老节点盯着废弃岔路右边。
废弃岔路上没有这笔 100 ETH 的交易。
悲剧Scanner 告诉公司数据库“没有充值”。
用户怒了“链上明明有钱你们交易所吞我钱”这就是所谓的“跑到分叉链上”Scanner 读到的全是那条废弃链上的“假数据”或者说是平行宇宙里的无效数据。
Nginx 指向另一台机器 (Node B)会有网络延迟影响吗Alen 的回答你非常敏锐这里确实有网络拓扑的变化但在这个场景下是可以接受的。
我们来对比一下“不能跨机器”和“能跨机器”的区别A. 为什么 Geth 和 Lighthouse 不能跨机器或最好别跨通信频率极高。
每秒钟可能交互几百次。
协议Engine API。
敏感度这是共识层。
如果延迟高了会导致验证签名超时直接导致节点漏块。
这是毫秒必争的。
B. 为什么 Nginx 和 Geth 可以跨机器通信频率中等。
Scanner 业务每秒发几百个请求查询余额。
协议HTTP / JSON-RPC。
敏感度这是业务层。
内网延迟AWS 同一个 VPC 内网同可用区服务器 A 访问服务器 B延迟通常在
5ms ~ 1ms左右。
业务容忍度Scanner 查询一个余额Geth 处理需要 20ms。
加上 Nginx 的转发 1ms变成 21ms。
对业务来说这 1ms 的差距完全无感。
结论 在“蓝绿部署”这种特殊升级时刻为了保证0 停机引入这 1ms 的内网延迟是完全划算的交易。
等升级稳定了Alen 其实可以把 Nginx 再改回指向 Localhost或者干脆就把 Node B 当成新的主节点用下去。