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 来说自然是利好。但是目前来看,并没有完全解决团队发展的困境。