我在区块链架构领域工作了五年, 期间目睹了太多团队口头上强调去中心化这个概念, 但是最终开发出来的产品实际上仅仅是换了一个外壳的中心化数据库罢了。涉及区块链的分布式系统在实际操作层面并没有像宣传PPT里面描述的那么理想化和浪漫, 其中存在的困难和陷阱数量远远超出了一般人的预期想象。
区块链分布式系统咋搭
不要一开口就把那个公有链给选上。在大多数的企业应用场景里面, 大家是用不到以太坊那样的共识机制的。其实对于大多数情况来说, 采用四节点Raft以及加上链上的存证方案就完全足够了。
我记得去年我给一个供应链项目实施了这个搭建, 最终把这个延迟的时间严格控制在两百毫秒以内, 这个速度比某条特定的公有制链的传输速度要快了整整十倍以上, 所以当那个客户去进行验收的时候, 盯着监控面板看了半天很长时间才真正相信了这件事。
在存储层这个地方, 千万不要去贪图规模过大。应当把交易数据通过分片的方式, 分别存放在各个节点的本地硬盘之中, 而共识协议只需要传递数据的摘要信息就可以了。
如果在开始的时候为了图省事, 选择了全量广播的数据传输方式, 那么在节点数量增加到八个的时候, 系统会直接出现卡死的现象。后续只有对数据流进行拆分处理, 程序才能恢复正常运转状态。光是进行回滚测试这一项工作, 就耗费了两周的时间。
区块链分布式系统难处
大家通常以为, 去攻克那个共识算法才是最为棘手的难题, 然而实际上, 处理故障恢复这件事才是最难的。
无论是由于节点突然掉线导致的连接中断, 还是因为网络发生分区所引发的数据不一致, 又或者是出现了所谓脏数据的情况, 只要在这些任何一个关键环节上没能做好兜底保护工作, 整条区块链系统就会立刻陷入停摆状态。
我自己就亲眼见过一个项目案例了, 因为在技术实现层面没有开发出状态回滚机制, 结果导致某一个节点在出现异常并且重启之后, 把整个链上的所有数据都搞乱了。为了重新建立正确的工作状态, 团队足足花费了三天的时间来进行重建操作, 而现场的甲方客户差点因此气得掀翻桌子。
团队方面的能力问题同样也是非常关键的。那些编写智能合约的工作人员和那些搭建分布式框架的工作人员往往不是同一个团体, 这两拨人在对所谓的最终一致性这一概念的理解上面的差距是非常巨大的。
没有统一的技术语言, 在进行集成的时候大家就全是互相推卸责任, 文档写了又被删掉, 被删掉了又再写一遍,项目的周期因此就被拖延了两个月。
做这个区块链分布式的系统, 它不是买那一套中间件回来就能直接跑起来的东西。它就比较更像是一门手艺活。你必须要经历反复地摔跤、反复地进行维修和修复这么个过程。在选定好架构之前, 你最好先把业务相关的场景都考虑得十分透彻清楚一点, 千万不要被分布式这一个词就给迷住眼神了。
