区块链分布式系统落地到底难在哪 干了五年架构说点大实话

区块链技术作为分布式系统的一个领域, 在近些年来受到了很多人的关注和炒作, 但是真正能够投入实际使用的案例并不是很多。作为一名在系统架构岗位工作了五年的从业者, 我见证了这个行业的太多团队遭遇挫折和失败, 所以接下来, 我想和大家聊聊行业内真实发生的一些情况和问题。

区块链分布式系统难在哪

一致性能力是一个长期存在的、非常棘手的问题。

在传统的关系型数据库当中, 大家通常都依靠唯一的中心节点来进行最终的决策判断, 但是在区块链分布式系统这样一个环境里, 每一个单独的节点在地位上面完全是平等的, 并不存在谁领导谁的说法,让成百上千个节点针对同一笔交易去达成共识, 这个过程所导致的延迟时间会出现好几倍的增长。

我们用PBFT协议进行过相关的测试验证, 当节点数量从五十个增加到两百个的时候, 产生一个新的区块所花费的时间从最初的两秒钟扩展到了八秒钟, 在这个时候, 业务的负责人员当场就表现出慌张的状态了。

扩容能力本身就是一个很大的缺点。以太坊的主网每秒只能处理30笔交易数据, 如果在供应链金融这样一个场景里遇到业务高峰期, 这种吞吐量肯定没法承受得住。虽然分片方案在理论上看起来是可行的, 但是因为跨分片通信的复杂程度太高了, 这个因素直接劝退了一半的团队。

区块链分布式系统怎么搭

大家在推进项目落地的过程中, 切莫刚一着手就去搭建完整的节点。应当把业务层面的功能交给轻量级节点或者是侧链去处理交易的确认环节。在下层的共识机制这个方面, 请选择那些具有高度实用性的方案。

如果在联盟链的应用场景里进行选择的话, Raft或者Tendermint这两种方式会比工作量证明PoW显得更加符合实际要求更为现实得多。我们曾经给一些制造业相关的客户实施解决方案, 采用的是Hyperledger Fabric这一框架搭配自定义的排序服务。

在运行了一年这一期间内, 该平台每日可以处理十万笔交易数据, 并且一直稳定运行, 没有发生过什么大型事故。

连存储这一项也不要忽视。具体做法是在链上面只存哈希值和关键状态, 而在链下面用 IPFS 来承担数据的存储量。为了让单机房拉链等同于没有发挥分布式优势这种情况不会发生, 节点部署这一步务必要横跨两个或者更多的可用区, 这一点是不可妥协的底线要求。

千万不要被去中心化这三个字给骗了, 真正在工程落地的时候, 拼的是取舍这个能力。只有把业务上真正需要的节点数量还有容忍度都定下来了以后, 剩下的部分才真的有办法可以走通。