Hyperledger Fabric 升级路线

需求

hyperledger fabric v1.x 升级至 v2.x

风险

1. 版本跨度较大，升级步骤及组件多而杂
2. 技术特性发生重大变化，从而带来系统架构变化（是否需要重新评估架构）
3. 升级是单向的，一旦服务启用则无法降级，仅允许回退至备份时间点，意味着新版本启用后的数据将丢失。
4. 2.x 版本于 2020 年 1 月 30 日发布，缺少经过验证的案例
5. 2.x 版本对于 Java 应用改造量尚未评估
6. 2.x 版本对于国密改造量尚未评估

方法

分三个阶段实施，每个阶段依次滚动升级节点（每次升级一个节点）

1. 阶段一： v1.x to v1.4.2(kafka)
2. 阶段二： v1.4.2(kafka) to v1.4.2(raft)
3. 阶段三： v1.4.2(raft) to v2.x

阶段一 v1.x to v1.4.2(kafka)

适用任何低于 v1.4 的升级

主要过程如下：

1. 依次停止 SDK, peer, orderer, kafka, zookeeper
2. 备份 MSP, artifacts 文件及 zookeeper, kafka, orderer, peer 的持久化数据
3. kafka 集群升级
4. Orderer 升级
5. Peer 升级
6. capability 更新
7. chaincode 升级
8. SDK 升级

阶段二 v1.4.2(kafka) to v1.4.2(raft)

主要过程如下：

1. 备份 zookeeper, kafka, orderer, peer 的持久化数据
2. 备份应用版本及配置文件
3. 动态增加 Orderer 节点（生产环境建议 5 或 7 个节点）
4. 备份文件及持久化数据
5. 更新通道配置 ConsensusType.State 打开维护模式
6. 更新通道配置 ConsensusType.type 切换至 raft
7. 依次停止 orderer, kafka, zookeeper 后，仅重启 orderer
8. 切出维护模式

阶段三 v1.4.2(raft) to v2.x

主要过程如下：

1. 备份 orderer, peer 的持久化数据
2. 备份应用版本及配置文件
3. Orderer 升级
4. Peer 升级
5. capability 更新
6. chaincode 升级
7. SDK 升级