我从事区块链行业已经有五年的时间了, 从编写智能合约到管理业务的整体架构,我最大的一个感受就是大部分公司的技术架构并不是通过精心的设计规划出来的, 它们大多是因为需求驱动而野蛮生长起来的, 接下来我们要聊一些非常实际的问题。
区块链业务架构咋搭
我本人是亲眼目睹过好多团队在开始搞事情的时候, 二话不说就先画出来一大堆微服务的框框, 把那个账本的节点, 还有共识的那一层, 以及应用的那一层全部乱七八糟地塞到一起去, 导致界限变得非常模糊, 根本分不清楚。
结果等到这个系统正式上线才过了三个月, 仅仅是一次共识那层的升级操作, 就硬生生地把整个应用层给直接拖垮了, 彻底弄崩掉了。
分层这件事情它绝对不是在那裡画个大饼给人看, 是需要具备那种清晰的、单向的依赖方向关系的, 具体就是上面的那一层去调用下面的那一层, 无论如何绝对不允许出现从下面往上反着调用的依赖情况, 我这个大坑我自己确实是亲自踩过一次的。
在真正投入使用的场景下, 必须做到把链下业务逻辑和链上交易彻底解耦。具体而言, 像下单这类操作、风控这类处理、还有结算这项工作, 全都是跑在传统的服务系统里面的。
只有那一部分确实需要不可篡改记录的小模块, 才会被搬运到区块链上去。千万不要把所有东西都一股脑地堆砌到链上去, 因为链上的吞吐量是远远扛不住这些压力的, 同时带来的成本还会好几个月内翻好几倍。
区块链业务架构咋分
针对模块划这一件事, 核心原则只有一个, 那就是谁负责变更,谁就保持独立。 因为用户体系、交易撮合以及合规审计这几个部分, 它们产生变更的频率差异巨大。如果非要把这些差别很大的内容硬塞进同一个服务里面, 最终会导致灾难性的后果。
在我任职的前一家公司里, 我们曾经把审计模块从整体架构中单独拆分出来。这个动作成功使得合规报告的产出周期从原来的两周时间压缩到了两天。这样一来, 业务团队再也不用再为了等待审计报告排期而耽误事儿了。
不要去追求那种可以一下子就把整体大环境都重新整理好的做法。先要把清楚哪几个板块的连接是紧密到了极点的, 去改动一个地方会让人感到非常疼的地方是哪个, 然后就在这些地方动一刀就行了, 这样做就足够了。
因为架构本身是具有生命力的, 所以在每一次迭代的环节中去除掉一点的连接关系, 这个做法要比描绘一张完美的计划图来得实际很多。
不存在固定的正确答案, 可只要大方向选对了, 后面不论进行调整还是做出更改, 心里都不会觉得慌张和焦虑。
