作者 | 余珊

本文根据 QCon 北京 2018 站上的演讲整理而成，原题《区块链 Hyperledger Fabric 的落地挑战与阿里云探索经验分享》。

**

这是今天的主题大纲，我们开始先会回顾一下区块链的概念技术和业务，我们会探讨一下区块链在企业场景落地的一些关键考虑的问题，下面也会介绍一下我们阿里云推出区块链的一些相关的工具。最后的话，我们会做一些重点分享，我们在区块链落地，从规划、运维、到应用这方面去分享我们的一些探索经验。

首先我们先回顾一下区块链的基本概念，最近一两年大家无论主动或被动的已经受到了很多区块链技术和业务科普的洗礼。 首先，区块链是什么？它是一种分布式共享账本技术，在参与区块链网络的交易各方以及监管方可以共享账本，这个账本有这样一个特性，一旦交易经过各方的确认，交易的数据就不可实现任何的更改。第二，交易历史是全程可以回溯的，交易信息里面涉及到些商业机密，交易方的身份等等都得到隐私的保护，交易本身是通过智能合约 Smart Contract 去自动执行的。

区块链的类型有很多，公有链、私有链、联盟链等等，在阿里云这边，我们的工作更多是关注联盟链这种类型。区块链本身不是一个全新的技术，它是基于一些业界已有的关键技术去构成的一套体系，包括比如基于拜占庭等共识算法。还有基于密码学的一些技术基础，像非对称密钥、数字签名等等技术。此外，它本质是一个分布式系统架构，所以会涉及到一些分布式计算如高可用，水平扩展，Gossip 通讯协议等等一些技术。

区块链要解决的核心问题，是在缺乏信任基础的商业环境下，各方如何来进行交易和协作的问题。大家看到有很多讲区块链价值，比如说提升了协作效率，降低了时间成本，提升了信息透明度等等，根源都在于我们缺乏信任以及或信任度不足的情况下，在传统模式引入的各种冗余的流程、冗余的模式、中介机构所导致的。同时区块链也会带来像去中心化 / 多中心化这样的结果，但是去中心化不是区块链的目的，真正目的是要解决跨企业的信任问题。

其实业界在区块链的实现技术上有很丰富的类型，这列举了一些影响力比较大的主流技术。其中一个在开源界影响比较大的是 Linux 基金会 Hyperledger 这样一个伞形项目，下面包含了很多区块链技术实现以及一些工具。其中获得最广泛采用的是 Hyperledger Fabric 这个项目，项目初期是由 IBM 和 DAH 一起贡献的源代码，现在全球参与的项目成员数量已经是非常多了，其次还有 Sawtooth，Iroha 等等。

其他的实现技术还有以太坊，以太坊早期是从以太币发展起来的，那么现在也有一些面向商业场景以及联盟链的分支技术。还有像 R3 Corda，R3 Corda 是面向金融场景开发的一种区块链技术，与之相比， Hyperledger Fabric 更多是面向通用行业、通用业务场景的。此外还有各个厂商自研的区块链技术，例如阿里这边有蚂蚁金服自研的蚂蚁区块链技术。

这一页大概总结一下在 Hyperledger Fabric 的发展过程中它的架构演进的过程，在 Hyperledger Fabric v0.6 采用的是左图这样一种架构体系。它跟很多厂商自研的区块链技术是一种类似的架构，它主要由 Peer 节点构成，Peer 上面保存了账本，账本在不同 Peer 之间会共享以及同步复制，Peer 上面也会运行共识算法以及智能合约。后来 Hyperledger Fabric 从 1.0 开始采用了一种新的架构，它的优势是可以实现架构的水平扩展和解耦，它的共识算法可以实现可插拔的模式，来解决传统比如拜占庭共识算法带来的节点数要在一开始就固定好，后期无法动态扩展这些问题。

区块链的业务应用场景非常的丰富，相信大家在国内外也看到了很多落地的案例，这里我也大概列举了一些。比如说公益慈善、信用证、资产证券化、资产托管等等，我也会介绍一下在一些重点的场景上面，区块链的价值以及面临的挑战是什么。

比如说在商品溯源这个场景，区块链实现的是商品从出厂到中间经过物流、仓储、经销商、零售、电商平台，再到消费者，这个过程中它的产品溯源信息的不可篡改的特性。但是在这业务场景落地有一个很关键的挑战，虽然区块链实现了链上数据的不可篡改，但也要解决实体商品本身如何跟区块链上的数据做一个可信的关联。因为我们要避免出现标签是真的，区块链溯源数据都是真的，但是实体商品是假的。这个环节不是区块链就可以把它全部解决，我们还要结合像防伪技术等等，去形成更完整的溯源方案。

在数字内容版权这个领域，区块链的价值在于可实现对无论视频、音频、电影、音乐、电子书等等内容的创作权的存证确认，以及更进一步的，在消费、交易环节给创作者做公平的收益分享。要在这个场景落地也有一些很关键的挑战，就是怎么保证在内容、交易和消费的环节，将消费数字内容的工具和流程均纳入到区块链这种利益分配的体系，这是区块链在这个场景落地的一个很关键挑战。

在供应链金融，核心企业在供应链中往往处于很强势的地位，那么如何把核心企业的信用资质传导到供应链的上游和下游，比如上游的多级供应商，以及下游的多级经销商，让他们可以基于核心企业的背书，得到更低成本、更高效的融资，这是供应链金融区块链一个核心价值。但里面的关键落地挑战在于，怎么能吸引到整个供应链上下游那么多企业都愿意参与到区块链这个业务体系来。

基因医疗数据存储和共享，这个场景有一定共通性，因为它也会适用于像金融大数据，或者是互联网大数据，这些数据资产的存储和共享。这里面区块链价值在于，可以对数据资产的所有权做一个确认，并且在这种数据资产交易的平台或者体系里面，可以根据所有者的这些不可篡改的确权存证来保证数据交易的利益的在各方实现分配。但里面也有一些关键挑战，例如怎样去保证数据交易在数据使用这个环节，数据资产不会发生泄露或者被违规使用，或者被购买方二次倒卖等等，这是数据资产业务落地的一个关键挑战。各个行业区块链落地也都面临着很多挑战，上面举的是一些比较典型的例子。

对于企业来说，现在关心区块链，并且想和业务结合的企业越来越多。我们与阿里云的客户、以及我们的合作伙伴进行了很多探讨，以及内部我们也正在开发一些落地方案。

对一个企业来说，要应用区块链到底需要考虑哪些维度的问题？大概分为这几个类别。比如说在业务方面，我们首先要做一件事是要有“人”的保证，这个人才的团队包含很多方面，需要区块链的技术人才，需要部署区块链底层，或者业务底层的云平台的技术人才，需要有业务应用开发的团队去支持，需要有业务方面的一些专家，所以这是人才团队的维度。

另外业务场景选择，有很多企业场景，如果能用传统的中心化方案或者系统去解决的话，那么就要反思是否有必要去用区块链。如果说有一些场景是涉及到跨企业协作，并且确实缺乏信任基础的，这个就可以考虑应用区块链。

下面是业务流程优化，区块链在业务应用里面是有一个特点，尤其在联盟链，它涉及到跨企业的业务流程，所以不像传统的流程只限于企业内部，只是几个部门之间的协作，跨企业的业务流程需要在保证各方平等、自治的基础上，建立起业务流程以及进一步优化，这些都是必须考虑的问题。

应用开发模式，解决的是如何在你的业务人员或开发人员与区块链底层技术之间构建起一个桥梁，把区块链底层的这些 API 调用、SDK 调用变成你的业务模型、业务流程，让业务人员能够理解和使用。接下来是可视化分析，区块链本身运行是类似于一个黑盒子，如果我们在企业落地，我们关心是它对业务贡献的商业价值，怎样把这种一个黑盒的系统变成对商业的决策者来说是可视化、可量化，并且可用于做 BI 分析的设计。数据建模和管理指的是，区块链里面账本存储的是 key value，是区块链对应的业务场景的数据建模存储的内容。那么区块链业务数据怎么和企业的主数据之间去建立起关联，以及做后期的数据模型的管理？这些也是企业需要考虑的。

下面的话，像技术方案选型，就涉及到区块链技术本身的不同流派、不同区块链类型等等的选择，以及相应的开发编程语言、开发框架的选择，还有底层部署云平台技术的选择。平台设计实施，这包含了整个平台方案以及业务部署方案的设计实施。高可用和灾备，这里面涉及到跨企业区块链业务协作体系，怎么既要保证本企业业务服务的可持续性，也要保证在跨企业协作中，不会因为一个企业的节点，导致了整个联盟链的业务的瘫痪，所以这都是要考虑的很关键的问题。

像安全合规治理，这是大家应用区块链最关心的一个点，因为我都把我的业务数据放在一个跨企业的联盟链上面，我是非常重视里面的数据安全，商业隐私的保护，尤其大家如果还涉及到，比如说进军海外市场，涉及到和美国政府或欧盟打交道，这些很严格的数据保护的要求，隐私保护的政策等等，这方面也是我们应用区块链必须要考虑的。

另外平台应用运维，这里面就涉及到因为区块链的不可篡改特性，导致上面的配置、数据、应用的管理相比传统有很大的不同和挑战。下面是运营，市场营销宣传，我看业界很多公司做得很好，这块我就不用多说了。生态系统参与包含了企业去应用区块链，同时要考虑，是否要跟外部的，比如说区块链相关的官方组织，以及开源社区的技术参与，以及业务生态系统的参与，比如说，基于某个业务形成的这些行业联盟，以及行业协会等等的参与。

所以这里面涉及到的问题是覆盖了很多维度，今天可能不能对所有问题都有一个标准的答案。但我们会对其中一些地方，分享我们的一些探索经验。

面的话，是介绍我们在探索过程中用到的工具，就是去年 10 月份，我们在杭州云栖大会发布的基于阿里云容器服务的区块链解决方案。这其实是我们在区块链领域探索的第一小步，目前我们也在紧张地开发一些更新的产品形态和更多的落地方案。

这里面它核心解决是什么问题？对很多企业来说应用区块链，关注的是怎么快速地去把业务和区块链结合，实现业务应用上线，我想聚焦的是业务创新本身，没有足够的比如人员团队或者是时间去进行区块链整个底层的建设，所以这是企业一方面的诉求。

另一方面的诉求是由区块链的技术特性决定的，因为它的不可篡改的特性会导致了在开发业务应用的时候，区块链系统里面的数据，区块链的整个网络的配置，不是说管理员去改几个参数，或者是去做 roll back、delete 等等就可以恢复成一套全新的环境。你需要把整个环境铲掉，然后重新把它再搭建起来才能进下一轮的开发测试等等。这就导致了在业务应用的开发过程迭代的效率问题。这类的话，我们的区块链解决方案可以提供基于界面化的一键自动化配置部署，让企业可以在几分钟内就可以得到一套企业级的区块链开发测试环境，这是我们当时解决用户痛点的一个出发点。

这个是解决方案的大体架构，这里我也不做太多介绍了。大家可以看一下，这里面体现了如何在 Kubernetes 集群技术上去搭建一套 Hyperledger Fabric 区块链服务的最基本的要素的展现，企业在进行区块链技术选型时候也可以参考这些纬度，去选择区块链平台。

下面我们就重点讲讲我们在这三个领域上面的探索经验。

第一个是基于 Hyperledger Fabric 的业务和数据存储容量的估算方法。下面这个图展示的是 Hyperledger Fabric 的完整交易流程以及部署架构，给大家介绍一下基于 Hyperledger Fabric 的区块链交易是怎么进行的。首先业务应用会通过 CA 服务去进行身份的注册以及登录之后，就可以去连接不同组织的背书 Peer 节点，把交易请求发送给背书的 Peer 节点，进行区块链交易模拟运行，模拟运行是通过里面的 Chaincode 容器去进行的，再把模拟交易结果返回给 Client，再发给上面的 Orderer 服务，去把这些模拟运行的交易结果变成一个个区块，这就是区块链里面出块的那个环节。Orderer 服务内部是把 transaction 交易信息放到后台 Kafka 队列，再从队列取出后组成一个个区块的。组成区块之后，Orderer 会把区块广播发送给整个业务网络里的 Peer 节点，每个 Peer 节点收到这些块之后，就会对里面的 transaction 做一个 validation，再把里面合法的交易 commit 到区块链的这些账本里面，这就是区块链 Hyperledger Fabric 一个交易的整体流程。

但对一个企业来说，我如果要搭建一个基于区块链的业务系统，我光了解这个流程是不够的，尤其是企业的架构师、或者预算和采购的团队，以及甚至 CTO 他会问这个问题：你这套系统到底能支撑我多大的业务量？尤其区块链里面最重要的是交易数据，那么为了对交易数据做持久化，我要规划多大的存储资源才能满足我企业业务未来一年、两年、三年的运行的需要，这是我们遇到的很多客户在落地前问的第一个问题。

这个问题不好回答，因为由于区块链比如 Hyperledger Fabric 本身的交易流程以及底层技术架构复杂性，业界也没有很好的估算的方法。我们进行了对 Fabric 架构和代码的分析，以及通过一些容量的测试，得出了一些估算方法，下面跟大家分享一下。

首先我们对整个 Fabric 技术架构的存储增长的热点做了一个定性的分析，可以看到在 Orderer 这个节点，每个 Orderer 它会保存账本的一个 block file，就是交易历史文件，它跟我们的交易量是线性相关的，增长的压力是比较大的。

其次是 Kafka 集群的队列，刚才讲的在 Orderer 收到交易数据以后是放在 Kafka Broker 的队列里面，这里面也会有数据容量的增长，这块是黄色，代表它增长压力是中等的，后面会解释一下。其次在整个网络里面每个 Peer 又有两部分，在 Peer 的 Ledger 里面也有 block file，这块也是随着交易量会有一个线性增长。其次 StateDB 是存储账本的世界状态，这一部分也会跟交易相关，但是它不是一个直接线性相关的关系。

有了这个定性的分析结果之后，我们再进一步看看如何定量的去得出估算的结果。这里是经过刚才讲的一系列架构代码分析，以及容量测试，得到的一个估算公式。可能它还不是非常完美的，但是在实际应用中已经能提供非常有用的信息。我大概解释一下，区块链有个多链的概念，就是 Fabric 有个多链的概念，通过 Channel 去实现，每个 Channel 代表了一种业务，这种业务有独立的账本，跟其他的 Channel 是隔离的关系。我们可以让用户提供一个输入，比如说它可以估算每种业务每天平均交易笔数作为基础，因为这里我们进行的是容量估计，而不是做 Performance 峰值估计，这是第一个输入参数。

其次 Fabric 每一笔交易的基本开销是 Fabric transaction 这种数据结构，这个数据结构我们分析过代码，大概是 2.9KB 的大小，但是还有其他附加的，比如说 Index 的一些开销以及 Block 的一些开销，我们大概取一个估算值，大概 4K 左右的一个结果。那么再加上每一笔交易平均业务数据大小，那就是你的真正交易 Payload 数据，你想把什么数据写在链上，这个 Payload 的大小。这里要乘个 2，乘 2 是个很关键的点，在刚才讲的背书交易的过程，它这个交易 transaction 数据是包含两部分，一个叫了 chaincode proposal payload，以及 proposal response payload，它是把我的业务数据这一部分进行了两次的表述，在我的 transaction 数据结构里面，这就是为什么有乘 2 的原因。

其次就是业务 Channel 数量，我搭起来一套 Fabric 区块链网络，不希望只服务于一种业务，希望可以支持多种业务，那么要乘上相应的业务 Channel 数量。要支持业务年的时间，还有 Peer 节点数量，Peer 节点是因为每个 Peer 上面会存储区块链的 block file 来记录账本，乘 2，2 到 1 之间是个很有意思的，它涉及到每个 Peer 既有 block file，也有 StateDB，比如企业级我们现在用 CoachDB，但这个数据特征是跟你的业务类型紧密相关的，如果说你每个交易都是创建一个新的 key value，跟你多笔交易 update 同一个 key value，对 StateDB 的开销是不一样的。

另一方面，因为像 CoachDB 它应用了 Google 的 Snappy 压缩技术，真正的交易的 Payload 进到 StateDB 里面存成 key value，它不是原生的数据大小，而是它会经过一段时间压缩之后，数据量会大大的减小，当然压缩比例会跟业务数据的本身这些数据的一些特征会有关系，这就是一个比较弹性的，因为涉及到我刚才讲的 StateDB 的特性。此外 Orderer 的节点数量，这里面就涉及到，因为 Orderer 它保存了一套完整的数据账本，那么它跟 Peer 的账本是一致的，这块还有相应的开销。

然后就是 Kafka，Kafka 的队列是有一个功能是做 retention period 的保证，经过 retention period 之后，它可以把队列里的消息，就假定是客户不需要的可以把它清除掉，在 Fabric 里面 kafka  Retention 天数大概是 7 天，当然用户可以自定义了，7 天的量，再乘以 replica，replica 是 kafka 用来做数据的高可用的，同一套数据在 kafka 会有多套副本。在 Fabric 里面，kafka replica 数量是 3，这是只需要保存 7×3 的这样一个量。这就是整个估算的方法，下面我给出对应的 Excel 公式，大家也可以针对你的情况自己得出一套自动计算的估算公式。

面再讲讲，在运用估算方法以及注意的点，也反映了区块链这个业务应用系统一些设计原则。第一个，每条业务 channel 它是有总的大小限制，这个来自于哪里呢？因为刚才讲到每个 channel 它有一套账本，账本核心是 Block，记录所有的交易数据、交易历史记录，这个 Block 是以一个个 append-only 类型的文件来存储，这些文件大概是有 10 的 6 次方这样的数量上限，每个大小是 64 兆，乘下来，技术上大小上限是 61TB。刚才看到估算的这些值，但是它的上限，比如说每个 Order 或者每个 Peer，它上面的业务数据量是不能超过 block file 的上限的。

第二个就是我们要注意到底什么东西是适合放在区块链的，这不仅仅是容量规划的问题，而是整个业务场景选择的问题，因为首先区块链的特征是适合保存证据，它不是用来作为原始的数据存储，或大数据存储的基础设施。另外的话，如果你的业务场景，频繁地去更新同一个 Key，比如银行里面转账、支付交易，那么我们就要思考这种是否适合区块链一个特质，因为区块链在业界也有一个不成文的共识，它本身不涉及用于支撑高频交易业务的。另外还有 Block 开销，因为刚才讲了 transaction 是封装在 Block 里面的，这个 Block 本身从数据结构上大概有 1.9KB 的基本开销，Block 数量跟 transaction 数量比例是不定的，因为有下面几个原因，看到数字货币像比特币，它的出块是根据矿工挖矿，也就做一系列的穷举计算以及做哈希计算得到一个满足难度条件的随机数等等，这是数字货币出块。

但是在 Fabric 里面出块，它只需要满足这样三条标准，比如 Block 里面包含的 transaction 笔数达到上限，它就可以去出一个块。或者是 Block 里面包含的 transaction 总的 byte 字节数达到了上限，或者是从第一条 transaction 进入 Block 之后，等待时间到达上限都可以产生一个块。因为这三条标准导致了 transaction 数量与 Block 数量是没有严格的对应的关系，顺便说一句，这三个标准跟 IBM MQ 做网络批量的高效传输三条标准是基本一致的，业界有很多设计是很巧合的。

其他还有一些比较次要的考虑因素，比如说 Fabric 容器镜像开销，Fabric 涉及到容器镜像从三五百兆再到 1.5G，1.3G 都有，假如说所有的镜像单独存成文件，大概是 11G 的开销，当然如果我们把镜像存储在 Docker Registry 里面比如说 Harbor，或者是云上的镜像服务，它占的实际体积会小很多，因为基于 docker image 分层文件系统的技术。但是如果对企业来说可能要考虑，我要备份多少套的镜像版本来支撑业务的升级、回滚，或者是开发的需要，这是存储开销。此外还有业务应用跟其他软件的容器镜像、以及数据的存储备份等等这些开销，但这些都是相对次要的一些因素。

我们分享完第一个探索经验，下面将从运维角度，怎么对 Hyperledger Fabric 日志来实现企业级的运维分析。可能在座的很多同仁会有过使用 Fabric 日志的一些经验，比如说我们可以通过像 Kubernetes 控制台，去查看某一个 Peer 节点、Orderer 节点的日志信息，或者通过命令行运行 kubectl logs 或 docker logs 命令，也可以看到每个节点的容器的日志信息。但问题是这些手段满足不了企业级运维和业务分析的需求，这里所面向的对象很可能是区块链运维系统的团队，甚至某些场合下会涉及到业务相�