本着“以教带学，Learning by Doing”的想法，我于上周加入了。这个群可不太好混，群规要求每个成员必需每周有输出，连续两次交白卷就要被踢出群。
在这样的压力之下，我决定开一个新坑：区块链周周记，记录下每周区块链的学习成果和爬坑经验。作为系列的新篇章，我选择从超级账本的Fabric开始。
为什么选择超级账本作为起点？
我在中曾说过会从超级账本入手开始区块链的学习和实践，同时也给出了个人的理由。但作为一篇布道类文章，单单个人喜好是没有说服力的。
在中，它强调了自己面向企业应用而生的理由：
- 企业希望跟身份确定的人做生意，而非像公链那样完全匿名的对手方
- 并非人人都可加入的商业网络
- 交易的私密性，比如，对于不同的渠道或经销商，他们各自拿到的折扣不一样，这些信息必须是私密的，相互隔离。
- 性能和交易确认的时延
可以看得出，相比起公链激进的做法，以Fabric为代表的联盟链要温和的多，并且也容易为企业所接受。加上其给出的若干限制，技术上的落地也相对容易很多。
Fabric中的主要组件
关于区块链本身的理论和介绍，目前已经烂大街了，在此也就是不再赘述。在本节，让我们来看看Fabric是如何通过主要组件完成技术落地的。
从大的方面讲，Fabric的主要组件大致可划分成这几个部分：
- 分布式账本，解决数据共享问题，让所有参与方拥有共同的交易历史。
- 智能合约，解决应用与账本的交互问题，包括查询和更新。
- 共识机制，解决数据同步问题，基于Endorsement Policy实现交易的传播。
- 成员服务，解决参与方身份问题，只有可信成员之间才能完成交易。
分布式账本
Fabric的分布式账本状态由两部分组成：世界状态（World State）和区块链。前者代表账本的当前状态，变更和查询频繁，往往以数据库形式实现；后者则用来捕获前者的每次变更，作为交易的变更记录，无法修改且极少查询，常常实现为文件形式。
对于世界状态的DB载体，当前版本有两个选择：内置的LevelDB和外置的CouchDB，如果想要获得更灵活的查询能力，选择后者。由此大家应该可以猜出：世界状态中保存的数据是以KV对的形式存在。
对于区块链来讲，它以Block的hash链组成，每个Block包含一组有序的交易。这个顺序是交易顺序，非常关键。
除了这两个组件，Fabric还引入了一个独特的设计：Channel，用来解决不同组织间的账本共享问题。假如组织A同时与组织B和组织C做生意，并且组织B和组织C是竞争对手，那么通过建立不同的Channel可以实现A和B，A和C分别共享各自的账本。利用Channel，很好地解决了常见的B2B场景。
Channel抽象出了业务参与方的沟通，可视为业务网络的子网，实现了交易的相互隔离和业务私密性。
智能合约
Fabric的智能合约以“链码（Chaincode）”的形式存在，外部客户端利用它来完成对世界状态的更改。与以太坊不同，链码支持使用通用编程语言来书写，当前版本支持Go和Node.js，但从中可以看出，离支持Java应该也不远了：
public enum Type { JAVA, GO_LANG, NODE} 对于初学者需要注意的是：链码 != Fabric SDK。前者运行于Fabric环境，执行业务逻辑。后者则由被客户端程序用来与链码完成交互。打个类似的比方：
- 将Fabric环境视为Tomcat这样的容器。
- 链码则可视为运行于其中的Servlet。
- Fabric SDK则类似HttpClient这样的类库被Java客户端利用发起请求，实现于Servlet的交互。
由此可知，链码本身实际上是一个应用，其生命周期可分为：package、install、instantiate、upgrade。同样，链码可以绑定任意任意数量的Channel，并独立运行。
关于链码的教程，文档已经给出了，在此就不再啰嗦。
共识机制
Fabric中有三类节点：
- Client，代表最终用户向endorser提交事务调用（Transaction Invocation），向ordering service广播事务提议（Transaction Proposal）。
- Peer，提交事务，维护世界状态和账本副本（区块链）。其中，有一类特殊的Peer是Endorser。
- Orderer，提供节点间的通信服务，保证消息的交付和顺序，典型如Kafka队列。
整个在文档中有介绍：
- client发起事务提议。
- endorser peer验证并执行。
- client检查事务提议的响应。
- 若endorsement policy满足，client将endorsement打包进事务，提交给ordering service。消息包括：endorser签名、读写集和channel id。
- 事务被orderer提交给channel上所有的peer，它们会检查并提交事务。
- 账本更新。
从上面的流程可以看出，Fabric的共识机制建立在endorsement policy之上，它可以通过命令行参数进行配置，并不需要Channel的所有Peer参与。
成员服务
成员服务负责参与方的身份许可和验证，它建立于数字证书和信任链基础之上。所谓成员，既可以是组织（Org），也可以是组织部门（OU）。Fabric的成员服务配置可以出现在两处：Local（节点）和Channel（Channel级）。
从开发角度来讲，引入成员服务带来的作用就是：如果应用（Client和Chaincode）要参与到区块链网络中，则需要相应签名和证书。
Fabric的开发套路
老实讲，从上面的简单介绍已经看出，Fabric的开发并不简单，它至少涉及：
- Client，提供UI、链码交互以及其他辅助功能。
- 链码，负责执行业务逻辑。
- 业务网络，定义参与方、Channel和Endorsement Policy。
- 成员管理，定义组织及其成员映射，这涉及到一系列证书的发放。
- 应用部署，将上面的各部分部署到Fabric环境。
这还不算完，如何测试也是一个大麻烦，相比起简单的CRUD应用，光搭建Fabric的环境就让人生畏。假如你对自己的要求更高点，想要实现一个持续集成环境，该怎么办？
此外，开发之后的运维成本也不会低，除了Fabric本身的基础设施，链码的平滑升级也对开发和运维提出了高标准。
鉴于这些麻烦的事情，假如你没有办法说服业务合作方也同样部署一套Fabric，我觉得完全没有必要去基于它来开发应用。单组织内的区块链应用，我个人认为是一个伪命题，没有存在的价值。
关于示例教程，Fabric的文档已经给出了，各位可以仔细阅读。
为了降低区块链应用的开发难度，超级账本项目又引入了。其目的在于加速应用的开发和部署，目前已经支持Fabric，当前处于孵化阶段。它建立在诸多框架和工具之上：
- node.js + angular，帮助开发者完成全栈区块链解决方案的开发。
- yeoman，利用其模板功能快速搭建应用框架。
- 一套开发环境，实现应用的打包部署以及暴露成Restful Service。
看起来很不错！
写在最后
对于一个初学者来讲，写这篇文章真不容易！如文章存在错误，不要客气，只管指出，:)。关于下一周的周记，我会去写一个实际的Fabric应用的例子，同时给出Composer的例子，请保持关注。
附注：在写此文的过程中，我还找到了一篇吐槽Fabric的文章，这里一并给出，方便大家客观评定。