测试
全部博文（931）
分类： 架构设计与优化
2019-08-27 21:36:03
今天的文章来自Wen Aviva, 坐Jerry面对面的程序媛。
Jerry在之前的公众号文章《在SAP UI中使用纯JavaScript显示产品主数据的3D模型视图》已经介绍过Aviva了，SAP成 都C4C开发团队中其他同事评价她为：“美腻与智慧的化身”，“云时代女王”，“是大家前沿技术的引路人”。因为Jerry和Aviva就在一个组，所以我的看法是，这些评价都实至名归。
比如Jerry了解到的Javascript 3D渲染，增强现实(Argument Reality)和这篇文章谈到的Hyperledger Fabric， 全部都是从Aviva那里学到的。
SAP成 都研究院的每位同事，只要是参加了2017年岁末年会扫福字领红包的活动，则理论上都使用了Aviva和成 都另一位程序媛Zhao Rina开发的基于AR的小应用。
2017年7月初成 都C4C开发团队刚刚创建，除了老大Max之外，只有5位组员：哈公子，大卫哥，象老师，勇哥和阿爽。当时这支新的开发团队面临的最紧迫问题，就是赢得C4C美国开发总部的信任，从而从总部揽活到成 都本地来做。用什么获得信任呢？对程序猿来说，当然是talk is cheap, show me the code。当时这支刚刚组建起来的五人小团队对C4C毫不了解，但是却选择了一个中国客户呼声非常高，非常希望能够添加到C4C标准产品去的backlog。短短一个月时间，这个五人小团队完成了从现学C4C产品知识和前后台开发知识，到将backlog实现成一个原型的全过程。当原型录成的视频给美国开发老大过目之后，得到了极高的评价，惊叹这只团队从创建到productive只花了短短一个月的时间。这个原型的顺利完成，为成 都C4C团队后续的发展壮大打下了一个坚实的基础。
这个原型最后的交付形式是iOS应用。当时五位同事都没有做过iOS平台上的开发，不过幸好我们有Aviva。Max从SAP成 都数字创新空间租借了Aviva。在她的帮助下，原型发布顺利完成。更令人敬佩的是，Aviva将她的iOS开发经验无私地分享给了团队其他同事，现在C4C团队已经有多位同事能够在iOS平台上进行工作。我想，今年三月成 都C4C团队参加编程马拉松时，在组队阶段给队伍取名为“Hi Aviva!”, 或许是想通过这种方式感谢Aviva对C4C团队做出的贡献。
Jerry很庆幸每天可以和这样的同事一起工作。
下面是Aviva的正文。
区块链的数据结构是一个链表，交易数据被存储到链表的区块中，区块链的第一个区块叫创世区块，除了创世块以外，每个区块还包含前一个区块的哈希指针，这个哈希指针的值是根据前一个区块的实际数据计算出来的。哈希指针指向前一个区块，后面的区块可以查找前面所有区块的信息。
账本的数据结构就是这样的一个链表，那么分布式的含义是什么呢？
区块链的众多参与者组成了一个松散自治的P2P网络，我们把区块链网络的参与者叫做节点，每个节点都拥有一个账本拷贝，所有账本的信息都是一致的，在区块链里没有中心节点。每当有新的交易进来，所有节点的账本都会更新，并且最终保持一致。更新的方式不是去修改某个区块的值，而是保存交易记录。比如在比特币系统中，它没有用户资产记录这样的概念，不像普通数据库那样用一条数据存储资产，比特币用户资产的值是通过把所有的交易记录串联聚合后得到的，账户里资产的来源可以一直向上追溯，直到创世块为止。区块链里的交易数据根据具体场景，可以是任何需要记录的信息。
为了支持信息的持续更新，以及对账本进行管理（写入交易，进行查询等），区块链网络引入了智能合约来实现对账本的访问和控制。智能合约不仅仅可用于在区块链网络中打包信息，它们也可以被用于自动的执行由参与者定义的特定交易操作。
比如智能合约可以规定物流中的运输费用，根据物流的快慢收取不同的费用，根据货物的到达时间进行自动转账等。上传到区块链网络中的的智能合约会被打包到某一个区块中，因此智能合约一旦写入区块链，也是不可更改的。
区块链网络中交易信息同步的过程，确保交易只有获得适当参与者批准后才更新，所有的参与者都会将同样的信息按照同样的顺序更新，这样的过程叫做共识。共识机制是区块链的核心之一。
区块链的第一个应用比特币，采用的是Proof of Work（工作量证明）的共识机制。简单介绍一下比特币的共识机制，算法的具体细节大家可以去查白皮书。节点收到一个交易后，会根据判断标准对该交易进行有效性校验，无效的交易会被废弃。通过有效性验证之后的交易将会被广播给其他节点。其他节点会做同样的独立校验，当有效的交易达到整个网络所有节点时，即全网达成了“该交易有效”的共识。每个节点都会收到很多有效但是还未被打包到区块中的交易，这些交易被组装成Merkle Tree，Merkle Tree的第一个交易比较特殊，叫做coinbase，由节点自己创建，将挖矿奖励支付到矿工自己的地址。挖矿奖励包括新创建的比特币和打包进该区块所有交易的手续费总额。然后节点计算一个符合难度的哈希值，挖矿就是通过修改参数不断计算区块哈希值，直至达到难度要求，也就间接证明了该节点付出了对应的工作量，这就是工作量证明。Jerry的公众号文章《300行ABAP代码实现一个最简单的区块链原型》里用了一个ABAP方法CL_ABAP_MESSAGE_DIGEST=>CALCULATE_HASH_FOR_CHAR来计算区块的哈希值。
当节点计算出一个符合难度的区块哈希时，即说明该矿工挖矿成功了，该节点将该区块组装到本地的区块链，同时也将此区块广播给其他节点。其他节点接收到该区块后会验证该区块是否有效，有可能有两个节点同时挖出了新的区块B1和B2，它们的上一个区块都是同一个区块P。有的节点可能会先收到B1，有的会先收到B2，这时区块链出现了暂时性的两个分叉。要打破这种局面，要看下一个区块是基于B1生成还是基于B2生成。如果基于B1，B1这条链就变成了最长链，其他包含B2的节点会重新选择最长链，而B2作为孤块被丢弃掉。
到目前为止，我们可以将区块链看做是一个共享的，去中心化的多备份系统，通过智能合约更新交易数据，同时借助共识的协作流程使网络中所有的节点保持一致。
这里的交易可以指代任何数据，例如：数字货币，合同，记录或者其它任何信息。
公有链：网络中的节点可以任意接入，网络中数据读写权限不受限制，所有节点都参与共识过程。比特币，以太坊等数字货币都属于公有链。
私有链：网络中的节点被一个组织控制，由其独享该区块链的写入权限，私有链和其他的分布式存储没有太大区别。
联盟链：多个公司或组织通过授权接入，由某些节点参与共识过程。Hyperledger Fabric属于联盟链。
Hyperledger Fabric 是Linux基金会发起的Hyperledger项目之一。Hyperledger Fabric 专为在企业环境中使用而设计的开源的基于区块链的分布式账本。Hyperledger Fabric可用于全球供应链管理、金融交易、资产记账、人力资源、保险、健康和数字音乐等领域。
Hyperledger Fabric中的账本子系统(ledger)包括两个组件：世界观(world state)和事务日志(transaction log)。世界观记录了账本在特定时间点的现状，是一个键值数据库。交易日志记录产生世界状态当前值的所有交易，是世界观的更新历史。账本的世界观的底层数据库可以更换，可以选择使用levelDB或couchDB。
Hyperledger Fabric是第一个支持以通用语言编写智能合约的区块链平台，可以使用java，nodejs和go语言来编写智能合约。Hyperledger Fabric中的智能合约也叫链码(chain code)。
和其他公有区块链平台最大的不同，Hyperledger Fabric 是私有的并且需要授权才能接入，它拥有一个MSP(Membership Service Provider)模块专门提供成员管理服务。
CA(Certificate Authority)负责权限管理，成员身份相关证书管理(Enrollment CertificateAuthority)和维护交易相关证书管理(Transaction Certificate Authority)等等。
Hyperledger Fabric提供了建立channel的功能，这允许参与者为交易新建一个单独的账本。当网络中的一些参与者是竞争对手时，这个功能变得尤为重要。因为这些参与者并不希望所有的交易信息——比如提供给部分客户的特定价格信息——都对网络中所有参与者公开。只有在同一个channel中的参与者，才会拥有该channel中的账本，而其他不在此channel中的参与者则看不到这个账本。
Hyperledger Fabric使用独立的排序节点(order)来提供共识服务，负责排序交易，提供全局确认的交易顺序。
应用程序通过SDK访问Hyperledger Fabric。
最新版Hyperledger Fabric的设计中，根据功能将节点角色解耦开，让不同节点处理不同类型的工作负载。从业务逻辑上又将节点分为背书节点(Endorser)和提交节点(Committer)。
Endorser peer：负责对来自客户端的交易进行合法性和权限检查（模拟交易），通 过检查则签名并返回结果给客户端。
Committer peer：负责维护账本，将达成一致顺序的批量交易结果进行状态检查，生成区块，执行合法的交易，并写入账本，同一个物理节点可以同时担任endorser和committer两个角色。
共识流程主要分Proposal，Packaging和Validation三个阶段。
应用提交一个交易proposal，然后将其提交给所有的背书节点，后者接到后，将其作为输入执行链码生成相应的交易proposal响应。此时并不会更新Ledger，而是对交易proposal 响应签名，并将其返回给应用。应用收到签名后的响应，共识流程的第一阶段就完成了。
这个阶段是order节点对交易进行排序打包。Order节点从各个应用接收交易proposal响应，然后对这些交易进行排序，排序之后打包成区块。
共识流程的最后一个阶段，由order节点将区块分发给所有和它连接的节点，这些节点将确认区块中的交易都经过背书节点签名，然后将确认后的区块更新到ledger中。
整个流程称为共识，所有节点都已对交易内容和顺序达成一致，这一过程由order节点控制。 共识是一个多步骤的过程，只有在整个流程完成时才会更新账本 ，可能每个节点的更新时间稍有不同。
构建一个Hyperledger Fabric平台绝非易事，既需要硬件基础设施的投入，也需要全方位的开发和运营管理(DevOps)。除了平台本身，一套完整的解决方案，还包括设备接入，访问控制，服务监控等管理功能。
SAP Cloud Platform(下文简称SCP)提供了开箱即用的Hyperledger Fabric Service，为开发者提供了强大的服务支持：
直观友好的可视化监控与操作界面，帮助开发者按需申请区块链网络，创建管理节点、渠道，而无需考虑底层硬件资源。
简单易用的智能合约开发与测试环境，方便开发者对应用代码进行管理。
安全，隐私性方面的保障，并对相关资源进行了性能优化。
以上是我对Hyperledger Fabric的一些理解，接触和了解区块链的时间有限，难免存在一些错误，欢迎大家指正。后续会给大家带来SAP云平台上Hyperledger Fabric开发的一些细节介绍。
主要参考文献
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
