近日，针对迅游公司发布的一篇“主流公链研究和分析”文章，专门的对雷达底层的相关技术原理进行了相对客观的分析和考察：

?可以看出，Radar早期版本的RocksDB?案已经被HBase所代替，HBase是何方神圣？一起来看一下：

HBase–HadoopDatabase，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群。

与YonghongZ-DataMart等商用大数据产品不同，HBase是GoogleBigtable的开源实现，类似GoogleBigtable利用GFS作为其文件存储系统，HBase利用HadoopHDFS作为其文件存储系统；Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用HadoopMapReduce来处理HBase中的海量数据；GoogleBigtable利用Chubby作为协同服务，HBase利用Zookeeper作为对应。

上图描述HadoopEcoSystem中的各层系统。其中,HBase位于结构化存储层，HadoopHDFS为HBase提供了高可靠性的底层存储支持，HadoopMapReduce为HBase提供了高性能的计算能力，Zookeeper为HBase提供了稳定服务和failover机制。

此外，Pig和Hive还为HBase提供了高层语言支持，使得在HBase上进行数据统计处理变的非常简单。Sqoop则为HBase提供了方便的RDBMS数据导入功能，使得传统数据库数据向HBase中迁移变的非常方便。

雷达的分片基于开源的Sharding架构实现

Sharding-JDBC是一套扩展于Java JDBC层的分库分表中间件，最初起源于当当的内部应用框架ddframe中的数据库访问层组件。由于分库分表需求的相对普遍，并且具备独特的生命力与关注度，因此将其抽离成为独立的项目，命名为Sharding-JDBC，并于2016年初开源。

Sharding-JDBC的最初目标是透明化分库分表所带来的复杂度，包括数据源的管理、根据业务进行的SQL改写等。作为使用Java语言开发的ddframe框架中的一部分，Sharding-JDBC顺其自然的选择了JDBC作为其分库分表扩展点的接入端。正如其名称Sharding-JDBC所昭示，它是在JDBC层进行Sharding（分库分表）的产品。

Sharding-JDBC采用无中心化架构，适用于Java开发的高性能的轻量级OLTP应用；Sharding-Proxy提供静态入口以及异构语言的支持，适用于OLAP应用以及对分片数据库进行管理和运维的场景。

ShardingSphere是多接入端共同组成的生态圈。 通过混合使用Sharding-JDBC和Sharding-Proxy，并采用同一注册中心统一配置分片策略，能够灵活的搭建适用于各种场景的应用系统，架构师可以更加自由的调整适合于当前业务的最佳系统架构。

核心功能完善

Sharding-JDBC在其后的一年中有条不紊的发布了1.x的6个大版本更新，分别是：

奠定了SQL解析、请求路由、SQL改写、SQL执行和结果归并的分库分表的核心模型的1.0.x

原生支持Spring和行表达式的1.1.x

最大努力送达型柔性事务的1.2.x

读写分离的1.3.x

分布式主键的1.4.x

全新SQL解析引擎的1.5.x

分布式治理

在分库分表功能逐渐成熟之后，在2017年，Sharding-JDBC进入了2.x时代。2.x主要实现的功能是数据库治理，它可以通过注册中心提供对配置的集中化和动态化，以及对数据库和应用进行禁用和熔断。在此基础上，还增加了面向OpenTracing协议的链路追踪能力，并且达成了与国内优秀的APM产品Apache SkyWalking（https://github.com/apache/incubator-skywalking）的合作协议，将Sharding-JDBC的追踪数据对接入SkyWalking，并让SkyWalking将采用Sharding-JDBC作为其存储引擎成为可选项。

针对其不?:

1. CFT模式会削弱区块链的去中?化特性。这是所有区块链不可能三角原理的共性，对联盟链来讲，内层的各种辅助架构模式只能实现协同效应，在分布式服务器集群规模不大的情况下，贡献效果并不明显，所以最终的实际解决方案仍然是依靠分布式服务器来实现联盟链的分布式治理。

2. Radar是基于账户模型的区块链实现，每个?户只有?个地址，所有交易都和这个地址相关，隐私保护能?较弱。针对这一点，实验室早就进行过多重签名技术的研发，针对目前用户群特性而言，单地址的模式安全性从技术角度来看实际上已足够支撑日常交易。