区块链已经从社会的边缘产品，变得被越来越多的人所熟悉和接受，并逐渐成为一种新趋势和未来。在这个过程中，区块链技术也取得了日新月异的发展，智能合约、共识机制、分片以及跨链等新概念，正在不断刷新着我们的认知。

　　作为一个在数据库领域奋斗10余年的老兵来看，区块链的本质其实是一个多活的分布式数据库，区块链中的很多技术，在数据库的漫长演进过程中也曾得到很多的应用和实践，为了能更好的理解区块链，我概述了从2000年开始这十几年主流系统架构的演变。我们将分成3个阶段来阐述：

　　第一阶段，Oracle集群时代

　　在这个时代中，如果想去选择一个可以支撑每秒几万笔业务的成熟数据库方案。工程师一定会推荐Oracle。而这个时期系统的主要架构如下：

　　图1 RAC架构图

　　2001年，对Oracle公司来说是一个特殊的年份，在这一年Oracle发布了甲骨文数据库产品的经典版本Oracle 9i。在这个版本的产品中，Oracle极大的增强了集群服务能力(RealApplication Cluster，RAC)，促使Oracle完成了在生产环境中，从一个单一主机节点向多节点的转换的过程。

　　RAC技术有效的解决了以往数据库单节点运行的瓶颈，提升了数据库系统的并发负载能力和高可用性，满足了企业发展过程中，管理指数级数据增长的迫切需求。因此这个方案，被广泛应用到了政府、运营商、银行、证券等各个领域，当然也包括阿里巴巴和京东等互联网巨头企业。

　　随着版本的升级，Oracle 10G的集群节点能力理论峰值扩充到了100多个。但是因为部署设备(小型机和存储)昂贵等原因，不可能有企业可以完成这个量级的部署。从我所了解的数据来看，国内一些企业在实际的业务中，应用了6-8个节点的集群。

　　尽管应用广泛，但是随着国内互联网业务的进一步发展，Oracle集群的一些问题也逐渐暴露出来，这也促使了后来国内轰轰烈烈「去IOE」运动的产生。

　　第一个问题：架构所需要的软硬件(IOE)价格昂贵

　　I

　　IBM小型机

　　O ORACLE数据库

　　E EMC存储

　　在图1的架构图中可以看到，为了保证事务的一致性，Oracle采用的是在多节点间共享存储的方式，也就是说最终的数据在磁盘上只存储一份，数据可以被多个节点读写，Oracle利用行锁等技术解决读写争用问题，并保障每个交易请求提交或回滚的一致性。

　　应用层主机通过Oracle Net Services路由到不同的数据库节点中，提交数据库交易请求后，数据库节点会定时将交易数据写入共享的磁盘阵列中。

　　我们知道IO请求在计算机请求中是非常缓慢的，这样的架构设计，更加突出了IO读写的性能瓶颈。企业的应对办法则是购买性能更好，更昂贵的磁盘阵列，提升IO性能，这也导致了IOE架构在很长一段时间内占据着国内IT采购的主流地位。

　　第二个问题：扩展能力有限，增加节点的性能收益并非线性增强

　　正如上面提到的，因为受限于IO请求的性能瓶颈。各个节点的交易数据发起IO请求将数据写入磁盘会有一定的间隔。而这个过程中，实时交易信息则是由IPC协议在各个节点间传输内存数据来同步的。这时我们需要一个高速的数据传输网络，一般是由千兆网卡来完成。

　　但是，随着节点的不断越多，需要同步的交易数据就会越多，网络争用和行锁争用也会变得越来越严重，从而导致扩展节点的性能收益并非线性增强。

　　第二个阶段：分布式数据库时代

　　随着淘宝业务的飞速发展，2010年时，淘宝已经成为Oracle中国的优异的客户了。为了降低IT成本同时满足业务的进一步发展需求，也鉴于在开源社区长期的技术积累驱动。2010年时，由淘宝技术团队开启了轰轰烈烈的「去IOE」运动，目标是用分布式的开源数据库架构替代传统的Oracle DB架构。淘宝「去IOE」的成功，有效的验证了分布式数据库在大规模生产应用中的负载能力，这也促使后续国内IT架构选型思路的转变，以及分布式数据库架构的演进。

　　分布式的数据库方案有非常多种，目前在各个互联网公司应用的也比较普遍，其本质就是将数据拆分存储到不同的节点上，从而缓解单节点读写的压力，比如按奇偶拆分数据就是一个简单的分布式系统，示意图如下：

　　当我们将数据拆分成分布式数据库之后，就不得不考虑，分布式带来的三个特性之间的权衡，正如 CAP所描述的：

　　C

　　Consistent ，各个节点数据始终是一致性

　　A Available ，在可容忍的时间内，交易请求有返回结果

　　P Partition tolerant ，单个分区宕机或断网，系统依然可使用

　　系统架构师需要根据业务，用各种变通的手法优化CAP的三个特性，让系统最终体现的效果可以与业务需求的预期一致。

　　目前看到的一些主流分布式方案，对这3个特性都有不同程度的选择。我们在运营上一个创业项目OneAPM时，为了解决处理用户访问轨迹而产生的海量数据的问题，曾综合使用过Kafka、Zookeeper、Clickhouse等架构来满足业务需求，架构图如下：

　　图2 OneAPM Ai产品分布式架构图

　　第三个阶段：区块链时代

　　从数据库技术的角度来看，区块链的本质是一个特定架构的多活分布式数据库。分布式数据库利用Paxos、RAFT等算法来保障数据库多副本的强一致性，而区块链是用共识算法来解决各个节点间数据一致性的问题。

　　POW、POS、DPOS等各类共识算法其本质都是在竞争将由哪个节点拥有写入区块(账本数据)的权力。在区块链的经济模型的设计中，对写入区块的行为进行了经济激励，极大的鼓舞了区块链生态的发展。

　　但也正是因为每个节点都有可能拥有写入区块的权力，为了保障系统数据一致性，必须与系统的响应时间之间做出权衡。所以我们看到比特币的TPS是每秒7比业务，以太坊的TPS也只有每秒几十笔业务。分布式数据库中的CAP问题，依然是区块链需要挑战的技术难题。当然，目前随着分片，闪电网络等新技术的出现，交易性能的瓶颈再被不断的优化。

　　此外，从产品的功能上来看，目前的区块链技术主要提供的交易记账的能力，并不能支撑数据库的标准能力「增删改查」，所以以功能而言，目前的区块链本质是数据库技术栈的特殊子集。在区块链上，扩充对文件和数据增删改查的能力是DAPP生态发展的关键能力。

　　纵观数据库系统演进的这3个时代，技术发展的浪潮无法阻挡，我们唯一可以做的只有学习和面对。正如分布式数据库最终替代了传统ORACLE集群，去中心化模型的区块链技术也将迭代中心化模型的业务系统。从目前的情况看，分片，闪电网络等新技术的出现，交易性能瓶颈在被不断的优化，区块链技术也正在逐步的向主流IT架构演进。