Oracle托管单组织Hyperledger Fabric多环境部署方案选型咨询

直接选方案2：为dev/uat/prod每个环境单独部署完全隔离的独立网络，不推荐单网络多通道的隔离方式，都是实际踩坑攒的经验：

• 刚好匹配你要的全链路一致性要求：三个独立网络全部部署在Oracle托管服务上，网络拓扑、节点类型、部署流程、证书管理逻辑、链码生命周期操作规则完全对齐，你在dev环境跑通的发布脚本、配置调整、故障排查步骤，可以无缝复用到uat、prod，不会出现环境差异导致的诡异问题。本地Docker部署的轻量dev环境可以保留给开发做日常单功能自测，Oracle上的托管dev环境专门做集成测试、部署流程校验，两层dev搭配开发效率更高。
• 单网络多通道只有逻辑层面的隔离，根本满足不了研发环境的隔离要求：
  • 通道只隔离链上业务数据，不隔离底层基础设施资源：三个环境共享同一套orderer集群、peer节点的计算/存储/网络带宽，dev环境做压测、批量造测试数据、异常调试的时候很容易抢占资源，拖垮uat甚至prod的交易性能，出了性能问题你都没法快速定位是代码问题还是资源抢占导致的。
  • 网络级配置是全局共享的：根CA证书、共识策略、Fabric版本补丁、节点全局参数都是整网生效的，你在dev环境测试通道配置更新、节点版本升级这类操作，一旦失误直接影响全网上线的业务，生产风险完全不可控。
  • 权限没法彻底拆分：开发人员需要dev环境的全操作权限，uat、prod的操作权限要严格收敛给测试、运维角色，单网络的权限模型是全局生效的，你做不到完全限制开发接触prod相关的节点、证书配置，等保合规层面也过不了审。
• 成本问题完全可控：dev环境在Oracle托管服务上选最低配的节点规格就行，不需要和uat、prod对齐配置，多出来的那点资源成本，和隔离性带来的风险降低、运维效率提升比起来完全可以忽略。

补充说明：单网络多通道的设计目标是给同一网络内的多组织做不同业务场景的数据隔离，从来不是用来拆分dev/uat/prod这类研发生命周期环境的，别用错场景踩没必要的坑。

内容的提问来源于stack exchange，提问作者crtag