注意事项与最佳实践

区块链分布式结构的特点,使得其在管理上相对单点系统要复杂的多,需要从多个角度进行仔细考量和论证。这里总结一些在生产环境中使用 Fabric 网络需要注意的地方和最佳实践技巧。

节点角色差异

Fabric 网络中各个节点可以拥有不同的角色。不同角色的众多节点负责整个网络功能中不同环节的工作负载,呈现出了差异化的处理特性。

Ordering 服务需要排序整个网络中所有的交易消息,是全网的关键组件。Orderer 维护网络中所有通道的区块链结构,往往大量吞吐区块文件。因此,对于 Orderer 节点来讲需要加强网络(至少千兆网络)、存储和内存方面的配置,并且采用集群部署的方式提高其可靠性。

Peer 节点除了处理区块和背书交易(Endorser)之外,还需要对账本状态进行更新(Committer),对身份进行验证。同时,对于每个通道来说,加入通道的节点都需要维护一个针对该通道的账本结构(存放在数据库中)和区块链结构(存放在文件系统)。因此,Peer 节点需要加强CPU、内存、存储等资源配置,Endorser 还可以在签名处理方面进行加权。对于打开文件句柄较多的节点(如配置使用 CouchDB 作为状态数据库时),可能还需要对系统的 ulimit 等参数进行调整。

而对于链码容器来说,自身不需要维护太多状态信息,但是需要执行计算操作,因此需要提高较好的计算能力支持。

一般来讲,链码容器常常跟 Peer 节点在同一服务器上,建议为 Peer 服务预留 2 GB 以上的空闲内存,4 CPU 以上资源,并且一般每个链码容器分配 256 MB 运行内存和 1/10 的 CPU 核资源(根据链码逻辑进行调整)。

日志级别

日志级别越低,输出日志内容越详细,出现问题后方便进行调试。但输出过多日志会拖慢系统的吞吐性能,严重时甚至能降低几个数量级。

因此,在生产环境中必须要仔细调整日志级别。对于关键路径上的系统,通常要配置不低于 Warning 级别的日志输出;对于非关键路径上的系统,则可以采用不低于 Info 级别的日志输出。

Fabric 在日志级别上,支持对不同组件提供不同的级别。推荐将全局配置为 warning 级别,gRPC 组件由于需要处理大量交互消息,可以配置为更高的 error 级别。

如果要追踪区块链网络中的状态变化,可以通过事件监听等方式,降低对网络处理的压力。

链码升级

Fabric 目前已经支持了链码升级特性,升级时会调用链码中的 Init 方法。通过合适地设计链码,对其进行升级操作可以保护旧版本链码所关联的状态数据不被破坏。

但是注意目前升级操作并不需要整个网络的共识,因此对部分节点上链码版本升级后,未被升级的节点上仍然会运行旧版本的链码。

从数据一致性上考虑,在对某链码代码进行升级前,推荐先将所有该链码的容器停止,并从 Peer 上备份并移除旧链码部署文件。之后先在个别 Peer 节点上部署新链码,对原有数据进行测试,成功后再在其它节点上进行升级操作。

另外,在一开始编写链码过程中,就需要考虑链码升级操作,通过传入 Init 参数指定特定的升级方法来保护原有数据。

组织结构

组织代表了维护网络的独立成员身份。一般来说,组成联盟链的各个成员,每个都拥有代表自己身份的组织。一个组织可以进一步包括多个资源实体,这些资源实体彼此具有较强的信任度,并且对外都呈现为同一组织身份。

由于 Gossip 协议目前在 MSP 范围内进行传播,因此,一般建议将组织与 MSP 一一对应,即每个组织拥有自己专属的 MSP。当一个组织拥有多个 MSP 时,不同成员之间的交互可能会带来障碍;当多个组织同属于一个 MSP 时,可能会发生不希望的跨组织的数据泄露。

另外,一个组织可以包括多个成员身份,多个 Peer 可以通过使用同一成员身份来提高高可用性。

证书管理

Fabric 网络中,CA 负责证书的管理。用户虽然可以通过 cryptogen 工具提前分配好各组织的身份证书,但对于加入到网络中的用户,以及未来支持的交易证书,都需要 Fabric CA 来进行统一管理。

Fabric CA 占据网络中安全和隐私的最核心位置,因此需要加强安全方面的防护。CA 不应该暴露在公共网络域中,并且只能由有限个具备权限的用户可以访问。

另外,根证书往往要进行离线保护处理,减少接触和泄露的可能性。通常使用中间层证书来完成实体证书的签发。同时,绝对不能直接用根证书作为组织管理员的身份证书。

账本备份和裁剪

目前,Fabric 自身并未考虑对账本结构的备份和裁剪操作。在生产环境中,需要用户自己进行处理。

一方面,推荐用户根据业务需求和吞吐量来估算所需磁盘的大小。一般的,在平均每秒百次 TPS、交易消息不太大情况下,每年大约产生 3 TB 左右数据。

账本文件一般位于默认的 /var/hyperledger/production 目录下,包括区块链结构(文件存储)和相关状态(数据库存储)。大部分操作只与数据库存储相关,因此,对于旧的区块链文件,可以考虑从本地移除,备份到容量更大的持久化存储中。当需要时,再从大容量存储中恢复到本地。

系统优化

区块链作为分布式系统,对系统的计算、网络、存储等资源都有所需求,优化的系统配置可以有效提高资源效率。

例如,可以调整系统缓存策略、允许打开的文件句柄数、调整 TCP 连接超时时间等网络参数等。如果使用容器,还可以调整容器的资源限额和访问权限等。

此外,对于第三方软件也应该根据对应文档进行调整和优化。例如使用 Kafka 共识机制,在 Kafka 2.0 版本默认保留日志时间为 7 天,应当调整为更长,但同时注意要预留足够的系统存储空间。