Wednesday, October 18, 2017

《区块链原理、设计与应用》出版!


《区块链原理、设计与应用》已经正式出版,详细介绍了区块链相关技术,特别超级账本的设计、架构和应用,欢迎大家阅读使用并反馈建议。

编辑推荐

本书由超级账本全球技术委员会委员、核心设计和开发者编撰,清华大学五道口金融学院常务副院长廖理教授作序,Apache 基金会创始人 Brian Behlendorf 等国内外专家联袂推荐。
本书由浅入深,详细讲解超级账本 Fabric 架构设计精华与应用开发案例,是区块链与分布式账本开发落地专业指南。

内容简介

全书分为理论篇和实践篇两大部分。
第 1-3 章介绍区块链技术的由来、核心思想及典型的应用场景;第 4-5 章重点介绍区块链技术中大量出现的分布式系统技术和密码学安全技术;第 6-8 章介绍区块链领域的三个典型开源项目:比特币、以太坊以及超级账本;第 9-11 章以超级账本 Fabric 项目为例,具体讲解了安装部署、配置管理,以及使用 Fabric CA 进行证书管理的实践经验;第 12 章重点剖析超级账本 Fabric 项目的核心架构设计;第 13 章介绍区块链应用开发的相关技巧和示例;第 14 章介绍区块链服务平台的设计与开发,并讲解应用超级账本 Cello 项目构建服务平台的相关知识。
本书覆盖了区块链和分布式账本领域的最新技术,可帮助读者深入理解区块链核心原理和典型设计实现,以及高效地开发基于区块链平台的分布式应用。

专家推荐

区块链(Blockchain)无疑是近十年来最具颠覆性的新兴信息技术之一。业界甚至把它与人工智能(Artificial Intelligence)、云计算(Cloud Computing)和数据科学(Data Science)统称的“ABCD”,推崇为未来*有潜力的四大信息技术方向。本书的作者有深厚的学术背景和丰富的实战经验,在区块链技术方面接触广泛、钻研深入,积累了大量基于超级账本的实践和应用案例。本书深入浅出,系统总结归纳了区块链及其相关技术基础,全面比较分析了区块链主要开源项目的异同,相信对区块链技术与系统的应用和研发是一个很有价值的指南。
-- 李军,原清华大学信息技术研究院院长,清华信息科学与技术国家实验室常务副主任
区块链技术正与云计算、大数据和人工智能等新兴技术交叉融合,孕育出新的商业模式和产业格局,具有重构数字经济发展生态的重要潜力。这本书既有对区块链原理的深度解析、三大典型开源区块链项目的底层剖析和Fabric 架构设计的细致阐述,也有转账、资产权属管理、调用其他链码等具体应用的开发示例,是一本知行合一的好书,与大家分享并推荐。
-- 刘多,中国信息通信研究院院长,中国通信标准化协会副理事长
互联网彻底解放了信息,使得信息的创作、获取、存储、再加工无处不在。区块链也将同样解放人类的交易过程,以一种全新的方式建立交易的信任、仲裁、记录基础。区块链和分布式账本技术很可能是我们这个时代下一个可以和互联网相提并论的伟大发明。本书系统介绍了区块链技术和分布式账本技术,包括核心概念、应用场景、关键技术和开发技巧,并且较全面地介绍了三大典型区块链开源项目:比特币、以太坊和超级账本。本书作者不仅是全球发展*快的超级账本项目的重要代码贡献者和开源社区组织者,也是将区块链技术应用到客户实际生产项目的实践者。因此,书中不仅有深入透彻的架构设计剖析,可以让读者快速掌握该领域的核心知识,还有容易上手的实战案例,可以让读者感受区块链技术的应用前景。无论是希望了解区块链和分布式账本领域的核心技术,还是学习如何更好地开发区块链应用,本书都值得一读。
-- 田忠,IBM 全球杰出工程师、IBM 中国创新工程院院长
Baohua Yang has an impressive technical depth and breadth of knowledge on blockchain and distributed ledger technologies and the impact they will have on the way businesses and governments work. He has made enormous contributions to Hyperledger, the distributed ledger project of the Linux Foundation, both in China and globally.
-- Brian Behlendorf,超级账本管理委员会执行董事,Apache基金会创始人

销售渠道

目前已授权京东图书China-pub 等各大渠道进行销售!

===== 关于 TechFirst 公众号 =====
专注云计算、大数据、Fintech、人工智能、分布式相关领域的热门技术与前瞻方向。
发送关键词(如云计算、大数据、容器、区块链),获取热门点评与技术干货。
欢迎投稿!
如果你喜欢公众号内容,欢迎鼓励一杯 coffee~


Hyperledger Fabric 核心术语

2017-05-09 TechFirst 
  • Anchor(锚点):一般指作为刚启动时候的初始联络元素或与其它结构的沟通元素。如刚加入一个 channel 的节点,需要通过某个锚点节点来快速获取 channel 内的情况(如其它节点的存在信息)。
  • Auditability(审计性):在一定权限和许可下,可以对链上的交易进行审计和检查。
  • Block(区块):代表一批得到确认的交易信息的整体,准备被共识加入到区块链中。
  • Blockchain(区块链):由多个区块链接而成的链表结构,除了初始区块,每个区块头部都包括前继区块内容的 hash 值。
  • Chaincode(链码):区块链上的应用代码,扩展自“智能合约”概念,支持 golang、nodejs 等语言,多为图灵完备。
  • Channel(通道):Fabric 网络上的私有隔离。通道中的 chaincode 和交易只有加入该通道的节点可见。同一个节点可以加入多个通道,并为每个通道内容维护一个账本。
  • Committer(提交节点):1.0 架构中一种 peer 节点角色,负责对 orderer 排序后的交易进行检查,选择合法的交易执行并写入存储。
  • Commitment(提交):提交节点完成对排序后交易的验证,将交易内容写到区块,并更新世界观的过程。
  • Confidentiality(保密):只有交易相关方可以看到交易内容,其它人未经授权则无法看到。
  • Endorser(推荐节点或背书节点):1.0 架构中一种 peer 节点角色,负责检验某个交易是否合法,是否愿意为之背书、签名。
  • Endorsement:背书过程。按照 chaincode 部署时候的 endorsement 策略,相关 peer 对交易提案进行模拟和检查,决策是否为之背书。如果交易提案获得了足够多的背书,则可以构造正式交易进行进一步的共识。
  • Invoke(调用):一种交易类型,对 chaincode 中的某个方法进行调用,一般需要包括调用方法和调用参数。
  • Ledger(账本):包括区块链结构(带有所有的交易信息)和当前的世界观(world state)。
  • Member(成员):代表某个具体的实体身份,在网络中有用自己的根证书。节点和应用都必须属于某个成员身份。同一个成员可以在同一个通道中拥有多个 peer 节点,其中一个为 leader 节点,代表成员与排序节点进行交互,并分发排序后的区块给属于同一成员的其它节点。
  • MSP(Member Service Provider,成员服务提供者):抽象的实现成员服务(身份验证,证书管理等)的组件,实现对不同类型的成员服务的可拔插支持。
  • Non-validating Peer(非验证节点):不参与账本维护,仅作为交易代理响应客户端的 REST 请求,并对交易进行一些基本的有效性检查,之后转发给验证节点。
  • Orderer(排序节点):1.0 架构中的共识服务角色,负责排序看到的交易,提供全局确认的顺序。
  • Permissioned Ledger(带权限的账本):网络中所有节点必须是经过许可的,非许可过的节点则无法加入网络。
  • Privacy(隐私保护):交易员可以隐藏交易的身份,其它成员在无特殊权限的情况下,只能对交易进行验证,而无法获知身份信息。
  • System Chain(系统链):由对网络中配置进行变更的配置区块组成,一般可以用来作为组成网络成员们形成的联盟约定。
  • Transaction(交易):执行账本上的某个函数调用或者部署 chaincode。调用的具体函数在 chaincode 中实现。
  • Transactor(交易者):发起交易调用的客户端。
  • Validating Peer(验证节点):维护账本的核心节点,参与一致性维护、对交易的验证和执行。
  • World State(世界状态):即最新的全局账本状态。Fabric 用它来存储历史交易发生后产生的最新的状态,可以用键值或文档数据库实现。

===== 关于 TechFirst 公众号 =====
专注云计算、大数据、Fintech、人工智能、分布式相关领域的热门技术与前瞻方向。
发送关键词(如云计算、大数据、容器、区块链),获取热门点评与技术干货。
欢迎投稿!
如果你喜欢公众号内容,欢迎鼓励一杯 coffee~

Monday, September 26, 2016

第二届区块链峰会随记

上周(9.19-9.24)在上海参加了第二届区块链全球峰会。
整体感觉,整个产业已经上升到一个新的阶段了,开始有一些落地的项目,不再只是呼吁概念。

天下大势,三分已成

币圈和链圈渐行渐远,而目前区块链领域从技术实现上已经逐渐划分为三大阵营:以太坊、超级账本和其它。
以太坊(Ethereum):开源阵营。由 VB 同学带领的以太坊团队牵头开发。草根出身,自然受到很多个人开发者的喜爱,相关的客户端、环境支持也比较完善。不少欧洲的创业项目(Consensus 投资了不少)都是基于以太坊的平台来搭建,但普遍规模较小。
超级账本(HyperLedger):开源阵营 + 企业支持。由 Linux 基金会组织团队开发。科技界和金融界的巨头们牵头支持,自然受到各大企业的青睐。不少机构给的对区块链平台的需求和设计,基本可以理解为对超级账本白皮书的解读,包括隐私保护、可审计、安全、插件化的共识等都是超级账本的基本特性。SWIFT 也刚跳出来支持超级账本阵营。更多信息可以查看 这里
其它方案:包括各种开源、非开源的方案。以创业团队居多。百花齐放百家争鸣是好事情,但是可惜自己真的从头做的很少,这也挺正常,毕竟区块链领域相关技术门槛确实比较高。少数几个号称从头做、有底层技术的又不开源,这在如今是一件挺可惜的事情。
个人感觉,区块链产业要想做大,至少在基础设施这一层需要尽快的成熟和规范,这对大家都有好处。Linux、Web Server 这样的开源方案出来被大家认可后,才有了整个互联网的繁荣。

通用平台 vs 专用平台

除了对通用平台的讨论,开始有人意识到专用平台的重要性。
之前不少人喜欢用传统数据库的需求来质疑区块链。实际上区块链技术跟数据库完全是两个领域的事情,解决的不同的问题。如果某个业务场景真的需要特定的功能,则应该结合业务层从一开始就设计支持,而不是所有需求都堆到底下。
大胆预测,未来可能出现专门面向各个领域的专用区块链平台:金融区块链、物联网区块链、众筹区块链……,类似不同的 Linux 发行版。
只有这样,才能真的说区块链落地了。

应用场景

应用场景仍然是五花八门,开始有一些关注到具体实际的问题。
比如解决个人的资产登记问题、跨境资金、分布式电商平台,大部分也都是之前就耳熟能详的。但有些推出了新一代的解决方案,还是有不少亮点的。
对应用来说,技术层面反而要弱化,好的商业模式、对市场的把握、对当地政策的解读往往都是决定性的因素。
从目前来看,明后两年将会出现应用的大爆发,特别是国内市场。

BaaS 将成为短期内热点

随着 IBM、微软、Google 等宣布退出 BaaS 业务,将有更多的云服务商会追随这一趋势。
目前来看,基于 HyperLedger 的 BaaS 有相对成熟的解决方案。

Friday, August 12, 2016

ProtoBuf 与 gRPC 你需要知道的知识

ProtoBuf 是一套接口描述语言(IDL)和相关工具集(主要是 protoc,基于 C++ 实现),类似 Apache 的 Thrift)。用户写好 .proto 描述文件,之后使用 protoc 可以很容易编译成众多计算机语言(C++、Java、Python、C#、Golang 等)的接口代码。这些代码可以支持 gRPC,也可以不支持。
gRPC 是 Google 开源的 RPC 框架和库,已支持主流计算机语言。底层通信采用 gRPC 协议,比较适合互联网场景。gRPC 在设计上考虑了跟 ProtoBuf 的配合使用。
两者分别解决的不同问题,可以配合使用,也可以分开。
典型的配合使用场景是,写好 .proto 描述文件定义 RPC 的接口,然后用 protoc(带 gRPC 插件)基于 .proto 模板自动生成客户端和服务端的接口代码。

ProtoBuf

需要工具主要包括:
  • 编译器:protoc,以及一些官方没有带的语言插件;
  • 运行环境:各种语言的 protobuf 库,不同语言有不同的安装来源;
语法类似 C++ 语言,可以参考 语言规范
比较核心的,message 是代表数据结构(里面可以包括不同类型的成员变量,包括字符串、数字、数组、字典……),service代表 RPC 接口。变量后面的数字是代表进行二进制编码时候的提示信息,1~15 表示热变量,会用较少的字节来编码。另外,支持导入。
默认所有变量都是可选的(optional),repeated 则表示数组。主要 service rpc 接口只能接受单个 message 参数,返回单个 message;
syntax = "proto3";
package hello;

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
  repeated int32 number=4;
}

service HelloService {
  rpc SayHello(HelloRequest) returns (HelloResponse){}
}
编译最关键参数是指定输出语言格式,例如,python 为 --python_out=OUT_DIR
一些还没有官方支持的语言,可以通过安装 protoc 对应的 plugin 来支持。例如,对于 go 语言,可以安装
$ go get -u github.com/golang/protobuf/{protoc-gen-go,proto} // 前者是 plugin;后者是 go 的依赖库
之后,正常使用 protoc --go_out=./ hello.proto 来生成 hello.pb.go,会自动调用 protoc-gen-go 插件。
ProtoBuf 提供了 Marshal/Unmarshal 方法来将数据结构进行序列化操作。所生成的二进制文件在存储效率上比 XML 高 3~10 倍,并且处理性能高 1~2 个数量级。

gRPC

工具主要包括:
  • 运行时库:各种不同语言有不同的 安装方法,主流语言的包管理器都已支持。
  • protoc,以及 grpc 插件和其它插件:采用 ProtoBuf 作为 IDL 时,对 .proto 文件进行编译处理。
官方文档 写的挺全面了。
类似其它 RPC 框架,gRPC 的库在服务端提供一个 gRPC Server,客户端的库是 gRPC Stub。典型的场景是客户端发送请求,同步或异步调用服务端的接口。客户端和服务端之间的通信协议是基于 HTTP2 的 gRPC 协议,支持双工的流式保序消息,性能比较好,同时也很轻。
采用 ProtoBuf 作为 IDL,则需要定义 service 类型。生成客户端和服务端代码。用户自行实现服务端代码中的调用接口,并且利用客户端代码来发起请求到服务端。一个完整的例子可以参考 这里
以上面 proto 文件为例,需要执行时添加 grpc 的 plugin:
$ protoc --go_out=plugins=grpc:. hello.proto

生成服务端代码

服务端相关代码如下,主要定义了 HelloServiceServer 接口,用户可以自行编写实现代码。
type HelloServiceServer interface {
        SayHello(context.Context, *HelloRequest) (*HelloResponse, error)
}

func RegisterHelloServiceServer(s *grpc.Server, srv HelloServiceServer) {
        s.RegisterService(&_HelloService_serviceDesc, srv)
}
用户需要自行实现服务端接口,代码如下。
比较重要的,创建并启动一个 gRPC 服务的过程:
  • 创建监听套接字:lis, err := net.Listen("tcp", port)
  • 创建服务端:grpc.NewServer()
  • 注册服务:pb.RegisterHelloServiceServer()
  • 启动服务端:s.Serve(lis)
type server struct{}

// 这里实现服务端接口中的方法。
func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {
    return &pb.HelloReply{Message: "Hello " + in.Name}, nil
}

// 创建并启动一个 gRPC 服务的过程:创建监听套接字、创建服务端、注册服务、启动服务端。
func main() {
    lis, err := net.Listen("tcp", port)
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }
    s := grpc.NewServer()
    pb.RegisterHelloServiceServer(s, &server{})
    s.Serve(lis)
}
编译并启动服务端。

生成客户端代码

生成的 go 文件中客户端相关代码如下,主要和实现了 HelloServiceClient 接口。用户可以通过 gRPC 来直接调用这个接口。
type HelloServiceClient interface {
        SayHello(ctx context.Context, in *HelloRequest, opts ...grpc.CallOption) (*HelloResponse, error)
}

type helloServiceClient struct {
        cc *grpc.ClientConn
}

func NewHelloServiceClient(cc *grpc.ClientConn) HelloServiceClient {
        return &helloServiceClient{cc}
}

func (c *helloServiceClient) SayHello(ctx context.Context, in *HelloRequest, opts ...grpc.CallOption) (*HelloResponse, error) {
        out := new(HelloResponse)
        err := grpc.Invoke(ctx, "/hello.HelloService/SayHello", in, out, c.cc, opts...)
        if err != nil {
                return nil, err
        }
        return out, nil
}
用户直接调用接口方法:创建连接、创建客户端、调用接口。
func main() {
    // Set up a connection to the server.
    conn, err := grpc.Dial(address, grpc.WithInsecure())
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()
    c := pb.NewHelloServiceClient(conn)

    // Contact the server and print out its response.
    name := defaultName
    if len(os.Args) > 1 {
        name = os.Args[1]
    }
    r, err := c.SayHello(context.Background(), &pb.HelloRequest{Name: name})
    if err != nil {
        log.Fatalf("could not greet: %v", err)
    }
    log.Printf("Greeting: %s", r.Message)
}
编译并启动客户端,查看到服务端返回的消息。

Docker 1.12 Swarm 模式剖析

Docker 1.12 在 2016 年 7 月 28 日正式 GA,除了大量的在使用上的改进和 bug 修复外,最引人瞩目的是原生支持了 Swarm 模式。
熟悉 Docker 的读者都知道 Docker Swarm 是官方三剑客之一,提供了轻量级容器云的支持,以性能卓越出名,跟 K8s 面向应用的较为复杂的容器云方案一时瑜亮,各有千秋。
本次 Swarm 模式特性的发布可谓重要变革,不仅仅是减低使用门槛那么简单,还引入了不少新的围绕应用的特性,从中可以一探 Docker 团队对于容器云的理念。

基本概念

Swarm 定义为一组合作在一起的 Docker 主机集群,由节点组成,每个节点都是一个独立的 Docker 主机。
集群中包括两种节点:管理节点和工作节点。参考 k8s 的结构,也是如此。
  • 管理节点:负责对任务进行调度和其它管理任务,多个管理节点通过 Raft 协议组成集群;
  • 工作节点:负责运行具体的任务,管理节点可以同时作为工作节点。
如果把所有节点配成管理+工作,那就是绝对的对等了,实际上从性能角度考虑,管理节点数量不宜过多,并且相互之间的互联网络要保证好的质量。
此外,还引入了服务的概念。服务也包括两种类型:
  • 复制服务(replicated services):类似 k8s 中复制集的概念,保持一定数量的相同任务在集群中运行;
  • 全局服务(global services):类似 k8s 中 daemon 的概念,每个工作节点上运行一个。
一个服务由多个任务组成,一个任务即一个运行的容器。

主要特性

负载均衡和服务地址管理

k8s 中让人印象深刻的是它的服务自带了负载均衡和服务地址功能,Swarm 也通过 ingress load balancing (基于 ipvs 的四层代理)来实现,为每一个服务提供一个 DNS 地址,维护一个公共的端口。这点上跟 k8s 默认方式略有不同,但效果是一致的,都保证了无论容器如何变化,任意节点对应用的访问保持不变。

跨主机网络

这点还是基于 overlay 网络来实现。

监控管理

基于服务的概念,对运行状态进行管控,自动保持服务的运行状态。

支持命令

目前围绕对集群和服务进行管理,命令都很容易理解。
  • swarm init
  • swarm join
  • service create
  • service inspect
  • service ls
  • service rm
  • service scale
  • service ps
  • service update

Swarm2k

很有意思的项目,就是基于最新的 Swarm 模式来在全球范围内构建一个超过 2000 个节点,1 M 个容器的大集群。
目前已经达到预定目标,具体可以关注 [这里](https://github.com/swarm2k/swarm2k/blob/master/PROPOSAL.md)。
这个项目的成功,也再次证明官方的 Swarm 方案,在性能上确实首屈一指!

小结

跟 Docker 技术自身的火爆不同,Docker 团队一直以来就面临着未来发展的困境,几乎所有人都希望他们只安心做好容器引擎。但作为一个商业化公司来说,这样下去毫无疑问是自掘深坑。于是,他们积极的在基于容器的各种平台和工具上进行构建。包括三件套、包括容器云,都是很好的尝试。
从 Swarm 的特性来看,Docker 团队在应用为中心这点上是认同了 K8s 的理念的,但是自身又同时保持了一定的独立性。这对于 Docker 来说自然是利好。但是目前来看,并没有完全解决团队发展的困境。